是否有一种方法可以计算出Java / scala应用程序中的KTable / KStream随时间推移将大约使用多少堆（或任何其他）内存？
我有一些具体的假设，我想知道它们是否正确：
Kafka流仅使用内部主题和RocksDB。
RocksDB是可嵌入的DB，因此它使用了我的应用程序的堆内存。
KStream在它们不再可以被拓扑中的任何处理器使用（例如，用于与指定的JoinWindow的连接）（==使用的内存不多）后，不断从RocksDB中删除所有记录。
KTable已完全存储在RocksDB中（==内存中）
当KTable接收到空值记录时，它会从RocksDB中删除记录（==已释放内存）
答案 0 :(得分：1)
很难估计。对于一般大小，请考虑以下指南：https://docs.confluent.io/current/streams/sizing.html
Kafka流仅使用内部主题和RocksDB。
是的。您还可以用内存存储（属于Kafka Streams的一部分）替换RocksDB或实现自己的自定义存储。
RocksDB是可嵌入的数据库，因此它使用了我的应用程序的堆内存。
RocksDB使用堆外内存，还会溢出到磁盘上。
KStream在不再被拓扑中的任何处理器使用后（例如，与指定的JoinWindow进行联接）（==使用的内存不多）后，会不断从RocksDB中删除所有记录。
这取决于商店类型。对于键值存储（即“常规” KTable），不会删除数据（明确的删除消息除外，即所谓的逻辑删除）。对于具有时间窗/会话窗的KTables（窗口聚合的结果）和联接，有一个保留期，此后将删除数据。
KTable已完全存储在RocksDB中（==内存中）
RocksDB还会溢出磁盘。它不仅在内存中。
当KTable收到空键记录时，它会从RocksDB中删除记录（==已释放内存）
null键记录没有格式错误。我假设您的意思是null值记录，即所谓的墓碑。这些被视为删除。