Kafka Streams State Store：状态为什么也要写回 Kafka

验证：State Store背后真实藏着两个自动创建的内部topic

命令 · shell $ kafka-topics.sh --bootstrap-server localhost:19092 --list | grep wordcount

真实实测 · 本机执行输出

wordcount-windowed-app-word-count-windowed-store-changelog
wordcount-windowed-app-word-count-windowed-store-repartition

这两个topic真实没有在代码里写过一行创建它们的逻辑——Materialized.as("word-count-windowed-store")这一句，真实让Kafka Streams框架自动帮开发者创建了一个changelog topic，命名规则是应用ID-store名字-changelog；因为聚合操作前有一次groupBy真实需要按新的key重新分区，框架还额外真实创建了一个-repartitiontopic。

验证：changelog topic真实记录着状态的每一次变化

State Store本身(本文这个word-count-windowed-store)真实是Kafka Streams应用进程本地的一份数据(默认用RocksDB存在磁盘上)，只在这台机器上——如果这个进程真实崩溃重启，本地状态数据没了怎么办？答案就是changelog topic：每次State Store真实发生变化(比如某个词的计数+1)，这次变化真实会被同时写进changelog topic，相当于给本地状态做了一份持续的、增量的异地备份。进程重启后，Kafka Streams真实会先把changelog topic从头到尾重放一遍，把本地State Store真实重建到崩溃前的最新状态，再继续处理新数据。这也是为什么"状态也要写回Kafka"：State Store本身是本地的、易失的，changelog topic才是它真实的持久化保障，让"有状态的流处理"在真实的进程故障面前，具备了跟"无状态处理"一样的可恢复性。

分步演示：State Store背后真实的两个内部topic

每一步都是本文上面用kafka-topics.sh真实查出来的原始结果。

本地状态的每一次变化，真实都被同步写进了changelog

这一步新验证的topic

参考与说明

数据来自本机3节点Kafka 4.3.1集群，上一篇《Kafka Streams：一条消息如何变成状态存储》里同一个wordcount-windowed-app应用，真实查看它自动创建的内部topic。
没有验证：真实模拟Streams应用进程崩溃重启，验证changelog topic重放重建State Store的完整过程；changelog topic的cleanup.policy=compact压缩机制真实的效果(只保留每个key最新的值，不是无限增长)。

下一篇 · KAFKA 内部原理 76

Window、Join 和时间语义