别小看 Phx 这几位剑客！他们可是微信强大的支持后盾

原创

腾讯开源

修改于 2017-08-23 11:29:36

5.4K0

修改于 2017-08-23 11:29:36

文章被收录于专栏：腾讯开源的专栏腾讯开源的专栏

历程与背景

Phx比武大会即将开始啦！今天，来自微信后台团队的三位剑客正跃跃欲试，将在各位朋友的见证下上演一场精彩的对决。小编想想都觉得很刺激呢。

在比赛开始之前，我们先来了解一下他们的幕后老板——微信后台团队。过去的数年时间里，微信后台系统从无到有，为了满足微信庞大用户群和海量数据的业务需求，不断迭代优化，形成成熟的技术并开始在公司内分享。从小步慢跑到快速成长，经历了平台化到走出国门，微信交出了一份优异的答卷。

现在，微信后台团队也紧跟开源步伐，一下子带出了三位武林高手：轻便简洁的PhxRPC框架，基于Paxos协议的多机状态拷贝类库PhxPaxos以及分布式数据库服务PhxSQL。下面，我们将深入了解这几位选手，看看他们都会展示什么令人惊叹的必杀技？

PhxPaxos

他是谁？（基本介绍）

PhxPaxos（GitHub上他的传记：https://github.com/Tencent/phxpaxos） 是腾讯公司微信后台团队自主研发的一套基于Paxos协议的多机状态拷贝类库。它以库函数的方式嵌入到开发者的代码当中，使得一些单机状态服务可以扩展到多机器，从而获得强一致性的多副本以及自动容灾的特性。这个类库在微信服务里面经过一系列的工程验证，并且我们对它进行过大量的恶劣环境下的测试，使其在一致性的保证上更为健壮。

他从哪里来？（研究背景）

互联网海量服务下的一些敏感的业务场景中（UIN核心资料信息 or 金融数据存储），同时对数据安全（一致性）和可用性有很高的要求。可用性要求数据多机冗余，而一致性要求不管集群里的存储机器在任何苛刻条件的环境，包括宕机，主备切换，超时丢包，网络隔离，Client都可以从这个集群里读取一致的数据。于是产生了比较高的技术难度。

业界如MySQL/Oracle的1主N备在这块的方案都面临 "最大可用(Max Ava)" 与 "最大保护(Max Protect)" 模式之间的选择。最大可用表示主备之间的同步是一种尽力而为的行为，如果备机宕机时则主机单独提供服务，这表示备机宕机并主备有切换时可能会有数据不一致的情况。最大保护即备机寄机时，强行等到备机可用时再恢复对外的服务，虽然保证数据不丢，但基本放弃了可用性。

而基于Paxos协议的数据同步与传统主备方式最大的优点在于，Paxos只要保证任意超过半数的副本在线且相互通信正常，就能保证服务的可用，且数据绝不丢失。裁剪和简化后类Paxos协议和实现可以接地气地用到很多2C的互联网业务开发中，让自己在后续开发中能灵活运用相关的思路去设计一致性和可用性问题的解决方案。

他长得怎么样？（架构简析）

上图为抽像后的框架大体模块架构，简述如下：

多Group , 每个Group有单独的物理日志存储和状态机，多Group可以提高Paxos写性能，并设计数据分布。
Proposer , Acceptor , Learner都聚集在同一进程上。一次Propose（写入数据）的Latency为一次RTT，均摊单机写盘次数为1次，每次写盘都使用fsync严格保证正确性。
内置Master选举功能。PhxPaxos提供了基于强一致的选主机制，由MasterMgr线程统一管理。但这里的选主能力是可选的，其实是提供业务侧的一个能力，因为MultiPaxos并不需要一个强一制的主也能运作，只是提高活锁的机率而已。
支持Checkpoint以及对PaxosLog的自动清理。CheckPoint，类DBMS的概念，可以定期把PaxosLog（DBMS里则是把RedoLog）归档到状态机的可靠存储里 , Cleaner与Replayer则和PaxosLog的裁剪与追数据的重放Paxos过程有关。
状态机(StateMachine) , PaxosLog最终要反映到状态机的状态变迁上，这也是业务数据真正落地的地方。一个PhxPaxos实例可以同时挂载多个状态机，而使用镜像状态机模式进行Checkpoint的自动生成，完成定期归档数据。
网络IO统一托管到Network线程，线程间通过带超时的条件锁通信。

提问

raft代码简单而且开源，为啥不用，却要自研paxos？

虽然raft开源，facebook也在使用，但paxos真正理解后实现起来其实更为简单优雅，而且具有大神经典论文的数学证明，更有google和microsoft多年大规模使用作为证明。另外，自己研发的paxos，更能根据存储的特点进行各方面的定制化。微信海量用户的特点，促使在存储方面有大数据高性能的需求。经过微信后台团队的潜心钻研，基于PhxPaxos定制的强一致、高可用、高性能的PhxSQL便横空出世。

PhxSQL

他是谁？（基本介绍）

PhxSQL（GitHub上他的传记：https://github.com/Tencent/phxsql） 是在MySQL为基础，搭建的一套MySQL分布式系统，涵盖了自动容灾处理，自动数据同步等机制，全程自动化，解救那些被MySQL深深折磨的运维和开发。

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

他为什么这么强？（优势）

1. 支持完整的MySQL功能、客户端无需修改 2. 可完整理论证明的强一致性

解决master／slave之间不一致的问题。
在重启、网络分区、切换主机、更换机器时仍然保持强一致
没有“幻读”，无需人工“闪回”、或者重做数据库 3. 高可用
自动管理master， master出现故障时，slave会自动成为新的master（若条件允许）。
只需要正常工作的机器数目超过一半，即可正常工作
支持多地多IDC部署 4. 高性能
性能与MySQL半同步持平或者更高，加快了主备之间的数据同步。 5. 架构简单
自身独立运行，系统不依赖zookeeper/etcd 6. 运维简单
防止slave被错误写入。
旧master出现故障，新master被指定时，如果旧master机器能工作，则可以实现master重定位，如果机器不能工作，则client端需要自行切换（在后面的版本我们会做到client端支持自动切换功能）

总而言之，PhxSQL的优势在于MySQL整个集群的备份和容灾全自动化，近乎0运维介入，大大的减少了人力物力，有效的减低运维成本和提高了服务的可用性。

他长得怎么样？（架构简析）

PhxSQL架构分3层， proxy、percona（MySQL）、binlogsvr。由它们组成的整套服务，部署在同一个机器上。

binlogsvr：负责MySQL的binlog传输, master管理等。
percona: MySQL分支,并带有PhxSQL团队开发的MySQL插件（phxplugin）
proxy: 负责MySQL的接入，master的跳转等。（注意：下文用MySQL代替percona来描述）

必杀技一：binlog数据

MySQL的binlog有两种，一种是基于binlog文件名加offset，一种是基于gtid。由于binlog文件名在每一台MySQL上都可能不一样，这种模式下会出现很多问题。因此MySQL的数据同步大多都是基于gtid。

什么是gtid？gtid是以MySQL结点的uuid加上结点的sequence来命名，可以达到全局唯一的效果。全局唯一的特性，和对于一个uuid的sequence的单调递增性，对于binlog是一个很好的设计。同步binlog数据的时候，根据gtid就能很容易的做到去重，查找等操作。

必杀技二：容灾策略

PhxSQL的master管理 PhxSQL的master由Binlogsvr管理。Binlogsvr通过paxos完成master的选举，达到master的原子切换。

Master有自己的租期，Master通过paxos来进行heartbeat完成续租。当租期到期时，重新选择新的master。当master发生故障时，由于master的租期问题，会在租期期间服务出现无master的状态。但通常租期只有几十秒。通过heatbeat来续租，可以使一个master在无故障状态下一直持有master身份。

PhxSQL的前端路由 PhxSQL的前端路由通过PhxSQLproxy来完成。当PhxSQLproxy接收到query时，会询问本地binlogsvr是否持有master身份，如果是，则向MySQL提交请求，如果不是，则重定向对应的master proxy，通过该proxy进行对应的操作。

由于master的切换是通过paxos来完成，具有原子切换的效果，因此当master出现故障时，旧master租约过期，新master被选举出来。旧master所对应的proxy将会马上重定向到新的master所对应的proxy，达到自动寻找master的功能。

PhxSQL binlogsvr的master自动管理加上PhxSQLproxy的自动路由，实现了自动容灾的功能，期间不需要运维的任何介入。

必杀技三：一致性

PhxSQL的binlogsvr数据一致性 binlogsvr的数据通过paxos来同步到其他binlogsvr，所以binlogsvr的数据一致性由paxos来保证。由于paxos的原子有序性，因此每一台binlogsvr的数据和顺序都是一致的。

PhxSQL的MySQL数据一致性由于MySQL才是binlog的受益者，因此除了确保binlog的一致性之外，也要保证MySQL的数据和binlogsvr的数据一致。

由于paxos的有序性，很容易可以得知每一个gtid的发送先后，因此每一台MySQL下发的gtid的顺序是一致的，且gtid的可去重性，起到了下发的数据是幂等的效果。保证了每一台MySQL slave的下发数据和master的提交数据是完全一致的。

MySQL的提交，类似乐观锁的机制，每次提交带上本地存储的最新gtid。由于binlogsvr基于paxos存储gtid的原子性和有序性，根据带上的gtid判断是否以最新版本的数据为基础进行提交，防止提交的并发性和落后性。此外，MySQL支持墙头query。当master在写完binlog后发生故障导致binlog未能成功同步到binlogsvr时，在该master重启时会主动回滚该query。

PhxSQL有PhxSQLproxy的前端路由，能很好的保护slave不会被无故写入，造成数据上的错乱，使得MySQL能真正实现事务上的序列一致性。PhxSQL保证了MySQL的本地binlog是binlogsvr的binlog的一个子集。

必杀技四：binlog同步性能

MySQL的groupcommit特性：master的多次写操作能被合并提交到binlogsvr进行binlog同步。

binlogsvr经过paxos同步到其他binlogsvr。Paxos协议只需要一次RTT时间。Binlogsvr数据同步后会写到binlogsvr自己的db，且paxos协议也会写操作记录到自己的db。这个过程会产生两次磁盘的读写。但paxos的协议需要fsync磁盘而binlogsvr的写入不需要fsync磁盘。因此fsync次数为1。

因此，在整个binlog同步机制中，网络延迟为1个RTT时间，写盘次数为2次，fsync次数为1次。经测试，binlogsvr的写入性能可以达到1w/s。

接下来，将会请出本次比武大会的最后一名选手，一个远程过程调用（RPC）框架——PhxRPC（GitHub上的传记：https://github.com/Tencent/phxrpc）。微信后台的RPC框架svrkit久经考验功能齐全，支撑了庞大的业务。而PhxRPC提供了一致的接口形式，轻便简洁，上手和维护成本都很低。

PhxRPC

他有什么属性？（为何需要PhxRPC）

非常简洁小巧的RPC框架，编译生成的库只有450K。
微信内部的RPC框架svrkit太多内部代码依赖，很难整理出来开源。
PhxRPC架构与svrkit相似，是一个简版的svrkit。
PhxRPC服务于微信今后的开源项目，使得开源项目在内外代码保持一致。

他比谁厉害？（为啥不用其他RPC框架）

grpc和thrift等要修改成和内部基础设施结合比较费力。
PhxRPC可以很容易和内部的基础设施结合。

他的技能汇总（特色）

使用Protobuf作为IDL用于描述RPC接口以及通信数据结构。
基于Protobuf文件自动生成Client以及Server接口，用于Client的构建，以及Server的实现。
半同步半异步模式，采用独立多IO线程，通过Epoll管理请求的接入以及读写，工作线程采用固定线程池。IO线程与工作线程通过内存队列进行交互。
支持协程Worker，可配置多个线程，每个线程多个协程。
提供完善的过载保护，无需配置阈值，支持动态自适应拒绝请求。
提供简易的Client/Server配置读入方式。
基于lambda函数实现并发访问Server，可以非常方便地实现Google提出的 Backup Requests 模式。

提问

相比grpc，PhxRPC的优势是啥？

一般使用RPC框架的业务对性能的要求都不会到极致，而更多追求的是开发效率，所以RPC框架之间的优势对比在现在来说其实已经微乎其微。而更应该关注的是上手成本以及维护效率，这也属于开发效率的一环。如果只是抱着玩玩的心态，任何RPC框架都是一个不错的选择，但真正用到业务上，首先必须得做的就是搞懂这个框架的每一行代码，这样当你的业务出现过载或者各种异常的时候，你才有办法快速得到解决方案。正如文章开头所言，PhxRPC小巧简洁，仅server端核心代码也不到1000行，这能大幅提升运维效率。当然从功能性来说远不比grpc全面，但如果刚好够用，PhxRPC绝对是非常好的选择。选RPC框架，简单适合的小轮更胜于复杂庞大的大轮。

微信后台选手的“亮剑比武”大赛到此结束啦，相信各位朋友对每位选手的精彩展示都赞不绝口了吧？如果你仍意犹未尽，小编可以悄悄告诉你，前往Tencent的GitHub账号（地址：https://github.com/Tencent，点击阅读全文可快速访问） 可以读取他们的“武功秘籍”哟！想要修（xue）炼（xi）的心都按捺不住呢！记住，秘籍不白拿，记得点个star！