本文作者：胡炜，阿里云数据库资深技术专家
阿里云RDS for MySQL企业版最大特点是采用了与社区版不同的复制技术，让数据在不同的MySQL实例节点之间传播。复制基于Paxos协议，能够确保任意1/2的节点宕机或者故障都不会影响集群数据的一致性，让MySQL服务拥有真正的RPO=0的能力，可以应对对数据安全性、一致性有高要求的应用场景。
企业版RDS for MySQL的核心复制技术是X-Pax****os。MySQL官方的半同步复制也能够在大部分场景下保证主备之间的数据一致。从实现来说X-Paxos 维护着多个节点的Paxos日志状态机以及数据状态机，是一个远复杂于MySQL半同步复制的复制技术，那在正常的运行状态中，是否X-Paxos的复制就会比半同步更慢呢？首先我们回顾一下两者的技术实现。
开源MySQL半同步复制技术实现
MySQL半同步复制的实现是建立在MySQL异步复制的基础上的。在开启半同步复制时，Master在返回用户的提交之前会等待Slave的响应。当Slave超时时，半同步复制退化成异步复制。这也是为什么半同步无法确保100%用户数据不丢失。具体的流程如下图：
当用户在Slave 服务器上执行start slave命令之后，开始进行主从复制，Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器，并请求从binlog日志文件或者是某个GTID之后的指定位置之后开始发送binlog日志内容。
Master服务器接收到来自Slave服务器的IO线程的请求后，Master Dump线程会根据Slave服务器的IO线程请求的信息连续读取指定binlog日志文件指定位置之后的binlog event，逐个发送给Slave的IO线程。
当Slave服务器的IO线程获取到Master发送的日志后会将binlog日志内容依次写到Slave端自身的Relay Log文件，SQL线程会实时检测本地Relay Log 中IO线程新增的日志内容，然后及时把RelayLOG 文件中的内容解析成sql语句并应用到当前的数据库中。
半同步的实现是让Master在执行完客户端事务提交之后不立刻返回给客户端，而至少等待Slave接收到事务的日志并且写入到relay log 之后才返回给客户端。因此能够提高安全性，确保用户已经提交的数据，至少存在于Master和一个Slave，确保单点故障不会让用户提交的事务丢失。
阿里云RDS企业版复制技术实现
RDS企业版的复制是一个纯异步，流水线驱动的Paxos协议库来驱动的，企业版在使用X-Paxos库的时候使用binlog作为Paxos日志，当集群中的多数派接收到事务日志后返回客户端提交，除此之外X-Paxos使用了高效的并行技术以及传输技术来保障复制的效率。
X-Paxos自己管理集群实例，包含了自动选主以及日志复制能力。企业版本的复制是默认启动的，复制的流程和社区版本的MySQL也存在着一些区别。用户在提交阶段生成binlog之后， X-Paxos就会将其打包发往其他的节点。等到多数派的节点日志写入binlog后，客户端会收到事务提交成功的请求。
两种复制技术大比拼对比结果
我们在相同的环境部署了RDS企业版以及社区的MySQL 5.7 ，实验使用硬件均为8C32G， 两个节点之间的网络RTT为1ms。测试场景我们采用Sysbench的 insert 纯写，纯写场景非常考验日志同步的效率。下图的对比结果横轴代表并发请求数目，纵轴代表QPS，单位为万。
为什么会有这样的差别呢？对比事务的响应时间，以及网络带宽，我们发现虽然X-Paxos的复制耗时略长一点，但是企业版在运行期间网络带宽使用是明显高于社区版本半同步的。这说明企业版RDS的X-Paxos复制技术的并行度更好，这也就能解释为什么测试结果吞吐会有差别，而且这样的优势会随着网络RTT的增加而增加。接下来就介绍一下RDS企业版的复制是怎么做的。
阿里云RDS企业版复制关键技术
1.全异步事件驱动
X-Paxos采用了全异步的事件驱动框架，日志的产生、投递、传输都是由一个统一的线程池来进行调度，并且通过多个IO线程来响应各种变动的事件，异步化的好处是能够充分利用CPU，避免无谓的同步等待，换取最大的QPS吞吐。目前在单个分区Paxos中可以完全的使用多线程的能力，所有的任务都有通用的woker来运行，消除了CPU的瓶颈。
依赖于服务层的多线程异步框架和异步网络层，X-Paxos除了必要的协议串行点外，大部分操作都可以并发执行，并且部分协议串行点采用了无锁设计，可以有效利用多线程能力。
2.Batching&Pipelining并行技术
社区版MySQL的复制采用了单线程同步发送的方式传递Binlog。X-Paxos针对高延迟网络做了大量的协议优化尝试和测试，通过合理的Batching和Pipelining，设计并实现了一整套自适应的针对高延迟高吞吐和低延迟高吞吐网络的通信模式，极大的提升了日志传输的性能。
· Batching：X-Paxos将多个日志合并成单个消息进行发送；Batching可以有效的降低消息粒度带来的额外损耗，提升吞吐。但是过大Batching容易造成单请求的延迟过大，导致并发请求数过高，继而影响了吞吐和请求延迟。X-Paxos有一套自适应的动态调整机制，决定batching的大小，提升吞吐。
· Pipelining：在上一个消息返回结果以前，并发的发送下一个消息到对应节点的机制，通过提高并发发送消息数量（Pipelining数量），可以有效的降低并发单请求延迟，同时在transmission delay小于propagationdelay的时候（高延迟高吞吐网络），有效提升性能。
Pipeling的引入，需要解决日志的乱序问题，特别是在异地场景下，window加大，加大了乱序的概率。X-Paxos实现了一个高效的乱序处理模块，可以对底层日志实现屏蔽乱序问题，实现高效的乱序日志存储。
3.传输压缩技术
在带宽有限的情况下，对传输的日志进行压缩可以有效的节约传输带宽提升吞吐，社区版本的MySQL是采用默认的序列化方式将binlog以字节流的方式传输到Slave端， X-Paxos可以对binlog进行可选择性的压缩。
目前可以选择的包括lz4和zstd压缩算法，两者都能够在压缩率以及压缩解压速率上有非常好的平衡，在测试中能够有效的将传输量压缩到5倍以上，而延迟上只有略微增加，这是CPU和带宽之间的平衡，可以根据不同的网络情况使用不同的压缩技术。
阿里云RDS企业版更换了复制的方式之后获得了强大的一致性能力，并且在传输方面做了一系列的优化来确保复制的吞吐和性能，特别是在高延迟下，可以有效控制带宽获得尽可能大的吞吐。社区的Group Replication也在这条道路上不断演进。
社区版本的异步复制以及基于异步复制的半同步在传输速率上却一直没有太大的进展。如果用户有跨机房跨AZ的容灾部署需求时，传统的半同步复制方式有时会成为系统吞吐的瓶颈，此时RDS企业版可以成为一个更好的选择。
网友评论