主备切换后多线程竞争本质是状态不一致与访问冲突，需通过强一致状态源、写调度器收敛、epoch校验防脑裂、连接主动失效四层机制协同解决。
主备切换后多线程并发竞争，本质是角色变更引发的“状态不一致”和“访问冲突”，不是单纯加锁就能解决的问题。关键在于**切换过程可控、状态感知及时、资源访问有界**。
明确主备切换的触发边界
多线程竞争往往源于多个线程在切换窗口期对同一资源（如连接池、缓存句柄、写入通道）做出不同判断。必须让所有线程清楚知道“当前谁是主”——不能靠轮询或本地缓存，而要依赖统一、强一致的状态源：
- 使用高可用协调服务（如 etcd、ZooKeeper 或 Redis Sentinel）作为主节点注册中心，所有线程启动时监听主节点变更事件
- 禁用本地静态变量存储主库地址；每次写操作前，通过轻量级接口（如 /api/leader）确认当前主节点，配合短 TTL 缓存（如 200ms）降低开销
- 在切换完成广播后，设置一个短暂的“静默窗口”（如 300ms），期间拒绝新写请求，避免残留请求打到旧主或未就绪的新主
隔离写操作的线程执行路径
不要让所有线程直连数据库连接池并自行决定是否可写。应将写能力收口为统一的“写调度器”：
- 写请求统一进入内存队列（如无锁 RingBuffer 或 BlockingQueue），由单个调度线程消费；该线程负责校验主节点有效性、重试降级逻辑、熔断控制
- 业务线程只负责提交任务，不持有连接、不解析 SQL、不处理失败重试 —— 避免多个线程同时尝试重建连接或重连旧主
- 若采用连接池（如 HikariCP），配置 connection-test-query + validation-timeout，确保获取连接前自动剔除失效连接，而不是让线程拿到坏连接再抛异常
利用版本号或任期号防止脑裂写入
即使网络分区恢复，也要阻止旧主重新接受写入（即“脑裂”）。MySQL、etcd、Raft 等都依赖任期（term）或 epoch 编号：
- 每次成功选举出新主，生成唯一递增的 epoch ID，写入共享存储（如 etcd 的 key /cluster/leader-epoch）
- 所有写请求携带当前客户端已知的 epoch；主节点收到请求时比对，若请求 epoch 小于当前 epoch，直接拒绝（返回 StaleEpochError）
- 客户端捕获该错误后，强制刷新 leader 地址并重试，而非盲目重发 —— 从协议层切断过期请求的传播链
连接与会话级资源做主动失效
切换后，旧主上的连接、事务、临时表等不会自动消失。需主动清理，避免线程复用残留上下文：
- 切换通知到达时，主线程向所有工作线程发送中断信号（如 Java 的 Thread.interrupt() 或 C++ 的 std::stop_token），要求其放弃当前事务、关闭连接、清空本地缓存
- 数据库连接池配置 remove-abandoned-on-borrow=true 和合理超时（如 remove-abandoned-timeout=60），确保被遗弃连接能被及时回收
- 避免跨线程共享 Connection / Session 对象；每个线程使用独立连接，生命周期绑定线程请求周期
不复杂但容易忽略：竞争不是出现在切换“那一刻”，而是出现在切换前后几十毫秒的状态模糊期。控制住状态同步粒度、写入口收敛性、请求合法性校验这三层，多线程自然退回到有序协作。
