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

这可能是明显区别PhxSQL和其它方案的一个特点.一个经过逻辑证明的模型才是可靠的,一个建立在可靠模型基础上的系统也才是可信赖的.PhxSQL一致性模型建立在两个前提上：

1. Paxos保证一致性.这个大家都可以接受.
2. 各个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支持热变更成员,是不是很令人激动的特性?

（编辑：ASP站长网）