Kafka 持久状态存储与内存状态存储答案

【问题标题】：Kafka persistent statestore vs in memory state storeKafka 持久状态存储与内存状态存储
【发布时间】：2019-07-16 10:56:31
【问题描述】：

我们正面临一个问题，我们正在使用 kafka 持久状态存储，并且它经常用完空间 (8gb)，因此我们正在考虑迁移到内存状态存储

Stores.persistenKeyValueStore("name");

到

Stores.inMemoryKeyValueStore("name");

如果我们在内存中更改，就没什么问题了

切换到内存还有其他缺点吗？

请注意，我们有流式应用程序 (KTable) 并且有大约 200 万条独特的消息。

每个消息的大小约为 2kb 频率 500msg/sec 平均

【问题讨论】：

【解决方案1】：

空间不足 (8gb)，因此我们正在考虑转移到内存状态存储中

切换到内存存储似乎是一种倒退？ 8GB 也比较小——为什么你有这么小的磁盘？

如果代理/消费者重启，我们会丢失任何数据吗？

没有。持久存储只是增加启动时间和保持更大状态的能力（因为它们可以溢出到磁盘）的优化。持久存储和内存存储都由 Kafka 集群中的更改日志主题支持，以实现容错。为了获得适当的容错，您需要在 Kafka Streams 以及独立于存储类型的更改日志主题上应用相同的配置。

如果内存中的旧数据被刷新，消费者如何获取之前的数据，它是否从代理获取该数据？

如果您使用内存存储，则客户端始终保存数据集的完整副本。因此，您的数据集必须适合主内存。写入 Kafka 集群仅用于容错。在正常操作期间，Kafka Streams 仅写入更改日志主题。仅当迁移任务并且需要重建存储时才会读取更改日志主题。

切换到内存还有其他缺点吗？

如前所述，缺点是： - 您失去了滚动重启的本地状态，并且需要从更改日志主题中恢复状态，从而增加启动时间 - 你的状态必须适合主内存

【讨论】：

你的意思是如果流不能放入主内存，它就不能工作？如果状态超过 32g，我们的主要内存是 32g，它不像 lru 缓存或其他东西那样工作吗？它清理一些数据并加载当前和需要旧数据时它从更改日志主题（而不是本地状态存储在持久的情况下）获取。
You mean streams wont work if it cannot fit in main memory? -- 正确。没有 LRU 或类似机制——如果您使用内存存储，所有数据都必须适合主内存。这就是 Kafka Streams 默认使用持久存储的原因——以允许处理更大的状态。
那么当使用持久化存储时，我们如何配置要保存在内存中的数据大小呢？
对于记录缓存有一个max.cache.bytes.buffering 配置，对于RocksDB，您可以实现RocksDBConfigSetter 接口并通过rocksdb.config.setter 配置进行配置。