Kafka GlobalKTable 延迟问题答案

【问题标题】：Kafka GlobalKTable Latency IssueKafka GlobalKTable 延迟问题
【发布时间】：2019-01-09 06:49:12
【问题描述】：

我有一个主题被读作 GlobalKTable 并在商店中实现。问题是，如果我更新主题的键，然后从存储中读取，一段时间（~0.5 秒）我会得到旧值。

此问题的原因可能是什么？

globalktable 是否将数据存储在每个应用程序实例的 RocksDB 中，所以如果更新另一个分区上的键，则需要一些时间从所有分区中提取数据并更新其本地 RockDB。如果不是，请解释 globalktable 存储如何在内部维护其状态？

如何解决上述问题？我们是否应该在期望一致性与 mysql 数据库相匹配的情况下使用 globalktable？

【问题讨论】：

【解决方案1】：

globalktable 是否将数据存储在每个应用程序实例的 RocksDB 中，所以如果更新另一个分区上的键，则需要一些时间从所有分区中提取数据并更新其本地 RockDB。如果不是，请解释一下 globalktable store 是如何在内部维护它的状态的？

绝对是的。在 Kafka Streams poll() 主题再次更新并更新到本地 RocksDB 之前，总会有一些延迟。

我们是否应该在期望一致性与 mysql 数据库相匹配的情况下使用 globalktable？

这取决于您需要什么保证——如果生产者写入 GlobalKTable 主题并且写入成功，这并不能保证 Kafka Streams 应用程序已使用此写入并更新了 GlobalKTable。在 Kafka 中，生产者和消费者在设计上是解耦的。

【讨论】：

有什么选择吗？最后一段正是我所处的情况。
atm 能做的不多。您可以尝试通过设置相应的消费者/生产者配置来减少写入和读取的延迟——但这当然可能会降低吞吐量。这是一个经典的“延迟与吞吐量”和异步处理问题。
非常感谢！我有点害怕这个作为答案。您是否认为可以将延迟设置为 1 毫秒，或者什么是最激进的值，但会完全破坏？
我可以利用exactly_once 语义并在以任何方式访问商店之前检查偏移量吗？是否建议切换到处理器 API？
我不认为只有一次会有帮助。这是异步处理的一个基本问题。注意：对于至少一次和完全一次的情况，只有在消息完全处理后才会提交偏移量。因此，检查已提交的偏移量可能会有所帮助——但是，如果您有重新分区主题，则很难跟踪这些主题之间的偏移量关系。此外，如果提交了偏移量 X 并且您查询存储，您可能已经看到偏移量 X+1 的更新。