Kafka Stream故障转移：备用集群迁移最佳实践及注意事项

一、核心最佳实践 #

• 提前同步状态与业务主题
  用Confluent Replicator或Mirror Maker 2持续同步主集群的三类核心主题到备用集群：
  • changelog主题（Stream应用状态存储的持久化主题）
  • __consumer_offsets消费者偏移量主题
  • 业务输入/输出主题
    配置时注意：
  • 保持复制后主题的分区数、副本数与主集群完全一致
  • 开启Exactly-Once复制语义（主集群支持的前提下），避免数据丢重
  • 用topic.rename.format（如main.{topic}→dr.{topic}）区分复制主题，防止命名冲突
• 预部署备用集群的Stream应用
  在备用集群提前部署与主集群完全相同的Stream应用，但保持暂停状态。关键配置要求：
  • application.id必须和主集群应用一致，确保状态存储能匹配加载
  • bootstrap.servers指向备用集群地址
• 无缝衔接消费位点
  • Mirror Maker 2会自动同步消费者组的offset到备用集群的__consumer_offsets；用Replicator的话，需额外配置offset同步任务
  • 故障触发时，先彻底停止主集群的Stream应用，再启动备用集群的应用——启动后应用会自动从同步后的offset位置继续消费
• 定期校验状态一致性
  用Kafka Stream的Interactive Query功能，定期对比主备集群状态存储的核心数据（比如累计交易数、用户账户余额），或者写自动化脚本校验，确保复制的changelog数据完整无差异

二、关键注意事项 #

• 严格避免双写冲突
  切换过程中必须保证主集群应用完全停止后，再启动备用集群的应用。否则两个集群的应用同时处理数据，会直接导致状态混乱、数据重复
• 主题配置必须对齐
  备用集群的主题配置（retention.ms、cleanup.policy等）要和主集群完全一致，尤其是changelog主题——如果备用集群的retention时间更短，会丢失部分状态数据，导致无法恢复到中断点
• 保障复制链路的稳定性
  主备集群之间的复制链路要低延迟、高可用，实时监控复制滞后量（比如Replicator的replication-lag指标），滞后过大时触发告警，避免故障切换后数据追补耗时过长
• 权限与网络隔离
  备用集群的Stream应用必须拥有访问复制后主题、状态存储的完整权限；同时要确保主备集群的网络隔离策略不会影响复制任务和应用启动
• 定期演练故障切换
  模拟主集群宕机场景，定期做故障切换演练，验证备用应用能否正常启动、断点续消费、状态是否一致，演练后及时优化流程

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