开源地址

GitHub - tencent-wechat/phxsql: A high availability MySQL cluster that guarantees data consistency between a master and slaves.

摘要

微信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流水根底上。次要原理简略来说：

i) Paxos选出主机

ii) 主机把本机MySQL设置成可写的MySQL主机，在MySQL写binlog流程中拦挡binlog流水、发送到Paxos，造成全局的binlog流水

iii) 备机把本机的MySQL设置成只读的MySQL备机，MySQL备机从全局binlog中拉取流水，重放和执行，从而主备MySQL统一

iv) 针对常见的业务场景，PhxSQL提供两个服务端口：强统一读写端口（ReadWritePort）和只读端口（ReadonlyPort）；对数据要求强统一的业务，通过ReadWritePort来读写；只要求能读取但不要求最新数据的读申请（比方一些定时对账业务），能够通过ReadonlyPort来读取

只有有多于一半机器工作和互联，PhxSQL就能够失常工作。

图 1：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半同步的写性能（在基准测试中晋升16%到25%）和简直雷同的读性能[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. 简略可逻辑证实的一致性模型

这可能是显著区别PhxSQL和其它计划的一个特点。一个通过逻辑证实的模型才是牢靠的，一个建设在牢靠模型根底上的零碎也才是可信赖的。PhxSQL一致性模型建设在两个前提上：

i) Paxos保障一致性。这个大家都能够承受。

ii) 各个MySQL的binlog流水统一，则各个MySQL机器之间数据“统一”。这个假如小有争议。例如即便binlog流水统一，因为不同的binlog格局、备机重放流水的不同配置，也会导致主备之间、不同备机之间的数据产生不同级别的“不同”，例如一条和以后工夫相干的insert操作。这种不统一有些利用能够容忍，有些则不能。在这里，PhxSQL保障流水统一，而把格局和配置的自在留给利用和DBA依据具体场景确定。在最严格的配置下，binlog统一，则数据统一。

在这两个前提下，PhxSQL的一致性模型通过Paxos，使得主机写入Paxos的binlog流水与备机从Paxos里拉取的binlog流水统一，从而保障MySQL数据的一致性。具体证实过程咱们将另外提供。模型和证实过程都很简略，大家在读完源码后也能够尝试:)。

但即便模型正确，PhxSQL正确实现了这个模型吗？用艰深的话讲，没有bug。码农都晓得这是个微小的挑战。从一个算法和模型到正确的实现之间差距是微小的。例如，正确实现Paxos挑战就很大[7]。为了尽量减少bug，咱们抉择了简略和易了解同时利用宽泛的Paxos作为一致性协定。为了实现一个“生产”级别的Paxos，三位次要码农各自独立实现了Paxos，在各自测试完正确性后，三套Paxos之间作为一组Paxos的独立节点互操作测验正确性，最初再个体实现一个发行版本PhxPaxos[21]！除了单元测试、零碎测试外，测试环境还随机高频率独立重启机器、对网络包进行乱序、提早、反复等以对系统进行充沛测试。

有读者可能问，Paxos慢且网络提早大，PhxSQL为什么不实现一个“优化”版？Paxos有各种版本，例如Fast Paxos[19]、EPaxos[20]。但这些都是Paxos，遵循Paxos的基本操作，所作的扭转，都做了严格的形式化或者逻辑证实。PhxPaxos严格遵循Paxos算法[4]实现，没有做任何扭转或者“优化”。PhxPaxos的失常写操作的网络提早是一个网络RTT，曾经是任何算法实践上能达到的最快速度。

当初，对于PhxSQL来说，切换主机是一件很平时和容易的操作，就像往MySQL里插入一条数据一样平时和容易。

4.2. 最小侵入MySQL准则

MySQL是个微小的疾速演进的生态系统，保障PhxSQL中的MySQL与官网MySQL的兼容性与可降级性是必须的。这使得MySQL利用能够疾速迁徙到和运行在PhxSQL上。这也使得PhxSQL能够迅速响应官网MySQL的降级，将PhxSQL中的旧版本MySQL降级到新的官网MySQL，从而取得新的个性、性能、稳定性、和安全性晋升。

这就要求PhxSQL中的MySQL对官网MySQL改变尽量少。实际上，PhxSQL版MySQL只更改了三个小中央：批改了binlog插件接口中一个函数的参数；在MySQL启动时新增了一个插件函数用于查看MySQL本地的binlog文件，在MySQL协定中透传了真正的客户端IP以兼容受权性能（如果利用不须要能够不批改）。这几个改变是如此小，且波及的是简直稳固不变的流程，使得PhxSQL中MySQL追随官网MySQL降级能够无缝实现。实际上，咱们正和MySQL社区沟通，心愿把这几处批改并入官网版本，从而使得PhxSQL当前能够齐全应用官网版本MySQL，也使得更多人能够不便采纳PhxSQL。

(a)

(b)

图 2：PhxSQL对MySQL的要害批改。(a)是MySQL。(b)是PhxSQL中的MySQL。PhxSQL批改了after_flush这个函数的参数，新增了在MySQL启动时调用的before_recovery这个函数。

也正是因为这个起因，咱们没有因为能够缩小模块个数而把PhxSQLProxy、PhxBinlogSvr放到MySQL过程内。为了保障和利用最宽泛的MySQL单机版兼容，也没有在事务层和存储层染指或批改。

4.3. 简略的架构、部署、和运维

在满足要求的前提下，简略的架构有很多益处，例如开发、保护、诊断、保护、可靠性等等都变得容易。PhxSQL只有3+1个模块。PhxSQL中的MySQL是必须的。PhxBinlogSvr负责全局binlog存储和同步、选主、集群成员治理等要害性能。在很多MySQL主备集群计划中，应用Zookeeper、etcd、心跳检测、Agent等承当选主的性能。PhxSQLProxy则作为传统MySQL client拜访PhxSQL中MySQL服务的代理，使得PhxSQL的换主操作对于传统MySQL client通明。在其它集群计划中，个别也是通过代理MySQL proxy、或者虚构网关VIP，向传统MySQL client屏蔽集群的换主操作，提供通明拜访。可选模块是PhxSQL client lib，它批改了MySQL client库中的连贯初始化函数，容许传入一个集群的PhxSQLProxy列表，从而在一个PhxSQLProxy没有响应时、主动拜访其它可用PhxSQLProxy，进一步提高可用性。开发人员能够间接链接PhxSQL client lib。

PhxSQL的部署和运维都很简略。在部署时，只有在指标机各自装好PhxSQL，在配置中指定集群的机器的IP列表，PhxSQL即可运行。换主这个操作曾经从运维层面转移到PhxSQL失常的工作流程。通常MySQL集群中换主后可能须要人肉检查数据一致性、人肉“闪回”（这可能违反一致性保障，导致“幻读”）；无奈”闪回“导致必须革除某台MySQL，从新拉取数据备份，和追流水等。这些耗时、沉重、易错的操作在PhxSQL中曾经齐全不须要。

至于热降级和热变更集群成员更简略。PhxSQL反对rolling-update，能够逐渐降级每台机器。变更集群成员是指往集群增加机器、撤出机器、和替换机器（原子操作）。在保障强统一和高可用前提下，热变更（不停服变更）是十分艰难的。PhxSQL通过在Paxos中实现成员变更解决了这个难题。PhxSQL提供了一个变更操作命令。当在新机器装置和启动PhxSQL后（要求MySQL曾经加载一份较新的数据备份），能够在现有集群中一键将新机器引入、剔除一台旧机器、或者同时做两者。这三种操作都是原子操作！新机器会主动追流水。想想看，相当于Zookeeper反对热变更成员，是不是很令人激动的个性？

PhxSQL因为在同步层应用Paxos，人造反对多数据中心、多机房部署，两地三核心这种部署更是不在话下。对于PhxSQL来说，多数据中心和多机房部署与机房内部署没有区别。PhxSQL的性能取决于多数派机器之间的网络提早。

5. 为什么要开源？

作为酷爱技术的码农，咱们置信开源的技术能够使得这个世界更美妙。从咱们日常开发应用的Emacs/Vim、GCC、GDB，间接为公众提供社交、电子商务、信息服务的Linux、Apache、MySQL、PHP，到公众每日应用来沟通和娱乐的Android等，开源是整个互联网的基石，为全世界提供许多要害不可或缺的根底服务。咱们充沛享受了开源带来的技术提高、经济倒退、和社会后退，咱们也心愿开源的PhxSQL能够回馈社区，帮忙更多有须要的人。

另外，咱们心愿通过开源更好地改良PhxSQL。咱们欢送技术性探讨和志愿者提交批改。咱们承诺开源的PhxSQL会始终更新。除了一些和外部运维撑持零碎进行集成的性能（PhxSQL把这些性能形象成插件，咱们针对外部运维撑持零碎实现了这些插件），开源版和外部版本将保持一致。

6. PhxSQL的局限性

在一个不完满的世界里，完满是不存在的。咱们很坦诚指出PhxSQL存在的两个局限：

6.1. MySQL主机在执行SQL DDL命令（例如建库和建表命令）时可能存在一致性危险。

因为MySQL的innodb引擎不反对DDL回滚，如果主机在innodb曾经commit这条DDL命令，然而这条命令的binlog还没达到PhxSQL的拦挡点前宕机，则这条DDL binlog会在全局binlog中缺失，从而备机也不会收到这条binlog。而为了保障线性一致性、serializable级别事务隔离、及“最小侵入MySQL”准则，咱们也不想批改MySQL源码，提前截获DDL命令。思考到DDL命令频度较低，咱们后续筹备在PhxSQLProxy退出检查和后续审计告警。也欢送大家提出更好计划。

**6.2. 在写入申请量很大的零碎中，MySQL备机流水可能落后较多；如果这个时候主机死机，备机临时无奈晋升成新主机，造成零碎在一段时间内不可写。

**

为了保障线性一致性，对于要求读取最新数据的申请（通过ReadWritePort发动的读申请）也将失败；须要等至多一台备机追完流水，被晋升为主机能力响应读取最新数据的申请。对于不须要读取最新数据的申请（通过ReadonlyPort发动的申请），能够从任意备机执行，但不保障线性一致性。（留神：PhxSQL保障无论MySQL主机流水当先MySQL备机多少，MySQL主机binlog流水和全局binlog流水是统一的，不会导致数据失落和毁坏线性一致性。）

MySQL备机追流水落后是基于binlog复制这种模式的一个潜在问题。事实上，不仅MySQL主备，任何一个多正本零碎，只有每个写操作不期待所有正本返回，都会呈现相似的有些正本落后的问题；而那些期待所有正本返回的模式，在耗时和可用性方面又存在问题。可喜的是MySQL 5.7版本实现了并行复制机制，显著地进步了备机追流水的性能。PhxSQL将很快反对MySQL 5.7，对于写入申请量很大的场景也能够很大水平上防止备机追流水落后的状况。

谈完why，敬请期待《PhxSQL设计和实现哲学》的下章：why not，即咱们为什么不反对若干个性，例如多主多写和分库分表，及与Galera和MySQL Group Replication的比拟等。

参考

  1. M.P. Herlihy and J. M. Wing. Linearizability: a correctness condition for concurrent objects. ACM Transactions on Programming Languages and Systems (TOPLAS), Volume 12 Issue 3, July 1990, Pages 463-492.
  2. L. Lamport. How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Trans. Computer. C-28,9 (Sept. 1979), 690-691.
  3. P. Hunt, M. Konar, F. P. Junqueira, and B. Reed. ZooKeeper: wait-free coordination for Internet-scale systems. USENIXATC'10, 2010.
  4. L. Lamport. Paxos Made Simple. ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001) 51-58.
  5. D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. USENIX ATC ’14, 2014.
  6. B. M. Oki and B.H. Liskov. Viewstamped replication: a New primary copy method to support highly-available distributed systems. PODC’88, 8-17, 1988.
  7. T. Chandra, R. Griesemer, and J. Redstone. Paxos made live – an engineering perspective. PODC’07, 2007.
  8. J. C. Corbett, J. Dean, M. Epstein, and etc. Spanner: Google's Globally-Distributed Database. OSDI'12, 2012.
  9. F. Pedone, R. Guerraoui, and A. Schiper. The database state machine approach. Journal of Distributed and Parallel Databases and Technology, 14:71–98, 2002
  10. V. Zuikeviciute and F. Pedone. Revisiting the database state machine approach. VLDB Workshop on Design, Implementation, and Deployment of Database Replication. 2005.
  11. Certification-based Replication. Visited at 2016/9/5.
  12. Snapshot isolation. Visited at 2016/9/5.
  13. Y. Amir, L. E. Moser, P. M. Melliar-smith, D. A. Agarwal, and P. Ciarfella. The totem single ring ordering and membership protocol. ACM Transactions on Computer Systems. 13 (4): 311–342.
  14. http://downloads.mysql.com/presentations/innovation-day-2016/Session_7_MySQL_Group_Replication_for_High_Availability.pdf. Visited at 2016/9/5.
  15. Replication API. Visited at 2016/9/5.
  16. Corosync by corosync. Visited at 2016/9/5.
  17. http://www.spread.org/. Visited at 2016/9/5.
  18. Isolation Levels. Visited at 2016/9/5
  19. L. Lamport. Fast Paxos. Technical Report, MSR-TR-2005-112.
  20. I. Moraru, D. G. Andersen, and M. Kaminsky. There is more consensus in egalitarian parliaments. SOSP’13, 2013.

OpenIMgithub开源地址：

https://github.com/OpenIMSDK/...

OpenIM官网 ：https://www.rentsoft.cn

OpenIM官方论坛：https://forum.rentsoft.cn/

更多技术文章：

开源OpenIM：高性能、可伸缩、易扩大的即时通讯架构
https://forum.rentsoft.cn/thr...

【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理
https://forum.rentsoft.cn/thr...