Kafka Broker宕机时，聚合、窗口化等状态化操作会如何变化？

当执行聚合、窗口化这类状态化操作时，负责的Broker宕机后，状态不会完全丢失，新Leader Broker当选后可以继续执行，具体细节如下：

• 状态数据的持久化保障：状态化操作的中间结果（比如聚合累计值、窗口内的事件数据）会被持久化到Kafka的内部changelog主题，这类主题默认配置了多副本（可通过replication.factor调整，通常设为3）。当承载Leader副本的Broker宕机，Kafka集群会自动为changelog主题选举新的Leader，状态数据通过副本机制得以保留。

• 任务迁移与状态恢复：Broker宕机后，Kafka Streams会触发任务重新平衡，将故障Broker上的状态化任务分配到集群内其他存活的Broker。新接管任务的Broker会从changelog主题的最新偏移量同步状态数据，完成恢复后即可继续处理后续数据流，无需从头重试整个任务。

• 本地状态的角色：每个任务的本地状态存储（如RocksDB）只是changelog主题的缓存，任务迁移时，新Broker会重新同步changelog数据构建本地状态，不会依赖故障Broker的本地存储。

注意：只有当changelog主题的所有副本所在Broker全部宕机时，才会出现状态丢失，但这属于极端故障场景。重新平衡和状态恢复过程会导致操作暂时停顿，但恢复后会无缝继续执行。

内容的提问来源于stack exchange，提问作者Mostafa Hamid