关于im:谈谈PhxSQL的设计和实现哲学上

开源地址

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…