微信高可用分布式数据库PhxSQL设计与实现

资讯频道 → 数据库

1顶
0踩

2017-04-14 10:18 by 副主编 jihong10102006 评论(0) 有5616人浏览

PhxSQL 分布式数据库

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

引用

作者：陈俊超，腾讯微信后台高级工程师，前期主要负责微信后台分布式架构设计及核心模块的开发，包括微信摇一摇，查看附近的人，朋友圈架构，群聊等。目前致力于关系型数据库PhxSQL的设计和开发。
本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅《程序员》

本文详细描述了PhxSQL的设计与实现。从MySQL的容灾缺陷开始讲起，接着阐述实现高可用强一致的思路，然后具体分析每个实现环节要注意的要点和解决方案，最后展示了PhxSQL在容灾和性能上的成果。

设计背景
互联网应用中账号和金融类关键系统要求和强调强一致性及高可用性。当面临机器损坏、网络分区、主备手工或者自动切换时，传统的MySQL主备难以保证强一致性和高可用性。PhxSQL将MySQL集群构建在一致性完善的Paxos协议基础上，保证了集群内MySQL机器之间数据的强一致性和整个集群的高可用性。

原生MySQL的容灾缺陷
【MySQL容灾方案】
MySQL有两种常见的复制方案，异步复制和半同步复制。
1、异步复制方案
Master对数据进行commit操作后再将数据异步复制到Slave。
但数据无法保证成功复制，也就无法保证MySQL主备间的数据一致性，如图1所示。

图1 MySQL异步复制流程

2、半同步复制方案
Master对数据进行commit操作前将数据复制到Slave，确认复制成功后再对数据进行commit操作。
绝大多数情况下，半同步复制能保证MySQL主备间的数据一致性，如图2所示。

图2 MySQL半同步复制流程

【MySQL重启流程】
半同步方案中的“半”是指Master在等待Slave的ACK失败时将退化成异步复制。同时，MySQL在重启时也不会执行半同步复制。

如图3中的id(Gtid)=101数据是Master机器中新写入到Binlog File的Binlog数据。但Master在复制数据到Slave的过程中MySQL宕机导致复制失败。MySQL重启时，数据（id=101）会被直接进行commit操作，随后再将数据异步复制到Slave。（下文将已经写入到Binlog File但未进行commit操作的数据（id=101）称为Pending Binlog。）

图3 MySQL重启时直接提交Pending Binlog

该情况下MySQL容易出现Master-Slave之间数据不一致的情况，官方也描述了该问题。

【MySQL重启缺陷】
下面将解释MySQL在重启时不执行半同步会产生数据不一致的原因。

当对上述例子中的Pending Binlog（id=101）进行复制时Master宕机导致复制失败，随后Slave1切换成新Master并开始提供服务（写入id=201的数据）。此后，当旧Master重启时，Pending Binlog（id=101）不会被重新进行复制而直接进行commit操作，从而导致旧Master比新Master多了一条数据，旧Master无法成为新Master的Slave，需要人工处理掉这条数据之后，才能让旧Master作为Slave提供服务，如图4所示。

图4 MySQL重启缺陷导致主备数据不一致

上述case只对旧Master的数据造成影响，不会使得MySQL Client读取到错误数据。但当Master连续出现两次宕机后产生Master切换，两次宕机间隔较短使得Pending Binlog未能及时复制到Slave，且期间有查询请求时（Master宕机→Master重启→查询数据→Master宕机→Master切换），MySQL Client会产生如图5所示的幻读（两次读到的结果不一致）。

图5 MySQL重启缺陷导致Client产生幻读

【MySQL Client分裂】
当Master出现故障且产生Master切换时，由于原生MySQL缺乏调用端的通知/重定向机制，使得不同的Client可能访问不同的Master，导致数据的错误写入和读取，如图6所示。

图6 MySQL进行Master导致Client端分裂

【MySQL缺乏自动选主机制】
由于半同步复制不需要等待所有Slave的ACK，因此当Master出现故障时，需要选有最新Binlog的Slave为新的Master；而MySQL并没有内置这个选主机制，如图7所示。

图7 MySQL缺少自动选主机制

【MySQL的容灾缺陷总结】
MySQL在容灾方面存在的问题：

Master切换时主备数据不能保证一致：Master重启并切换可能导致MySQL主备间数据不一致。Master重启并切换可能导致MySQL Client产生幻读。
原生MySQL缺乏高可用机制：Master切换导致调用端分裂。缺乏自动选主机制。

对于原生MySQL，在高可用和强一致两个特性中，只能二选一：

要求MySQL主备间的数据强一致，不做主备自动切换。
借助MHA实现高可用，容忍MySQL主备间的数据不一致。

因此MySQL在容灾上无法同时满足数据强一致和服务高可用两个特性。

PhxSQL设计思路
【可靠日志存储】
实现一个以可靠日志存储为中心的架构来解决MySQL数据复制时产生的数据不一致问题。

Master将Binlog发送到BinlogSvr集群（可靠日志存储），Slave从BinlogSvr集群获取Binlog数据完成数据复制。
Master在重启时，根据BinlogSvr集群的数据判断Pending Binlog是否已经被复制。如果未被复制则从Binlog File中删除。

利用BinlogSvr集群（可靠日志存储），使得Master（重启时检查本地Binlog是否和BinlogSvr集群的数据一致）和Slave（从BinlogSvr集群中获取Binlog）的数据保持一致，从而保证了整个集群中的MySQL主备间数据的一致性，如图8所示。

图8 实现一个可靠日志存储保证各MySQL的数据一致

【请求透传】
在Master进行切换时，切换操作可能会导致部分MySQL Client仍然访问旧Master并读到旧数据。
最直观的方法是修改MySQL Client API，在每一次进行查询时，先确认当前Master的位置。但此方法有以下缺点：

需要维护一个MySQL Client API的私有版本，维护成本高。
所有的调用端需要集成这个私有的MySQL Client API，操作成本很高。

为了避免修改MySQL Client API，可通过增加Proxy进行请求透传来解决上述问题。在每一个MySQL结点上增加一个Proxy，MySQL Client的请求不再直接访问MySQL而直接访问Proxy。Proxy根据Master的位置，将访问Slave机器的请求透传到Master机器，再进行MySQL操作。

通过增加Proxy进行请求透传，解决了MySQL Client分裂导致有可能读取到旧数据的问题，如图9所示。

图9 实现一个可靠日志存储保证各MySQL的数据一致

【自动选主】
多机自动选主最常见的实现方式是由各个参与者发起投票，获得多数派支持的机器为Master，同时把Master信息记录到可靠存储。Master机器定期到可靠存储延长租约；非Master机器定期检查Master租约是否过期，从而决定是否要发起选举自己为Master的投票。

为了避免修改MySQL代码，在MySQL机器上增加一个Agent，由Agent来替代MySQL发起选主投票和续期租约；可靠存储继续由BinlogSvr承担。

Agent完成以下功能：

Master机器的Agent监控本机MySQL是否正常服务；如果正常服务，则定期到可靠存储延长租约，否则停止续约。
非Master机器的Agent定期从可靠存储检查Master租约是否过期；如果过期，再检查本机MySQL是否已经执行了所有Binlog。如果已经执行了所有Binlog，则发起选举自己为Master的投票，如图10所示。

图10 可靠日志存储和Agent共同实现自动选主机制

PhxSQL架构和实现
从上述思路可以得出PhxSQL的简单三层架构。对于每一个节点，部署3个模块（PhxSQLProxy，MySQL，PhxBinlogSvr）。多个节点上的PhxBinlogSvr组成一个可靠的日志存储集群和可靠的Master信息存储集群；PhxBinlogSvr同时承担Agent的责任。PhxSQLProxy负责请求的透传。Master结点上的PhxSync负责将MySQL的Binlog发送到PhxBinlogSvr，如图11所示。

图11 PhxSQL基本架构

【Proxy(PhxSQLProxy)】
1、请求透传
请求透传是Proxy主要的功能。主要解决在进行Master切换的时候，MySQL Client会被分裂，不同的Client可能连接到不同的MySQL。导致出现MySQL Client写入数据到错误的Master或者从错误的Master读取到错误的数据。

Proxy的请求透传分两种：

读写端口请求透传：Slave节点收到的请求透传给Master节点执行。Master节点收到的请求直接透传给本机MySQL执行。
只读端口请求透传：Master节点收到的请求透传给Slave节点执行。Slave节点收到的请求直接透传给本机MySQL执行，如图12所示。

图12 Proxy请求透传流程

高性能：由于Proxy接管了MySQL Client的请求，为了使整个集群的读写性能接近单机MySQL，Proxy使用协程模型提高自身的处理能力。

Proxy的协程模型使用开源的Libco库。Libco库是微信团队开源的一个高性能协程库，具有以下特点：

用同步方式写代码，实现异步代码的性能。
支持千万级的并发连接。
项目地址https://github.com/tencent-wechat/libco

完全兼容MySQL：为了已有的应用程序能够不做任何修改就能迁移到PhxSQL，Proxy需兼容MySQL的所有功能。

兼容MySQL事务
MySQL事务管理基于连接，同一个事务的所有请求通过同一个连接通信。在事务处理中连接丢失，事务将被rollback（http://dev.mysql.com/doc/refman/5.6/en/innodb-autocommit-commit-rollback.html）。

Proxy使用1:1连接模型完全兼容MySQL事务。每当MySQL Client发起一个连接到Proxy，Proxy都会相应地发起一个连接到MySQL。两条连接中，任意一个中断，另外一个也相应断开，对应的事务会被rollback，如图13所示。

图13 Proxy的1对1事务连接模型

兼容MySQL权限
MySQL的权限管理基于（用户，源IP）对，源IP是通过socket句柄反查获取。当请求通过Proxy连接到MySQL时，源IP为Proxy本地IP，权限管理会出现异常。

Proxy利用MySQL协议HEAD保留字段透传真实源IP到MySQ，MySQL再从HEAD保留字段获取正确的源IP进行权限管理，如图14所示。

图14 Proxy通过修改MySQL协议兼容MySQL权限

PhxSync
PhxSync的功能和MySQL的semisync插件类似。经过调研，对semisync插件的接口做少量的调整，就可以使用这些插件接口来实现PhxSync。

PhxSync功能主要是：

正常运行时提交Binlog：MySQL在正常写入或者更新数据时，会调用after_flush接口。PhxSync插件通过实现after_flush接口将MySQL新写入的Binlog提交到本机的BinlogSvr，由本机BinlogSvr通过Paxos协议同步到BinlogSvr集群。
重启时校准本地Binlog：MySQL在重启时通过查询BinlogSvr集群判断本地Pending Binlog的状态。如果Pending Binlog未复制到BinlogSvr集群则从本地删除，保持本地的Binlog数据和BinlogSvr集群的Binlog数据一致。

由于MySQL没有提供在重启时的插件接口，为了后续维护方便，在MySQL代码层抽象出了一个新插件接口before_binlog_init用于校准Binlog。

上述对after_flush接口的调整，和新增的before_binlog_init接口已经提交补丁给MySQL官方（http://bugs.mysql.com/bug.php?id=83158）。

【PhxBinlogSvr】
PhxBinlogSvr主要负责存储Binlog和Master信息的维护。在数据复制阶段，通过Paxos协议保证PhxBinlogSvr各节点的数据一致性（下文称PhxBinlogSvr为BinlogSvr）。

PhxPaxos库：BinlogSvr使用PhxPaxos库进行数据的复制。PhxPaxos库是微信团队开源的Paxos类库，具有以下特性：1. 保证各节点的数据一致。
保证集群机器超过一半存活还能服务。
高性能。
功能完善。
稳定性经过大规模验证。
接口方便易用。
项目地址https://github.com/tencent-wechat/phxpaxos

BinlogSvr异常情况处理
防止Slave的节点提交数据
当旧Master在提交数据时由于网络问题数据包被卡在网络，且新Mater已经成功切换时，或者人为错误直接往Slave节点的MySQL写入数据时，则会出现Slave节点提交数据的情况。多节点同时提交数据会出现BinlogSvr的Binlog数据和MySQL存储的Binlog数据不一致的情况。

BinlogSvr存储了集群内的Master信息。当其收到MySQL提交的数据时，可根据Master信息拒绝非Master节点的提交，如图15所示。

图15 BinlogSvr通过Master信息拒绝非Master节点的提交

防止Master提交错误数据
在某些情况下，Master可能会重新发送数据或者发送错误数据。譬如在网络不好的情况下Master由于提交数据超时而重发数据。磁盘发生故障或者数据被错误回滚或者修改的时候，Master会提交错误的数据。

BinlogSvr使用乐观锁机制来防止Master的异常提交。在MySQL提交数据给BinlogSvr时，以本机MySQL已经执行的GTID为乐观锁，提交的内容为（本机MySQL已经执行的最新GTID，本次要提交的Binlog）。BinlogSvr通过检查请求中（本机MySQL已经执行的最新GTID）和自身保存的最新GTID是否匹配来拒绝重新发送或者异常发送的数据，如图16所示。

图16 BinlogSvr使用乐观锁拒绝Master在数据异常的情况下提交数据

支持MySQL原生复制协议：为了让Slave能从BinlogSvr获取Binlog，最好的方式就是BinlogSvr支持MySQL原生的复制协议，这样不用对Slave做任何修改，如图17所示。

图17 BinlogSvr支持MySQL使用原生复制协议获取Binlog数据

Master管理：BinlogSvr除了存储MySQL的Binlog数据，还存储了Master信息。同时还承担了Agent的角色，负责监控MySQL的状态，必要时发起选举自己为Master的投票。

BinlogSvr通过Paxos协议进行Master选举，选举成功后成为Master并拥有租约。通过Paxos协议选举保证了最终只产生一个Master且每个节点记录了一致的Master信息。

PhxSQL效果
【PhxSQL数据一致性】
通过比较PhxSQL集群中各节点的数据（MySQL Binlog，PhxPaxos，BinlogSvr) 判断各节点数据是否一致，如图18所示。

图18 PhxSQL 3机数据对比

【Master自动切换】
通过观察Master宕机时各节点的流量变化判断Master是否顺利切换。下图中的红线代表流量。当Master宕机时，流量会随之转移，代表Master顺利切换，如图19所示。

图19 PhxSQL进行Master切换时各节点的写入流量变化

【PhxSQL性能】

MySQL版本：Percona 5.6.31-77.0
机器信息：

工具和参数：

PhxSQL的写性能比MySQL的半同步好，读性能由于多了一层Proxy导致比MySQL的半同步稍差。

图20 PhxSQL和MySQL的性能对比

成功案例
QQ邮箱（域名邮箱）域名记录服务器：单个集群调用峰值40w/min。写请求平均耗时在20ms以下。读写比为20：1。机器配置：Intel Xeon CPU x3440 @ 2.53ghz 8 core，8GB ram。

订阅2017年程序员（含iOS、Android及印刷版）请访问 http://dingyue.programmer.com.cn

查看图片附件

分享到：

1
顶

0
踩

评论共 0 条请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

微信数据强一致高可用分布式数据库PhxSQL设计与实现

本文详细描述了 PhxSQL 的设计与实现。从 MySQL 的容灾缺陷开始讲起，接着阐述实现高可用强一致的思路，然后具体分析每个实现环节要注意的要点和解决方案，最后展示了 PhxSQL 在容灾和性能上的成果。设计背景 ...

！！！！！！！！！！！！！！！！！！！微信高可用分布式数据库PhxSQL设计与实现！！！！！！！！！！！！！！！！！！！

借助MHA实现高可用，容忍MySQL主备间的数据不一致。图8 实现一个可靠日志存储保证各MySQL的数据一致需要维护一个MySQL Client API的私有版本，维护成本高。所有...

cpp-PhxSQL是由微信后台团队自主研发的一款服务高可用数据强一致的分布式数据库服务

PhxSQL是由微信后台团队自主研发的一款服务高可用、数据强一致的分布式数据库服务。该服务基于Percona5.6搭建，目标在于解决MySQL在容灾和数据一致性方面的不足，并大幅简化了MySQL容灾切换的运维操作。

PhxSQL学习--腾讯开源的分布式数据库服务

最近在研究MySQL数据库的高可用性和强一致性，略有心得，记录一下！前言以前在开发电商项目时，使用的是主流的方法：通过对MySQL进行主从复制，及利用Amoeba实现数据库读写分离，来搭建一个较为稳定且能承受并发量...

微信开源PhxSQL：高可用、强一致的MySQL集群

作者：陈俊超(junechen@tencent.com)，微信后台高级工程师，主要负责微信后台核心模块的分布式架构设计和开发。早期负责微信附近的人，摇一摇，朋友圈，群聊等基础架构。现专注于PhxSQL等开源项目。PhxSQL作者之一...

PhxSQL设计与实现

导语：本文详细描述了PhxSQL的设计与实现。从MySQL的容灾缺陷开始讲起，接着阐述实现高可用强一致的思路，然后具体分析每个实现环节要注意的要点和解决方案，最后展示了PhxSQL在容灾和性能上的成果。 1. 设计背景...

分布式MySQL数据库服务PhxSQL

PhxSQL是由微信后台团队自主研发的一款数据强一致、服务高可用的分布式数据库服务。PhxSQL提供Zookeeper级别的强一致和高可用，完全兼容MySQL。源码地址 PhxSQL具有服务高可用、数据强一致、高性能、运维简单、和...

OFDM、OOK、PPM、QAM 的误码率模拟【绘制不同调制方案的误码率曲线】附Matlab代码.rar

1.版本：matlab2014/2019a/2024a 2.附赠案例数据可直接运行matlab程序。 3.代码特点：参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象：计算机，电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。

8c71b76fb2ec10cf50fc6b0308d3dcfc_9545878e2b97a84b2e089ece58da9e82.png

8c71b76fb2ec10cf50fc6b0308d3dcfc_9545878e2b97a84b2e089ece58da9e82

Android SO逆向-对象的拷贝构造函数.pdf

Android逆向过程学习

基于S7-200 PLC的糖果包装控制系统设计与实现

内容概要：本文详细介绍了基于西门子S7-200 PLC的糖果包装控制系统的设计与实现。首先阐述了PLC在工业自动化领域的优势及其在糖果包装生产线中的重要性。接着深入探讨了系统的硬件连接方式，包括传感器、执行机构与PLC的具体接口配置。随后展示了关键的编程实现部分，如糖果计数、包装执行、送膜控制、称重判断以及热封温度控制等具体梯形图代码片段。此外，还分享了一些实用的经验技巧，如防止信号抖动、PID参数优化、故障诊断方法等。最后总结了该系统的优势，强调其对提高生产效率和产品质量的重要作用。适合人群：从事工业自动化控制、PLC编程的技术人员，尤其是对小型PLC系统感兴趣的工程师。使用场景及目标：适用于糖果制造企业，旨在提升包装生产线的自动化程度，确保高效稳定的生产过程，同时降低维护成本并提高产品一致性。其他说明：文中不仅提供了详细的理论讲解和技术指导，还结合实际案例进行了经验分享，有助于读者更好地理解和掌握相关知识。

PLC与WinCC实现三部十层电梯协同控制及优化技巧

内容概要：本文详细介绍了参与西门子杯比赛中关于三部十层电梯系统的博图V15.1程序设计及其WinCC画面展示的内容。文中不仅展示了电梯系统的基本架构，如抢单逻辑、方向决策、状态机管理等核心算法（采用SCL语言编写），还分享了许多实际调试过程中遇到的问题及解决方案，例如未初始化变量导致的异常行为、状态机遗漏空闲状态、WinCC画面动态显示的挑战以及通信配置中的ASCII码解析错误等问题。此外，作者还特别提到一些创意性的设计，如电梯同时到达同一层时楼层显示器变为闪烁爱心的效果，以及节能模式下电梯自动停靠中间楼层的功能。适合人群：对PLC编程、工业自动化控制、电梯调度算法感兴趣的工程技术人员，尤其是准备参加类似竞赛的学生和技术爱好者。使用场景及目标：适用于希望深入了解PLC编程实践、掌握电梯群控系统的设计思路和技术要点的人士。通过学习本文可以更好地理解如何利用PLC进行复杂的机电一体化项目的开发，提高解决实际问题的能力。其他说明：文章风格幽默诙谐，将严肃的技术话题融入轻松的生活化比喻之中，使得原本枯燥的专业知识变得生动有趣。同时，文中提供的经验教训对于从事相关领域的工作者来说非常宝贵，能够帮助他们少走弯路并激发更多创新思维。

慧荣量产工具合集.zip

永磁同步电机FOC控制与SVPWM算法仿真模型解析

内容概要：本文详细介绍了永磁同步电机（PMSM）的FOC（磁场定向控制）和SVPWM（空间矢量脉宽调制）算法的仿真模型。首先解释了FOC的基本原理及其核心的坐标变换（Clark变换和Park变换），并给出了相应的Python代码实现。接下来探讨了SVPWM算法的工作机制，包括扇区判断和占空比计算的方法。此外，文章还讨论了电机的PI双闭环控制结构，即速度环和电流环的设计与实现。文中不仅提供了详细的理论背景，还分享了一些实用的编程技巧和注意事项，帮助读者更好地理解和应用这些算法。适合人群：电气工程专业学生、从事电机控制系统开发的技术人员以及对永磁同步电机控制感兴趣的科研人员。使用场景及目标：① 学习和掌握永磁同步电机的FOC控制和SVPWM算法的具体实现；② 提供丰富的代码示例和实践经验，便于快速搭建和调试仿真模型；③ 探讨不同参数设置对电机性能的影响，提高系统的稳定性和效率。其他说明：文章强调了在实际应用中需要注意的一些细节问题，如坐标变换中的系数选择、SVPWM算法中的扇区判断优化以及PI控制器的参数调整等。同时，鼓励读者通过动手实验来加深对各个模块的理解。

spring-ai-qianfan-1.0.0-M5.jar中文文档.zip

# 压缩文件中包含：中文文档 jar包下载地址 Maven依赖 Gradle依赖源代码下载地址 # 本文件关键字： jar中文文档.zip,java,jar包,Maven,第三方jar包,组件,开源组件,第三方组件,Gradle,中文API文档,手册,开发手册,使用手册,参考手册 # 使用方法：解压最外层zip，再解压其中的zip包，双击【index.html】文件，即可用浏览器打开、进行查看。 # 特殊说明： ·本文档为人性化翻译，精心制作，请放心使用。 ·只翻译了该翻译的内容，如：注释、说明、描述、用法讲解等； ·不该翻译的内容保持原样，如：类名、方法名、包名、类型、关键字、代码等。 # 温馨提示：（1）为了防止解压后路径太长导致浏览器无法打开，推荐在解压时选择“解压到当前文件夹”（放心，自带文件夹，文件不会散落一地）；（2）有时，一套Java组件会有多个jar，所以在下载前，请仔细阅读本篇描述，以确保这就是你需要的文件；

Android安全之旅系列博客导读.pdf

Android逆向过程学习

【图像处理】基于双目视觉的物体体积测量算法研究附Matlab代码.rar

3dmax插件按面积分离.ms

3dmax插件

spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7.jar中文文档.zip

# 【spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7.jar中文文档.zip】中包含：中文文档：【spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7-javadoc-API文档-中文(简体)版.zip】 jar包下载地址：【spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7.jar下载地址(官方地址+国内镜像地址).txt】 Maven依赖：【spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7.jar Maven依赖信息(可用于项目pom.xml).txt】 Gradle依赖：【spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7.jar Gradle依赖信息(可用于项目build.gradle).txt】源代码下载地址：【spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7-sources.jar下载地址(官方地址+国内镜像地址).txt】 # 本文件关键字： spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7.jar中文文档.zip,java,spring-ai-autoconfigure-vector-store-qdrant-1.0.0-M7.jar,org.springframework.ai,spring-ai-autoconfigure-vector-store-qdrant,1.0.0-M7,org.springframework.ai.vectorstore.qdr

1顶0踩