去年，腾讯微信团队开源了PhxSQL，使用Multi-Paxos类似的协议来同步集群中各个MySQL实例的Binlog，这个集群生态中包含了很多微信团队的其它组件：
Paxos协议库phxpaxos： http://github.com/tencent-wechat/phxpaxos
RPC通讯库phxrpc： http://github.com/tencent-wechat/phxrpc
以及协程库libco： http://github.com/tencent-wechat/libco
最近，2017年3月，阿里又推出了基于Raft 协议的MySQL 三节点企业版。一时间强一致性协议和MySQL走得很近！在此以前，比较正式的MySQL强一致集群方案有MySQL Group Replication/Galera（http://galeracluster.com/）和腾讯的TDSQL。Group Replication基于Paxos的变种协议Mencius来同步，Galera通过原子广播和基于WriteSet 的冲突检测机制来实现强一致，TDSQL是修复了官方SemiSync Replication技术存在的一些问题，同时加上工程上租约选主等手段来实现强一致。
Paxos和Raft都是用于解决分布式系统一致性的协议，Paxos更是历史悠久变种无数。我们从PhxSQL和阿里三节点企业版的架构来看看两者之间的差异，看似同为一致性协议的工程化应用，实际的差异还是不小！先看PhxSQL的系统架构：
（图片来自PhxSQL公开分享）
从上面的架构图可以看到，这里的Phxsync就是MySQL的一个插件，代码中实现其实就是在MySQL Semisync插件的基础上做了一些修改，原生Semisync插件遵循半同步协议把Binlog发给Slave，等待Slave回应Binlog事件所对应的Binlog File Name和Offset。Phxsync插件通过RPC把Binlog发给PhxBinlogSvr。PhxBinlogSvr之间通过Paxos协议进行同步。抛去Proxy 等环节不说，一次事物提交的复制阶段开销包含（假定PhxBinlogSvr之间的RTT相同）：
TReplication Latency =
RTTPhxsync 2 PhxBinlogSvr + RTT PhxBinlogSvr（L）2 PhxBinlogSvr（F）
这样我们可以看出，提交的性能之一取决于PhxBinlogSvr（Leader）部署位置和MySQL Master之间的RTT，所以一般PhxSQL的部署是PhxBinlogSvr和MySQL实例成对出现，部署在同一台物理机器上面。
当然，总结这篇文章的目的是强调这样的两种场景：
PhxBinlogSvr（Leader或者叫Master）宕机的情况下，事物提交会Block住，要么等待PhxBinlogSvr（Leader）被拉起，要么等Leader租约过期后切换到其它MySQL + PhxBinlogSvr对上面去。
Phxsync和PhxBinlogSvr之间的RPC通讯抖动，事物提交也会Block住，当然这个在同机部署的情况下是低频率事件。
也就是说，PhxSQL中事务提交对PhxBinlogSvr（Leader）的可靠性以及Phxsync和PhxBinlogSvr之间的通讯非常敏感！
再来看阿里三节点企业版的架构：
（图片来自阿里云官网）
在 AliSQL 内核中引入 Raft 协议，借助 MySQL Semi-sync Replication 实现日志多副本同步复制。Raft 是强Leader的协议，正好MySQL的主从复制是一种Primary-Backup的模型，所以个人也是认为两者是比较合拍的。Multi-Paxos虽然也有Leader的角色，但是Leader的存在是为了在一定条件下优化一致性的达成效率，而不是必须要存在的，所以Multi-Paxos不是一种强Leader的协议。除去Raft协议简单容易理解不说，我们仍然回到这篇文章强调的场景上来：
无论部署在哪里，同机或者远程，一个Slave的宕机不会影响事务的提交。
Master和一个Slave之间的网络抖动不会影响事务的提交。
完全和其它MySQL兼容，不像PhxSQL引入了那么多的组件～
总而言之，Raft更适合Primary-Backup Replication，Multi-Paxos更适合Multi-Primary Replication。如果基于传统的MySQL复制体系，它本来就是一种Primary-Backup Replication，Raft看上去更合适一些！MySQL Group Replication就是典型的Multi-Primary Replication，所以它也采用了Paxos的变种协议Mencius。
