我认为是这样。rocksdb用于保存状态，以便在执行需要状态本身的操作时更快。如前所述，状态更改也存储在kafka主题中，因此，如果当前streams应用程序示例失败，另一个示例（在另一个节点上）可以使用该主题重新构建本地状态，并继续像前一个示例一样处理流。

我的应用程序有一些聚合/窗口操作，所以它有一些状态存储，存储在 state.dir . 另外，它还将状态存储的changelog写入代理，因此可以将kafka流应用程序视为无状态pod吗？
无状态pod和数据安全（=无数据丢失）：是的，就数据安全而言，您可以将应用程序视为无状态pod；i、 e.不管pod kafka和kafka流发生了什么，它们都保证您不会丢失数据（如果您只启用了一次处理，它们也将保证后者）。
这是因为，正如您已经说过的，应用程序中的状态更改总是通过相应状态存储的changelogs不断地备份到kafka（代理），除非您显式地禁用了这个changelog功能（默认情况下是启用的）。
注意：当您使用的不是kafka的streams默认存储引擎（rocksdb）而是另一种内存存储引擎时，上述情况甚至是正确的。许多人没有意识到这一点，因为他们读取“内存”并（错误地）得出结论“当一台机器崩溃、重启等时，数据将丢失”。
无状态pod和应用程序恢复/恢复时间：如上所述，您应该了解在pod重新启动后是否有可用的本地状态将影响应用程序（或者更确切地说：应用程序示例）的恢复/恢复时间，直到它再次完全运行。
假设有状态应用程序的一个示例在一台计算机上运行。它将把当地的州储存在 state.dir ，它还将不断地将对其本地状态的任何更改备份到远程kafka集群（代理）。
如果应用程序示例正在重新启动，并且没有访问其上一个示例的权限 state.dir （可能是因为它是在另一台机器上重新启动的），它将通过从kafka中关联的changelog中还原来完全重建其状态。根据状态的大小，这可能需要毫秒、秒、分钟或更长时间。只有在其状态完全恢复后，它才会开始处理新数据。
如果应用程序示例正在重新启动并且确实可以访问其以前的 state.dir （可能是因为它是在同一台原始计算机上重新启动的），它可以更快地恢复，因为它可以重新使用所有或大部分现有的本地状态，因此只需要从关联的changelog恢复一个小的增量。只有在其状态完全恢复后，它才会开始处理新数据。
换句话说，如果您的应用程序能够重用现有的本地状态，那么这是很好的，因为它将最小化应用程序恢复时间。
无状态环境中的备用副本：但是即使您运行的是无状态pod，您也可以通过配置应用程序以使用备用副本来最小化应用程序恢复时间 num.standby.replicas 设置：
num.standby.replicas副本数
备用副本的数量。备用副本是本地状态存储的卷影副本。kafka streams会尝试创建指定数量的副本，只要有足够的示例在运行，就会使副本保持最新状态。备用副本用于最小化任务故障转移的延迟。以前在失败示例上运行的任务最好在具有备用副本的示例上重新启动，这样就可以最小化从其changelog恢复本地状态存储的过程。
另请参阅文档部分工作负载重新平衡期间的状态恢复
更新2018-08-29：在kubernetes上运行kafka/kafka streams/ksql最方便的方法是使用confluent操作符或confluent提供的helm图表，参见https://www.confluent.io/confluent-operator/. (免责声明：我为confluent工作。）
更新2019-01-10：还有一个youtube视频演示了如何用kubernetes缩放Kafka流。

kstreams使用底层 state.dir 用于本地存储。如果pod get在同一台机器上重新启动，并且卷已装入，它将立即从原来的位置恢复。
如果pod在本地状态不可用的另一台机器上启动，kstreams将通过重新读取支持的kafka主题来重建状态
一段简短的视频https://www.youtube.com/watch?v=oikzg7_vy6a 展示了如何在kubernetes上部署和扩展kstream应用程序（对于apachekafka）