1

当对 a 的基础主题进行更新时GlobalKTable，所有应用程序实例KStream获取最新数据的逻辑是什么？以下是我的后续问题：

  1. GlobalKTable当更新发生时，是否会被锁定在记录级别或表级别？
  2. 根据这篇博客：Kafka GlobalKTable Latency Issue，延迟可以达到 0.5s 吗？！如果是这样，有没有其他方法可以减少延迟？
  3. 由于GlobalKTable默认使用 RocksDB 作为状态存储，RocksDB 的所有功能都可以使用吗？

我了解GlobalKTable不应将其用于需要频繁更新查找数据的用例。是否有任何其他键值存储可用于可能需要更新表数据的用例 - 例如 Redis？

我找不到太多关于GlobalKTable其内部结构的文档。有可用的文件吗？

4

2 回答 2

2

GlobalKTables 是异步更新的。因此，无法保证不同实例何时更新。

此外，“全局线程”使用专用的“全局使用者”，您可以单独微调以减少延迟：https ://docs.confluent.io/current/streams/developer-guide/config-streams.html#naming

RocksDB 通过 JNI 集成，JNI 接口并没有暴露 RocksDB 的所有功能。此外，“表”抽象“隐藏”了 RocksDB，因此有些扩展。rocksdb.config.setter但是，您可以通过( https://docs.confluent.io/current/streams/developer-guide/config-streams.html#rocksdb-config-setter )调整 RocksDB 。

于 2020-06-03T01:32:58.980 回答
0

Javadocs forKStream#join()非常清楚，仅GlobalKTable在处理流中的记录时才发生连接。因此，要回答您的问题，底层 s 不会发生自动更新KStream：需要在其中处理新消息才能看到更新。

“表查找连接”意味着只有在处理 KStream 记录时才会计算结果。这是通过在当前内部 GlobalKTable 状态中查找匹配记录来完成的。相比之下，处理 GlobalKTable 输入记录只会更新内部 GlobalKTable 状态，不会产生任何结果记录。

  1. 如果 aGlobalKTable被具体化为键值存储，则大多数用于迭代和变异KeyValueStore实现的方法都使用synchronized关键字来防止来自多个线程同时更新状态存储的干扰。

  2. 您可以通过使用内存中键值存储或使用自定义状态存储实现来减少延迟。

  3. 例如KeyValueStore，与状态存储的交互是通过 Kafka Streams 中的一组接口控制的，因此从这个意义上说，您并没有直接与 RocksDB API 交互。

于 2020-05-31T20:00:39.917 回答