嘉宾 | 崔京
采编 | 木环
在投入运作的一定数量的服务器中，每月都会有硬件故障的发生；此外，还有如断电、人为误操作、***等情况。除了在源头上尽可能避免事故，还需要做好事故的应对方案。为了保证事故灾难发生后数据的可靠性，阿里云研发了MySQL三节点方案，每个节点同步地都存放全量的数据。
该项目是在AliSQL基础上，引入Raft协议来解决MySQL多节点复制上的一致性选主的难题。其中，前者AliSQL是基于MySQL官方版本的一个分支，由阿里云数据库团队维护；于2016年8月开源，InfoQ曾经报道了《专访丁奇：阿里云即将开源AliSQL，超大并发、针对秒杀优化》。这一次，InfoQ也采访了该方案的技术负责人。
分布式数据可的一致性问题纵观整个分布式数据库领域，大家要解决的问题都是相似的，只是实现方法会各有不同。问题有哪些呢？
第一是容错性，我们现在普遍使用的PC Server服务器，硬件本身的可靠性并不高，如何应对硬件的不可靠，是软件（包括数据库）需要去解决的问题。
第二是扩展性，又回到这种服务器，自身存储和计算都有上限，一个普通的业务放进来就有可能触达天花板，如何突破？
在实现上，随着软硬件的发展，业界也在不断地创新。不过目前从本质上，容错性大多是依靠多副本数据冗余（Redundancy），扩展性大多是借助于数据分片（Sharding/Partition），只是大家分别在不同的层次来实现而已。（计算机技术是分层的，比如虚拟裸设备层、文件系统层、数据库存储引擎层、数据库协议层包括应用层都会有自己的分布式实现）
三节点目前采用的是数据库协议层的多副本数据冗余，在 AliSQL 内核中引入 Raft 协议，借助 MySQL Semi-sync Replication 实现日志多副本同步复制，来确保数据的强一致性，提供金融级的可靠性。多个节点之间的数据是实时同步的，每个节点的数据都是全量的。
正常情况下，主节点（Master）向备节点（Slave）单向传输日志，在主节点执行的所有事务的日志都会至少传输到一个备节点然后才能提交，这样就保证一旦主节点故障，备节点数据是完整的。如下图所示：
不仅在正常情况下提供强同步，确保数据不丢。在异常情况下，发生主备切换时，为了确保多节点间的数据一致性，我们也做了非常多的工作，引入了大量边界条件的判断，完善各种故障场景下的测试用例，通过不间断的暴力测试来验证系统的可靠性。
比如：
假如主库在阶段②发生故障宕机，这时主库已经写成功，但备库relay log并没有写入，主备库数据将会不一致。由于Client也未收到Commit返回，因此当主库恢复后我们会把这条备库没有写入的事务通过Flashback方法回滚掉。
但是如果在阶段③和④主库发生故障，数据都已写入主备库，并不会引起不一致，因此并不需要特殊处理，但由于应用没有收到commit，这个需要业务进行容错。
我们其实放弃了P（Partition tolerance，分区容错性），获得了C（Consistency，一致性）和A（Availability，可用性）。上面讲到了MySQL三节点只是做了多副本同步，并没有做Partition。
只有主节点可读写的设计也降低了全局一致性的要求，只需要多数节点同步即可。正是因为这个特性，使得宕掉一个节点不会破坏多数派协议，数据库照样可写，从而提升了整体的可用性，满足A的要求。
此外，至少两个节点的强同步可以确保数据至少有两个完整的副本，主库故障数据0丢失，可从而提升整个数据库实例的可靠性。
另外，由于复制方式采用的是更高层级的MySQL原生协议，不受物理网络条件限制，可以做跨机房部署，这样就能实现机房容灾。但考虑到机房间网络延迟对同步复制的影响，目前仅提供同城多机房的部署方式。经过对比测试，在阿里云 华东1（杭州）相比同机房（单可用区），跨机房（多可用区）的实例性能损耗在5%以内。
那么，如果单个节点发生故障？据不完全统计，每50台投入运作的服务器中平均每月都会发生一起硬件故障（2%/月）。我们的两节点和三节点都是Primary-Standby模式，也就是备用节点都是离线的，不直接提供服务，因此只有主节点故障才会影响整个数据库实例的可用性。从这个角度上来讲二者发生的概率是一样的。
故障是不可避免的，我们要做的是尽量降低故障对我们的影响。一方面是减少故障时长（RTO），另一方面是降低故障影响避免数据丢失（RPO）。
某个节点发生故障，有两种情况：备库和主库。
备库故障对用户无影响，主库故障会在60s内完成切换，应用不需要配合即可恢复业务。（多说一点，阿里云MySQL提供了高安全模式的访问链路选项，中间会存在代理层，可对应用屏蔽95%以上的切换影响）
当主库故障时，所有备库上的Failover服务开始工作，首先等待自己应用完RelayLog，关闭连向主库的复制通道IO_Thread，然后使用Raft协议进行选举，结合所有备库的数据完备性，最终选择与主库同步的节点成为新主库。紧接着，整个集群的复制通道也会重建。
MySQL 三节点在 AliSQL 5.6 基础上进行开发，100% 兼容 MySQL 协议，原有使用 MySQL 数据库的任何应用都可以无缝切换到三节点实例上。所以就把他当成是一个普通的MySQL数据库，只不过相比自建数据库，提供了更高的可用性和可靠性。
关于这套AliSQL+ Raft的组合拳阿里开源的AliSQL就是阿里云MySQL数据库产品实际使用的内核源码，是阿里云数据库团队维护的一个MySQL分支。在AliSQL上的持续6年不断积累的基础上，引入Raft协议来解决MySQL多节点复制上的一致性选主难题。
在不损失可用性的前提下，MySQL三节点方案以较高的数据冗余度来换取更好的可靠性，同时支持跨机房的部署方式，具备机房容灾能力。据悉，这款MySQL三节点企业版已经开始公测，目前已有部分用户申请并使用，包括互联网金融、零售电商、汽车制造、政府、人工智能等各个行业。在问及该方案适合于何种用户时，乙休回答InfoQ目标群体是对数据安全可靠性要求较高的场景，比如新金融领域，尤其适合互联网金融、保险、证券等高端企业级用户。
刚刚问世的MySQL三节点项目依然还有要攻下的山头，乙休称一方面要挑战性能极限，另一方面会大幅提升扩展性，提供更高的配置和容量。同时，在新硬件和引擎内核层面会持续性投入，以提升用户体验增加性价比。
作者介绍崔京，8年数据库行业经验，擅长数据库性能诊断和高可用架构设计，关注下一代超大规模云数据库产品的发展演进方向。