主备切换不丢消息的关键是全链路可靠性保障：生产者需同步确认+强制路由，Broker端须强一致复制（如Quorum队列或acks=all），消费者依赖手动ACK与高可用位点管理，元数据由Raft或ZooKeeper等协调。
主备切换要真正实现“不丢消息”，关键不是切换动作快，而是整个链路在切换前、切换中、切换后都有明确的可靠性保障机制。单纯依赖自动选主或脚本重启，大概率会丢数据。
生产者端：写入必须等主节点确认
消息不能发出去就不管了。必须开启同步发送 + 强确认模式：
- RabbitMQ：启用 publisher confirms，并设置
mandatory=true，确保消息到达交换机且被路由到队列；队列需配置为镜像队列（Mirrored）或仲裁队列（Quorum），且写入策略要求多数副本落盘才返回 ack - Kafka：生产者设置
acks=all，同时min.insync.replicas > 1，保证 Leader 写入时至少有 1 个 Follower 同步成功 - RocketMQ：使用同步刷盘（SYNC_FLUSH）+ 主从同步复制（SYNC_MASTER）模式，避免仅异步复制导致主挂后从没来得及同步
Broker 端：主从数据强一致是切换前提
切换不丢消息的前提，是备用节点的数据和主节点完全一致或高度一致。这取决于复制机制：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 异步复制：主写完就返回，从滞后——切换必然丢消息，只适合低可靠场景
- 半同步/多数派同步（如 Kafka ISR、RabbitMQ Quorum Queue）：主等待至少 N-1 个副本写成功再响应，切换时新主一定拥有全部已确认消息
- WAL 日志同步（如 RocketMQ 的 HAService）：主节点将 CommitLog 实时推送给从节点，从节点回放日志追平，切换前校验 offset 是否对齐
消费者端：避免重复或跳过，靠位点管理
主备切换常伴随消费者重平衡或连接重连，此时消费位点（offset）若管理不当，会导致重复或漏消费：
- Kafka：offset 提交到 __consumer_offsets 主题，该主题本身也需多副本 + acks=all，确保位点不丢；推荐手动提交（enable.auto.commit=false），业务处理完成后再 commit
- RabbitMQ：使用手动 ack（noAck=false），且只有业务逻辑执行成功后才调用
basic.ack；镜像队列下，ack 会同步到所有副本，切换后新主仍知道哪些消息已被确认 - 通用原则：消费位点不应存在单点存储，应持久化到高可用外部系统（如 DB 或独立 Topic），而非仅内存或本地文件
元数据与状态：切换过程不破坏一致性
主备身份、Topic 分区归属、消费者组成员关系等元信息，一旦错乱，就会引发脑裂或重复投递：
- Kafka 依赖 ZooKeeper 或 KRaft 模块做集群协调，Leader 选举、ISR 维护、Controller 故障转移都由其保障原子性
- RabbitMQ Quorum Queue 内置 Raft 协议，自动完成 leader 选举与日志复制，无需外部组件
- 避免使用普通集群 + 镜像队列搭配 Keepalived VIP 切换：VIP 可能漂移过早，而队列数据尚未同步完成
