阿里云RDS for MySQL 的企业三节点版本是阿里云推出的全新的MySQL系列云产品，是AliSQL的集群解决方案。 AliSQL是阿里巴巴集团的MySQL 分支， 除了继承了官方MySQL的所有特性之外，沉淀了大量在阿里巴巴内部业务以及云上几十万客户的需求，并经历了严酷的线上考验，在稳定性和易用性上都具有良好的保障。
MySQL 5.7 依然是目前MySQL 最为成熟和稳定的大版本，有着最为庞大的用户群体。 5.7 在性能、灵活性、功能上相比之前的版本都有较大程度的提升。 其中包括更高效的并行复制（基于组提交的logic clock 算法以及基于主键的write-set算法），大幅改进的优化器和成本模型、更好的SSL的支持、虚拟列、虚拟列索引、全新的JSON以及GIS等等
RDS企业三节点版是基于AliSQL的集群版本的全新云数据库产品，集群版本和普通版本最大的区别是采用了Paxos进行Binlog日志和数据状态机的协调，确保数据的一致性。是一个真正的跨可用区数据强一致的解决方案，RPO（最多可能丢失的数据的时长）为零。
架构
集群内所有节点的日志复制采用paxos库进行多数派决议，而非传统的MySQL I/O线程复制。完整的架构如下图所示：
一个默认规格的三节点集群会分别部署于三个不同的可用区（AZ）内，根据paxos算法集群会自动选举出一个leader提供对外的服务，一致性算法采用leader based的multi-paxos，
事务的提交、回滚以及节点的恢复全部交由Paxos来控制。任何一个时刻，某个节点想要成为主节点对外提供服务就必须要有多数派的节点同意，任何一个节点上想要提交一个事务也必须有多数派的节点认可并持久化事务的日志。因此三节点的技术可以从根本上杜绝因为网络分区导致的脑裂问题。
RDS 企业三节点目前只有在至少拥有三个可用区的地区售卖（包括杭州、上海、北京、深圳、新加坡），三个节点分别部署于三个AZ之内，因此任何一个节点、甚至是一整个AZ的故障（机房断电，机房网络故障）都不会影响到整个对外的可用性和数据的一致性。 因为剩余的两个节点至少有一个节点保有最新的事务日志，并且它们仍然可以达成集群的多数派决议，保证对用户的服务正常。
网络传输优化
利用Paxos来进行日志传递有一个更大的优点是能够充分利用主机网络的带宽， 相比传统的MySQL I/O复制线程发送binlog的机制，Master 是一个一个Event进行发送， 而传统的半同步插件的ack线程爷只有一个Paxos传输模块中我们使用了多线程发送、异步乱序、批量化、流水线化、传输压缩、多线程ack等优化机制， 在跨AZ的网络中能够达到更大的网络吞吐。
除此之外，Paxos的传输模块还做到了自动探测网络环境，根据负载和带宽大小，自动在大batch、流水线乱序、以及压缩非压缩之间进行动态的选择， 确保能够自适应不同的网络环境和负载。
集群自运维能力
三节点企业版是一个高效的自运维系统，不再需要任何外部来建立复制关系，复制位点。Fail over 集群内部自动完成，因此相比主备来说更加的高效。 每个集群目前都会有主节点会定期向集群中的其他两个节点发送心跳来续租， 目前这个租约期为10s， 如果10s的时间里有非Leader节点一直没有收到当前Leader的心跳，那么就会开始发起投票， 如果有多数派的节点同意（三节点中除自己之外其他任何一个节点同意），则新的Leader上任，完成切换。 这种做法能够覆盖节点宕机以及网络异常的情况。 然而还有一种情况是主机存储设备故障、可能是IO无法进行或者特别缓慢，对业务是存在影响的，但是会给传统的HA带来困扰。 三节点企业版增加了存储自检的机制，增加了一个对于存储异常的Monitor检测，检测线程会定期探测日志和数据所在的位置的IO能力以及IO队列的长度，综合判断后决定是否立即将leader的角色转让给其他的节点， 确保单盘的IO异常或者故障不会影响集群整体的可用性。
Paxos 日志的优化实现
RDS企业三节点利用了5.7 multi-channel replication的机制，利用了一个特殊的channel来作为paxos复制使用，这样使得企业三节点同时可以支持paxos集群复制也同时支持常规的主备复制。 我们对paxos channel的日志进行了定制改造， 使得Paxos协议能够在binlog的框架下运转起来。
三节点的事务提交流程如下图所示：
其中第二阶段Leader 节点在本地写binlog 的同时就会向集群中的另外两个节点发送日志，其他的两个节点收到日志后直接作为binlog落盘，传统的复制下， Slave收到Master的日志后先写一份relay log， 然后SQL线程读取分发后执行更改并在提交时再生成一份BINLOG。Paxos channel 没有意义上的relay log 直接就使用了binlog本身， 这样以来最大的好处就是所有的事务日志只需要落盘一次，并且从节点回放事务日志时不需要做一个内部二阶段提交，可以提高回放的效率。第三阶段Leader在本地Binlog落盘以后，只要收到任何一个集群中的节点的回包ACK就能够成功提交事务。
异步化事务提交
RDS企业三节点在引入线程池后，可以利用有限的线程来处理大量的用户请求， 然后为了达成数据的强一致，执行线程必须等待事务日志的多数派达成，因此如果在节点间网络rtt比较明显时如果大量线程都在等待其他节点回包会导致CPU的大量浪费从而影响吞吐，三节点企业版改变了单一线程处理用户事务的模式，为每个事务增加了多个异步等待队列，单个事务不再由单个线程来完成所有的工作， 而是分别交由不同的线程来完成， 用少量的线程处理网络回包，从而把大量的CPU用于处理用户请求，在用户的大压力下可以获得非常显著的吞吐能力提升。
只读节点的数据一致性
传统的主备下只读节点是一个不开启semi sync的从节点，在主节点failover的情况下只读节点是有一定的概率会多出一部分旧主上未同步到从库的binlog日志，因此容易导致只读节点和新的主节点的数据不一致， 才遇到这种情况后或者是通过flashback（如果不一致的是DDL事务则非常难处理）或者是重建节点。 在企业三节点中我们对日志发送端做了优化， 主节点会在确认多数派节点持久化后的事务日志才会传输到只读节点。 只读节点会增加一个网络RTT的延时（跨AZ部署的集群一般在1ms左右）但是只读节点只会接收到不会回滚的事务的日志，这样无论如何HA，只读节点都不会遇到数据不一致的情况。
企业级特性
除此之外RDS for mysql 5.7 三节点企业版相比社区版本增加了企业应用特性，比如相比Percona更好用的连接池，SQL限流、动态执行计划绑定、主键查询优化、更丰富的慢查询信息、功能更强大的KV访问方式、性能更强大的GIS查询，更有针对性的秒杀场景优化。 特别要提的是秒杀场景的优化， 三节点企业版提供了热点更新合并的能力， 可以在数据库内部将会批量搜集对于同一行的热点更新事务， 并且对更新操作在存储引擎层进行动态合并，从而实现上吞吐量级的提升，可达数万次每秒的热点行更新处理能力， 这是在阿里集团内部使用非常广泛的技术，也是近几年双十一、新春红包等场景背后最重要的技术支撑能力。
总结
RDS三节点企业版是在阿里巴巴场景下经过充分的验证之后推出的升级版RDS for mysql服务， 也是阿里云第一次把AliSQL Cluster集群版方案推出服务云上客户。适合对数据一致性和服务连续性要求高的客户使用。其额外提供的企业特性能够满足不同场景下的业务需求。