globalktable刷新逻辑

pzfprimi  于 2021-06-05  发布在  Kafka
关注(0)|答案(2)|浏览(574)

当对某个主题的基础主题进行了更新时 GlobalKTable ,所有示例的逻辑是什么 KStream 获取最新数据的应用程序?以下是我的后续问题:
会不会 GlobalKTable 当更新发生时,是否在记录级或表级锁定?
根据这个博客:Kafkaglobalktable延迟问题,延迟能达到0.5秒吗?!如果是这样,有没有其他方法来减少延迟?
GlobalKTable 默认情况下使用rocksdb作为状态存储,rocksdb的所有功能都可用吗?
我明白 GlobalKTable 不应用于需要频繁更新查找数据的用例。有没有其他键值存储可以用于可能需要更新表数据的用例(例如redis)?
我找不到关于 GlobalKTable 以及它的内部结构。有可用的文件吗?

zbwhf8kr

zbwhf8kr1#

Java文档 KStream#join() 很明显,联合反对 GlobalKTable 仅在处理流中的记录时发生。因此,要回答您的问题,没有发生在底层服务器上的自动更新 KStream s:新邮件需要在其中进行处理才能看到更新。
“table lookup join”意味着只有在处理kstream记录时才计算结果。这是通过在当前内部globalktable状态下执行匹配记录的查找来完成的。相反,处理globalktable输入记录只会更新内部globalktable状态,不会生成任何结果记录。
如果 GlobalKTable 被具体化为键值存储,大多数用于迭代和变异的方法 KeyValueStore 实现使用 synchronized 关键字以防止多个线程同时更新状态存储的干扰。
您可以使用内存中的键值存储,或者使用自定义状态存储实现来减少延迟。
例如,通过kafka流中的一组接口来控制与状态存储的交互 KeyValueStore 因此,在这个意义上,您并不是直接与rocksdbapi交互。

chy5wohz

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-配置设置程序)。

相关问题