Java 弗林克：是因为丢失记录吗？

我的拓扑结构是这样的：

kafka（p:6）->reduce（p:6）->db-writer（p:12）

（其中p:parallelism）

• 我让它运行在带有

  taskmanager的单节点“集群”上。numberOfTaskSlots:30

• 我知道我的卡夫卡音源每分钟产生650万条记录
• 卡夫卡“阅读器”的并行性等于卡夫卡分区的并行性

当我观察这项工作（通过flink UI）约1分钟时，我看到的值如下：

• 卡夫卡->减少：发送约150万条记录（减少超过4倍）
• 减少（5秒的加窗聚合）->db写入~114K条已发送记录（关闭次数>2x）1
• 接收到的数据库写入-->记录：~23K（关闭时间>5x）2

（其他零件的发送/接收值之间的差异较小，但我可以将其归因于测量误差）

问题：
1.其余的记录在哪里？
2.运行时，此机器上的负载永远不会超过1.5。还有其他限制因素吗？
3.我是否误读了UI中的值

Java 8
Flink 1.0（最新的github）
机器：32芯/96 Gb RAM

1这可以用聚合过程来解释。

---

2该值与写入数据库的值一致。

Flink不会丢失记录，它们只是在飞行中缓冲，或者在卡夫卡停留更长时间。从数字上看，您似乎正在经历背压

您可以看到，“reducer”发出了许多“db writer”尚未接收到的记录。在这种情况下，这些记录仍在操作员之间通信通道的缓冲区中。这些通道的缓冲量有限（取决于配置的缓冲区数量，通常为几MB）。对于小型记录，它们可能会保存多个10k记录

如果一个运营商中发送的记录数持续显著落后于接收运营商中接收的记录数，则这表明接收器（此处为“db写入器”）无法跟上数据速率。可能是因为DB处理插入的速度不够快（太同步，太细粒度提交？），可能是“DB编写器”和DB之间的网络饱和了

在这种情况下，“db编写器”将对减压器进行背压，最终也将对卡夫卡震源进行背压

为了测试如果没有来自数据库的背压，数据速率会是多少，您可以尝试一个“db writer”简单地删除所有记录的实验