有没有办法计算随着时间的推移，KTable/KStream 在 java/scala 应用程序中将使用多少堆（或任何其他）内存？
我有一些具体的假设，我想知道它们是否正确：
Kafka 流仅使用内部主题和 RocksDB。
RocksDB 是嵌入式数据库，因此它使用我的应用程序的堆内存。
KStream 不断从 RocksDB 中删除所有记录，因为它们不再被拓扑中的任何处理器使用（例如，用于与指定 JoinWindow 的连接）（== 没有使用太多内存）
KTable 完全存储在 RocksDB 中（== 在内存中）
当 KTable 收到空值记录时，它会从 RocksDB 中删除记录（== 已释放内存）
【问题讨论】：
标签： memory apache-kafka apache-kafka-streams confluent-platform
很难估计。对于一般尺寸，请参考本指南：https://docs.confluent.io/current/streams/sizing.html
Kafka 流仅使用内部主题和 RocksDB。
是的。您还可以将 RocksDB 替换为内存存储（属于 Kafka Streams 的一部分）或实现您自己的自定义存储。
RocksDB 是嵌入式数据库，因此它使用我的应用程序的堆内存。
RocksDB 使用堆外内存，也会溢出到磁盘。
KStream 不断从 RocksDB 中删除所有记录，因为它们不再被拓扑中的任何处理器使用（例如，与指定的 JoinWindow 连接）（== 没有使用太多内存）
这取决于商店类型。对于键值存储（即“常规”KTables），数据不会被删除（显式删除消息除外，即所谓的墓碑）。对于时间窗口/会话窗口 KTable（窗口聚合的结果）和连接，有一个保留期，之后数据将被删除。
KTable 完全存储在 RocksDB 中（== 在内存中）
RocksDB 也会溢出磁盘。它不仅在内存中。
当 KTable 接收到空键记录时，它会从 RocksDB 中删除记录（== 释放内存）
null-key 记录没有格式错误。我假设您的意思是null-value 记录，即所谓的墓碑。这些被视为删除。
【讨论】：