当对某个主题的基础主题进行了更新时 GlobalKTable ，所有示例的逻辑是什么 KStream 获取最新数据的应用程序？以下是我的后续问题：
会不会 GlobalKTable 当更新发生时，是否在记录级或表级锁定？
根据这个博客：Kafkaglobalktable延迟问题，延迟能达到0.5秒吗？！如果是这样，有没有其他方法来减少延迟？
自 GlobalKTable 默认情况下使用rocksdb作为状态存储，rocksdb的所有功能都可用吗？
我明白 GlobalKTable 不应用于需要频繁更新查找数据的用例。有没有其他键值存储可以用于可能需要更新表数据的用例（例如redis）？
我找不到关于 GlobalKTable 以及它的内部结构。有可用的文件吗？
2条答案
按热度按时间zbwhf8kr1#
Java文档
KStream#join()很明显，联合反对GlobalKTable仅在处理流中的记录时发生。因此，要回答您的问题，没有发生在底层服务器上的自动更新KStreams:新邮件需要在其中进行处理才能看到更新。“table lookup join”意味着只有在处理kstream记录时才计算结果。这是通过在当前内部globalktable状态下执行匹配记录的查找来完成的。相反，处理globalktable输入记录只会更新内部globalktable状态，不会生成任何结果记录。
如果
GlobalKTable被具体化为键值存储，大多数用于迭代和变异的方法KeyValueStore实现使用synchronized关键字以防止多个线程同时更新状态存储的干扰。您可以使用内存中的键值存储，或者使用自定义状态存储实现来减少延迟。
例如，通过kafka流中的一组接口来控制与状态存储的交互
KeyValueStore因此，在这个意义上，您并不是直接与rocksdbapi交互。chy5wohz2#
globalktables是异步更新。因此，当不同的示例被更新时，没有任何保证。
此外，“全局线程”使用专用的“全局使用者”，您可以单独进行微调以减少延迟：https://docs.confluent.io/current/streams/developer-guide/config-streams.html#naming
rocksdb通过jni和jni接口集成，并不公开rocksdb的所有功能。此外，“表”抽象还“隐藏”了rocksdb，因此有一定的扩展性。但是，您可以调整rocksdb vie
rocksdb.config.setter(https://docs.confluent.io/current/streams/developer-guide/config-streams.html#rocksdb-配置设置程序）。