Apache kafka 全局表刷新逻辑

当对

GlobalKTable

的基础主题进行更新时，

KStream

应用程序的所有实例获取最新数据的逻辑是什么？以下是我的后续问题：

更新发生时，

GlobalKTable

会锁定在记录级还是表级

根据这个博客：，延迟能达到0.5s吗？！如果是，是否有其他方法可以减少延迟

由于

GlobalKTable

默认使用RocksDB作为状态存储，RocksDB的所有功能都可用吗

我理解

GlobalKTable

不应用于需要频繁更新查找数据的用例。是否有任何其他键值存储可以用于可能需要更新表数据（例如Redis）的用例

我找不到太多关于

GlobalKTable

及其内部结构的文档。有可用的文档吗？

很清楚，只有在处理流中的记录时，才会发生针对

GlobalKTable

的连接。因此，为了回答您的问题，底层的

KStream

s没有自动更新：需要在其中处理新消息才能看到更新

“表查找联接”意味着，仅当KStream 记录被处理。这是通过对执行查找来完成的 匹配当前内部GlobalKTable状态中的记录。在里面 相反，处理GlobalKTable输入记录只会更新 内部GlobalKTable状态，不会生成任何结果记录

如果一个

GlobalKTable

被具体化为一个键值存储，那么大多数迭代和变异

KeyValueStore

实现的方法都使用

synchronized

关键字来防止多个线程同时更新状态存储的干扰

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

与状态存储的交互是通过Kafka流中的一组接口控制的，因此从这个意义上讲，您不是直接与RocksDB API交互

---

GlobalKTables是异步更新。因此，当不同的实例被更新时，没有任何保证

此外，“全局线程”使用专用的“全局使用者”，您可以单独微调以减少延迟：

---

RocksDB通过JNI和JNI接口集成，并不公开RocksDB的所有功能。此外，“表”抽象“隐藏”了RocksDB，因此有些扩展。但是，您可以调整RocksDB vie

RocksDB.config.setter

（）。

谢谢@ck1。我有几个后续问题。问题顺序：1。

synchronized

关键字在整个表上还是在特定的键值对上？如果有Javadoc，你能给我指一下吗？2.

GlobalKTable

本身被具体化为内存中的键值存储，我的理解是否正确？您是否建议

GlobalKTable

存在延迟问题，最好使用不同的内存键值存储？3.我知道我们不能直接与RocksDB交互，但我们能通过Kafka Streams API以某种方式配置RocksDB吗？明白了。如果我们看一个实例，更新是异步的吗？从这个意义上说，当一个流正在处理时，它会暂停执行以更新

GlobalKTable

，还是会按原样继续，并且实例获取最新的数据是异步的？全局状态/表是使用专用线程更新的，因此处理是“常规的”输入主题并行发生。