分布式环境下的主从数据同步

1. 数据同步的推/拉方式

1.1 主节点推送

1.2 从节点拉取

1.3 常见组件的推拉方式

2.复制方式

2.1 同步复制

2.2 异步复制

2.3 半同步复制

2.4 常见组件的同步方式

3.日志格式

3.1 基于语句复制 SBR

3.2 基于行复制 RBR

3.3 基于预写日志 WAL

3.4 基于触发器复制

4.不同复制架构下的同步机制

4.1 单主复制 Single Leader

4.2 多主复制 Multi Leader

4.3 无主复制 LeaderLess

4.4 分片集群 Sharding

5.主从数据一致性问题

5.1 写后读一致性

5.2 单调读

5.3 一致前缀读

1. 数据同步的推/拉方式

从数据同步如何触发的角度来看，有两种常见模式。根据实时性要求、系统规模、网络条件等进行选择。

1.1 主节点推送

当主节点数据变更时，主动向所有从节点推送新数据。

优点：

实时性好：主节点有数据变更时可以立即通知从节点，减少延迟。
负载均衡：主节点可以根据从节点的状态（如网络状况、处理能力等）分配任务。
降低从节点负担：从节点不需要定期轮询主节点，减少网络和CPU占用。

缺点：

复杂度高：需要维护一个可靠的通信机制，并且要处理可能出现的网络问题、同步丢失问题。
扩展性挑战：随着从节点数量的增加，主节点可能成为瓶颈。

1.2 从节点拉取

从节点定期询问主节点是否有数据更新，有则拉取新数据。

优点：

灵活性好：从节点轮询请求主节点，可根据自身情况调整拉取频率。
易扩展：新增从节点时，只需配置好拉取逻辑即可，对主节点的影响较小。

缺点：

存在延迟：取决于从节点设置的检查间隔，不能保证数据的即时一致性。
增加主节点压力：频繁的轮询会增加主节点的负载。
效率较低：即使没有新数据更新也需要发起查询请求，浪费资源。

1.3 常见组件的推拉方式

组件	同步方式
MySQL	从节点拉取（通过 binlog 实现）
Etcd	主节点推送(raft 协议同步数据) + 从节点拉取(心跳)
MongoDB副本集	从节点拉取（通过 oplog 实现）
Redis	从节点拉取(异步复制) + 主节点推送(首次全量同步)
ZooKeeper	主节点推送(ZAB 协议同步数据) + 从节点拉取(心跳)

2.复制方式

2.1 同步复制

leader 节点等待所有 follower 节点确认已接收到并处理完数据后，才执行后续操作。

优点：数据高度一致性

缺点：可能会导致性能瓶颈，特别是在网络延迟较高的情况下

适用场景：高一致性要求、分布式协调（如 etcd 的 raft 协议）

2.2 异步复制

leader 节点不需等待 follower 返回，直接继续后续操作。

优点：性能好，实时性高

缺点：数据同步有延迟，数据一致性较低

适用场景：日志分析、社交媒体等一致性要求不高的系统

2.3 半同步复制

介于同步复制和异步复制之间的一种折衷方案。在这种模式下，只要一个 follower 返回之后，leader 就可以进行下一步操作。

这种方式既保证了一定程度的数据一致性，又避免了完全同步复制带来的性能损耗。

适用场景：MySQL 半同步复制、MongoDB 的 w:majority 模式

注意：共识算法并不是半同步模式而是强同步模式，因为半同步只需 1 个节点返回即可，存在数据丢失风险；但是共识算法要求多数节点返回，是严格保证一致性的。

2.4 常见组件的同步方式

组件	默认同步方式	一致性级别	其他同步方式支持
MySQL	异步	可调（最终→强）	支持半同步（插件配置，需至少1个从节点确认），组复制（多数节点同步）
PostgreSQL	同步（流复制）	可调	可配置为异步（synchronous_commit=off），支持同步提交（remote_apply严格同步）
MongoDB	异步	可调（w:1→w:majority）	通过写关注（Write Concern）配置半同步（如w:majority+j:true）
Redis	异步	弱一致性	可使用WAIT命令，手动等待指定个数的节点复制完成，但本质还是异步的
Etcd	同步（Raft）	强一致性	不支持
Kafka	异步（acks=1）	可调	acks=all（等待所有节点确认）， min.insync.replicas控制最小同步副本数