谈谈PhxSQL的设计和实现哲学（上）

《谈谈PhxSQL的设计和实现哲学（上）》要点：
本文介绍了谈谈PhxSQL的设计和实现哲学（上），希望对您有用。如果有疑问，可以联系我们。

开源地址

https://github.com/tencent-wechat/phxsql

摘要

PhxSQL是一个提供Zookeeper级别强一致和高可用的MySQL集群.PhxSQL完全兼容MySQL,建立在简单可逻辑证明的一致性模型之上,架构、部署、运维简单.文章还讨论了PhxSQL与相关技术方案的区别,并比较了各自的优缺点.

文章比较长,正文分成上下两章.上章主要讨论why,即我们为什么要做PhxSQL以及为什么这样做.下章着重探讨why not,即我们为什么不支持若干特性,例如多主多写和分库分表,及与Galera和MySQL Group Replication的比较等.

正文

PhxSQL[22]发布以来,受到很多关注.作为热爱技术的码农,我们感谢大家的关心和支持,欢迎一切基于技术出发点的讨论.“Show you the code”之后,我们在这里谈谈PhxSQL的设计和实现哲学,也同时回答大家提出的一些疑问.

1. PhxSQL是什么?

PhxSQL是一个通过Paxos保证强一致和高可用的的MySQL集群.PhxSQL建立在Paxos的一致性和MySQL的binlog流水基础上.主要原理简单来说：

1. Paxos选出主机
2. 主机把本机MySQL设置成可写的MySQL主机,在MySQL写binlog流程中拦截binlog流水、发送到Paxos,形成全局的binlog流水
3. 备机把本机的MySQL设置成只读的MySQL备机,MySQL备机从全局binlog中拉取流水,重放和执行,从而主备MySQL一致
4. 针对常见的业务场景,PhxSQL提供两个服务端口：强一致读写端口(ReadWritePort)和只读端口(ReadonlyPort)；对数据要求强一致的业务,通过ReadWritePort来读写；只要求能读取但不要求最新数据的读请求(比如一些定时对账业务),可以通过ReadonlyPort来读取

只要有多于一半机器工作和互联,PhxSQL就可以正常工作.

2. PhxSQL的”强一致“和”高可用“是什么级别?

很多MySQL集群方案都宣称强一致和高可用.PhxSQL这方面有什么不同?

大家熟知的Zookeeper提供强一致和高可用.一致性有很多级别,从强到弱分别是：Strict(严格一致性),Linearizable(线性一致性)[1],Sequential(序列一致性)[2],Causal(因果一致性),Eventual等.具体定义请参见参考文献.严格一致性只是一个理论模型.根据相对论,由于信息传播的速度不可能高于光速,严格一致性在实际中几乎无法实现.线性一致性的理论定义很复杂,不太严谨直观地讲,就是任何一个客户端都可以读到别的客户端写入的最新内容.这也是大家通常理解的强一致.

Zookeeper的强一致指“线性一致性”[3].高可用是说只要多于一半机器工作和互联即可在保证线性一致性的质量下正常工作.PhxSQL的强一致是指“线性一致性”,高可用是指只要多于一半机器工作和互联即可在保证线性一致性质量下工作.即,

PhxSQL提供和Zookeeper相同的强一致性和高可用性!

PhxSQL提供和Zookeeper相同的强一致性和高可用性!

PhxSQL提供和Zookeeper相同的强一致性和高可用性!

重要事情说三遍:).大家可以把PhxSQL当Zookeeper使用,例如用来选主!

在数据库事务隔离方面,PhxSQL支持最高级别的serializable.在性能方面,PhxSQL提供明显优于MySQL半同步的写性能和几乎相同的读性能[22].

细心的读者可能注意到,和通常的“高可用、强一致”说法顺序相反,这个小节的标题中,“强一致”有意放在了“高可用”的前面.在这里需要澄清一个误区.当谈到高可用时,有时会有意无意忽略或者降低一致性.严格意义上来讲,可用性和一致性必须一块讨论,满足一致性要求前提下的可用性才有意义.打个不严谨的比方,一致性就像汽车的“安全性”,可用性就是汽车的“可用性”.如果一辆车号称“可用性”很好,可以连续工作10年,但从来不提“安全性”,那么这辆车的品质是值得怀疑的.

3. 为什么要做PhxSQL?

虽然有很多NoSQL、NewSQL系统、以及多主多写MySQL集群、支持分库分表的MySQL集群,MySQL传统主备同步方案仍然具备很多新系统难以企及的优点.MySQL主备在主机上支持完整SQL、全局事务、以repeatable read和serializable级别的事务隔离,在金融、帐号等关键业务中有巨大的价值.同时,现有复杂MySQL应用迁移到新的非兼容系统成本也很高.

但是MySQL传统主备方案也有其缺点.最明显的就是主机故障后的自动换主和新旧主数据一致性(以及衍生的换主后主备一致性、各个备机之间一致性,这里就不详加讨论了),即所谓的一致性和可用性.

为了解决这个问题,有传统流派：用Zookeeper、etcd、或者其它第三方来检测心跳、选主、和切换.改造MySQL client让其能感知新的主机.或者为了能让传统MySQL client不加修改就能感知新的主机,部署MySQL代理服务器,让其将连到自身的MySQL client请求透明转发给新的主机.为了减少主备间数据的落后,从而降低旧主机故障、某台备机被提升成新主机时,新旧主机之间、新主机和其它备机之间的差异,很多方案在主备同步机制上做了很多有益的工作.例如semi-sync等待多数派备机应答,通过优化线程和网络、主备多通道、备机并行执行binlog流水等尽量减少主备之间差异.如果主备间任何时刻都完全一致,那么任何时刻换主都是强一致的.这句话的另外一个意思是,如果无法保证主备间任何时刻完全一致,那么当有持续不断的更新时,任何时刻的换主都是无法保证强一致的.

传统流派另外一个分支就是将MySQL本地磁盘换成更高可靠性的SAN,当MySQL主机故障时,将SAN挂接到备机上提供服务.而当SAN故障时怎么办?当需要跨机房部署时怎么办?

意识到传统流派的局限性,新出了Galera和MySQL Group Replication等.除了宣称提供强一致性和高可用性外,还支持master-master多点写入等诱人新特性.

世界上目前已知的经过理论证明和实际检验的一致性算法屈指可数：两阶段提交two-phase commit (2PC)、Paxos[4]、Raft[5]、Zookeeper Atomic Broadcast (ZAB)[3]、Viewstamped Replication[5]等.2PC虽然可以保证一致性,但在主机故障时无法工作,存在可用性问题.目前被工业界广泛认可和应用的是Paxos和Raft,2PC一般在前两者帮助选主下使用.这里的一个小建议就是：如果一个分布式系统宣称支持线性一致性级别的强一致和高可用,请先检查它使用的一致性算法.如果是新算法,请检查它的形式化证明或者逻辑证明.

因此,为支持线性一致性和高可用,同时完全兼容MySQL,我们在MySQL的基础上应用Paxos,设计和开发了PhxSQL.

4. PhxSQL的设计原则是什么?

从实际需求出发,除了前述强一致、高可用、完全兼容MySQL这3个明显、必须的设计原则,我们还提出以下3原则.

4.1. 简单可逻辑证明的一致性模型

（编辑：ASP站长网）