技术干货总结：分布式系统常见同步机制(2)

TiKV 使用的是 Raft 协议来实现写入数据时的一致性。参考 三篇文章了解 TiDB 技术内幕——说存储

• 使用 Raft，写入时需要半数以上的节点写入成功才返回，宕机节点不超过半数则数据不丢失。
• TiKV 将数据的 key 按 range 分成 region，写入时以 region 为粒度进行同步。
• 写入和读取都通过 leader 进行。每个 region 形成自己的 raft group，有自己的 leader。

Zookeeper

Zookeeper 使用的是 Zookeeper 自己的 Zab 算法(Paxos 的变种?)，参考 Zookeeper Internals

• 数据只可以通过主节点写入(请求会被转发到主节点进行)，可以通过任意节点读取
• 主节点写入数据后会广播给所有节点，超过半数节点写入后返回客户端
• Zookeeper 不保证数据读取为最新，但通过“单一视图”保证读取的数据版本不“回退”

小结

如果系统对性能要求高以至于能容忍数据的丢失(Redis)，则显然异步的同步方式是一种好的选择。

而当系统要保证不丢数据，则几乎只能使用同步复制的机制，看到 Kafka 和 Elasticsearch 不约而同地使用了 PacificA 算法(个人认为可以看成是 2PC 的变种)，当然这种方法的响应制约于最慢的副本，因此 Kafka 和 Elasticsearch 都有相关的机制将慢的副本移除。

当然看起来 Paxos, Raft, Zab 等新的算法比起 2PC 还是要好的：一致性保证更强，只要半数节点写入成功就可以返回，Paxos 还支持多点写入。只不过这些算法也很难正确实现和优化。

（编辑：ASP站长网）