主从复制单向同步、从库只读，双主复制双向同步、两端均可写；前者延迟明显但运维简单，后者易现冲突且脑裂恢复困难，适用场景取决于读写比例、一致性要求与运维能力。
主从复制和双主复制是 MySQL 最常见的两种高可用架构，核心区别在于写入能力分布、数据流向方向、冲突处理机制和运维复杂度。选错架构容易带来延迟、脑裂或写入失败等问题，不能只看“能不能用”，得看业务怎么写、读多还是写多、容错要求有多高。
写入方式与数据流向完全不同
主从复制是单向的：所有写操作必须发给唯一主库（Master），它把变更写进 binlog，再由从库（Slave）拉取并重放。从库只读，不可写。
双主复制是双向的：两台服务器互为对方的主和从，各自都能接受写请求，并把本机的 binlog 同步给对方。相当于两个 Master 在互相复制。
这意味着：
- 主从架构下，应用层必须严格区分读写路由，否则写到从库会失败
- 双主架构下，应用可向任一节点写入，但必须解决同一张表在两端同时写入导致的主键冲突、更新覆盖等问题
- 双主需配置
auto_increment_offset和auto_increment_increment避免自增 ID 冲突（比如 A 用奇数、B 用偶数）
一致性与延迟表现差异明显
主从复制天然存在同步延迟，尤其在大事务、网络抖动或从库性能不足时，从库可能落后几秒甚至几分钟。这对强一致性场景（如订单支付后立刻查状态）是个风险点。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
双主复制同样有延迟，但问题更隐蔽：如果两个节点几乎同时修改同一行，且没做应用层协调，就会出现“后写覆盖前写”或主键冲突报错。MySQL 自身不自动合并冲突，靠 DBA 或中间件兜底。
常见缓解方式包括：
- 启用 GTID，便于精准定位和跳过错误事务
- 使用半同步复制（semi-sync），至少等一个从库落盘才返回成功
- 双主建议搭配 keepalived 或 MHA 做 VIP 漂移，避免手动切换出错
适用场景有明确分界
主从复制适合：
– 读远多于写的系统（如内容展示、报表查询）
– 允许短时延迟的备份/分析/灾备从库
– 架构简单、团队运维经验有限的中小业务
双主复制适合：
– 多地域部署，需要本地低延迟写入（如华东写华东库、华南写华南库）
– 对写可用性要求极高，不能容忍主库单点宕机超过秒级（配合 VIP 或 DNS 切换）
– 已有成熟冲突规避策略，或业务本身写操作天然隔离（如按用户 ID 分片写入不同库）
故障恢复与运维成本对比鲜明
主从架构故障恢复相对可控：主库挂了，选一个延迟最小的从库提升为主，重配其他从库指向新主即可。工具如 MHA、Orchestrator 可自动化完成。
双主架构一旦发生脑裂（网络分区导致两边都以为对方宕机而继续写入），恢复极难：必须人工比对 binlog、合并数据、修复不一致，稍有不慎就丢数据。日常还需监控：
- Seconds_Behind_Master 是否持续为 0
- SHOW SLAVE STATUS 中的 Slave_IO_Running 和 Slave_SQL_Running 是否均为 Yes
- 是否存在 Duplicate entry 或 Deadlock 相关错误
