同城双活核心是保障数据不冲突、读不跨房、故障不丢数、切换不中断，需围绕一致性、流量调度、故障响应系统设计：金融类用raft/paxos强同步（rpo=0），订单类用半同步，日志类用异步+kafka；读写必须本机房闭环，通过单元化路由、本地优先中间件、双活redis实现；故障切换须自动化无感，rto趋近于0。
核心数据库实现同城双活，关键不在“能不能同时写”，而在于“怎么写不冲突、读不跨房、故障不丢数、切换不中断”。它不是简单堆两个主库，而是围绕数据一致性、流量调度、故障响应三根主线系统设计。
数据同步机制要分场景选型
同城机房间网络延迟通常在1–2ms，为强一致提供了物理基础，但不同业务对一致性的容忍度差异很大：
- 金融账务类系统：必须RPO=0（零数据丢失），推荐基于Raft或Paxos的强同步方案（如MySQL Group Replication、YashanDB融合集群），写入需多数节点落盘才返回成功；
- 订单/用户资料类系统：可接受毫秒级延迟，用半同步复制更平衡性能与安全——主库写入后，至少一个同城从库确认接收binlog即响应，失败时自动降级为异步；
- 日志/统计类数据：直接走异步复制+消息队列（Kafka）兜底，避免拖慢核心链路。
读写流量必须本机房闭环
跨机房读写是同城双活最大的隐性性能杀手。即使延迟只有2ms，高频调用也会累积成百毫秒级延迟。因此必须切断跨机房数据访问路径：
- 应用层按用户ID哈希或地域标签做单元化路由，确保同一用户请求始终落在同机房内完成全链路（含DB读写、Redis访问、MQ收发）；
- 数据库中间件（如ShardingSphere、MyCat）配置本地优先策略：先查本机房主/从库，仅当本机房全部不可用时，才允许fallback到同城另一中心；
- 缓存层双活部署Redis集群，客户端SDK强制优先访问本地机房节点，未命中再穿透至本地从库，严禁直连异地缓存。
故障切换必须自动化且无感
人工切库意味着分钟级中断，违背双活初衷。真正的同城双活要求RTO
- 注册中心（如Nacos、Eureka）与数据库健康状态联动：当检测到主库连续三次心跳失败，5秒内触发服务实例下线，并通知负载均衡器（F5-LTM或Nginx）屏蔽该机房入口；
- DNS层用F5-GTM做智能解析，结合topology算法按运营商、地理位置就近调度，故障时200ms内完成全局流量重定向；
- 数据库自身需支持自动选主：如MySQL MGR集群在多数节点存活时，10秒内完成新主选举并更新集群视图，应用无需重启即可重连。
数据一致性要有兜底与验证手段
再可靠的同步机制也需防御小概率异常：
- 每日定时执行跨机房数据比对（如pt-table-checksum），识别微小差异并生成修复SQL；
- 关键表增加逻辑版本号（version）和更新时间戳（updated_at），应用层写入时校验版本，冲突则由业务决定合并策略；
- 所有变更操作记录到独立审计库，并通过消息队列广播至各中心，用于构建统一的数据变更视图，支撑实时稽核。
