开源地址：
https://github.com/tencent-wechat/phxsql
点击阅读原文可自动跳转到github地址
PhxSQL是一个兼容MySQL、服务高可用、数据强一致的关系型数据库集群。PhxSQL以单Master多Slave方式部署，在集群内超过一半机器存活的情况下，可自身实现自动Master切换，且保证数据一致性。
PhxSQL基于Percona 5.6开发。Percona是MySQL的一个分支，功能和实现与MySQL基本一致。因此本文后续直接把MySQL作为讨论对象。
MySQL半同步复制存在缺陷，在Master进行切换的场景下，数据难以保证一致。
当旧Master复制失败时，旧Master和Updated Slave（已收到Binlog的Slave）需要回滚数据。
当Master进行切换时，旧Master仍有部分Client进行读写。
关于MySQL半同步复制的数据一致性问题可查看微信后台团队公众号文章MySQL半同步复制的数据一致性探讨。
PhxSQL的设计是为了解决MySQL半同步复制的不足，使MySQL集群在Master切换过程中保证数据的一致。
PhxSQL架构
图1 PhxSQL 三层架构
为了解决MySQL的两个问题（Binlog复制和Master切换），PhxSQL设计了两个模块（Phxbinlogsvr、Phxsqlproxy）和一个MySQL插件（Phxsync）。Phxbinlogsvr负责处理MySQL的Binlog复制和Master管理；Phxsqlproxy负责透传Client请求到Master；Phxsync插件负责MySQL和Phxbinlogsvr的交互。 一台部署了Phxsqlproxy，MySQL和Phxbinlogsvr的机器称为PhxSQL Node。如图1。
PhxSQL复制流程
图2.1 MySQL复制流程
图2.2 PhxSQL复制流程
图2 MySQL和PhxSQL的数据复制流程
在PhxSQL中，Phxbinlogsvr负责管理MySQL的角色和存储MySQL的Binlog，Phxbinlogsvr和其管理的MySQL部署在同一台物理机上。
MySQL Master在Send Event阶段不再把Binlog复制给Slave，而是通过Phxsync插件，把数据复制到Phxbinlogsvr集群。
MySQL Slave也不再从Master获取Binlog，而是从本机的Phxbinlogsvr获取。
Phxbinlogsvr集群使用Paxos协议进行数据复制。
PhxSQL使用PhxPaxos库，详情请查看微信后台团队公众号文章微信自研生产级paxos类库PhxPaxos实现原理介绍。
图3 Phxbinlogsvr形成一个可靠日志存储
图4 重启向Phxbinlogsvr询问PendingBinlog状态
从逻辑上来看，利用Paxos协议进行复制，使Phxbinlogsvr形成一个可靠的日志存储。PhxSQL可以看成是为MySQL增加了一个用Paxos实现的可靠Binlog存储，只要集群中多数派机器存活，就可以解决半同步复制的回滚问题。如图3。
分别从Master和Slave的角度来解释：
Master重启时，通过询问Phxbinlogsvr（多数派）Pending Binlog是否存在来决定是否需要回滚。如图4。
Slave从本机Phxbinlogsvr能拉取到的Binlog都已经经过Paxos协议成功复制到多数派机器，因此对于Slave来说不存在回滚的问题。
Phxbinlogsvr通过Paxos协议复制数据，很好的解决了MySQL中需要手动回滚Binlog和在大集群时同时需要回滚Updated Slave上的Binlog的问题。
PhxSQL的Master管理
图5 多个Master同时写入数据，导致数据不一致
MySQL多Master同时写入会导致数据的不一致。如图5，机器A是旧Master，在收到机器B成为了新Master的消息之前提交了Transaction 3；而同时机器B已成为新Master，Transaction 3则会留在机器A而未复制到机器B，最终两机的数据不一致。
MySQL多Master问题的产生，源于机器间无法得知当前Master的状态，最后导致两台机器的数据不一致。
即使使用外部服务（例如zookeeper）也无法解根本问题。
对Master查询和查询之后的操作不是原子操作，无法保证操作时的准确状态（例如机器A向外部服务查询得知自己是Master，然后执行复制Binlog操作。但期间出现故障导致两个操作之间停顿了很长时间（譬如1天）。在该期间内Master被切换，使得机器A在执行复制Binlog时，已不再是Master，导致了多Master的情况发生。）
Master管理依赖外部服务的稳定性。
多Master问题由于细节太多，暂不在此讨论。
PhxSQL自身进行了Master管理，具有以下特点：
Master通过Paxos协议投票选出。
Master带有租约，并定时续租。租约过期后，需重新选举新的Master。
全局只有1个Master，或者没有Master存在。
有效拒绝过期Master的非法写入。
PhxSQL的Master自动切换
PhxSQL实现了旧Master的自动数据回滚和Master管理，使得PhxSQL可以安全地实现Master的自动切换，提供高可用服务。和常见的MySQL切换Master方案不同，PhxSQL在切换Master之后仍然保证集群内各机数据一致。
图6
PhxSQL自动Master流程如下：
Slave机器上的Phxbinlogsvr定期检查Master是否过期。如果过期转第2步，否则继续第1步；
Phxbinlogsvr检查本机MySQL是否已执行完所有Binlog。如果已完成转第3步，否则继续第1步；
Phxbinlogsvr发起投票选举新的Master。如果投票成功，提升本机MySQL为Master，关闭readonly开关；否则继续第1步；
旧Master恢复，本机的Phxbinlogsvr查询发现已不是Master，切换MySQL角色为Slave，设置从本机Phxbinlogsvr拉取Binlog，并开启readonly开关。
Phxsqlproxy请求透传
Phxbinlogsvr解决了多Master同时写入的问题，使得MySQLClient向旧Master写入数据会产生失败。虽然保证了数据的一致性，但仍存在下面2个问题：
MySQLClient持续向旧Master写入数据，从而持续的失败。（服务不可用）
部分MySQLClient向新Master写入数据，但其他MySQLClient仍然向旧Master读取数据，导致读不到最新的数据。
图7
上述两个问题都是由于MySQLClient的Master信息更新不及时；部分Client没有及时更新，使得有可能产生PhantomRead(两次读的结果不一致)。
图8 Phxsqlproxy的请求透传
若Slave机器被访问，Phxsqlproxy则会把请求透传到Master机器的Phxsqlproxy。由于PhxSQL Master的全局唯一性，保证了只存在一台MySQL被访问。从而解决了多台机器同时被读写的问题。
PhxSQL性能
使用sysbench工具对PhxSQL和MySQL的半同步复制进行了性能对比。PhxSQL因为增加了Phxsqlproxy，导致读性能比原生MySQL略低；但由于PhxPaxos的实现比MySQL的半同步更加高效，让PhxSQL的写性能比半同步复制更好。
PhxSQL比MySQL读性能比原生MySQL略低，但写性能比MySQL半同步复制更好。
| 读性能 |
写性能 |
|||
| Client线程数 | QPS | 耗时 | QPS | 耗时 |
| 200 | 约降低3% | 耗时约增加2% | 约增高25% | 约降低20% |
| 500 | 约降低13% | 约增加10% | 约增高16% | 约降低10% |
测试环境和结果如下：
机型信息
CPU : Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz * 24
内存 : 32G
磁盘 : SSD Raid10
网络互Ping耗时
Master -> Slave : 3 ~ 4ms
Client -> Master : 4ms
压测工具和参数
sysbench –oltp-tables-count=10 –oltp-table-size=1000000 –num-threads=500 –max-requests=100000 –report-interval=1 –max-time=200
压测内容
PhxSQL和半同步复制在Client线程200和500的环境下进行下面方式的压测：
insert.lua (100%写)
select.lua (0%写)
OLTP.lua (20%写)
压测结果
Client线程数：200
| insert.lua (100%写) | ||
| QPS | 耗时 | |
PhxSQL |
5076 | 39.34/56.93 |
|
MySQL 半同步 |
4055 | 49.27/66.64 |
| select.lua (0%写) | ||
| QPS | 耗时 | |
PhxSQL |
46334 | 4.21/5.12 |
|
MySQL 半同步 |
47528 | 4.10/5.00 |
| OLTP.lua (20%写) | ||
| QPS | 耗时 | |
PhxSQL |
25657 | 140.16/186.39 |
|
MySQL 半同步 |
20391 | 176.39/226.76 |
Client线程数：500
| insert.lua (100%写) | ||
| QPS | 耗时 | |
PhxSQL |
8260 | 60.41/83.14 |
|
MySQL 半同步 |
7072 | 70.60/91.72 |
| select.lua (0%写) | ||
| QPS | 耗时 | |
PhxSQL |
105928 | 4.58/5.81 |
|
MySQL 半同步 |
121535 | 4.17/5.08 |
| OLTP.lua (20%写) | ||
| QPS | 耗时 | |
PhxSQL |
46543 | 192.93/242.85 |
|
MySQL 半同步 |
33229 | 270.38/345.84 |
注：耗时分别为测试结果的平均耗时/95%分位数耗时，单位ms
总结
PhxSQL解决了MySQL半同步复制中数据回滚和多Master的问题，使其能实现自动Master切换且保证数据一致。PhxSQL因为增加了Phxsqlproxy，导致读性能比原生MySQL略低；但由于PhxPaxos的实现比MySQL的半同步更加高效，让PhxSQL的写性能比半同步复制更好。
开源地址：
https://github.com/tencent-wechat/phxsql
点击阅读原文可自动跳转到github地址
附录：