MySQL作为世界上最流行的关系型数据库(RDBMS)之一，在互联网、云计算、零售电商等各行各业均有广泛的应用，普及率非常之高，用户基础良好。
随着云计算技术的逐渐普及，使用云服务的客户行业、场景的边界也在不断地被拓宽，不断提出新的需求。在最早尝试云计算的互联网行业带领下，金融、保险等行业都开始拥抱云计算，而以银行、证券为代表的很多公司对云数据库服务提出了更为严格的要求：要像他们现在基于昂贵的传统IOE构建出来的数据库系统那样，任何情况下都要保证数据不能丢失、损坏。于是在这样的背景和客户驱动下，我们希望通过增加副本数，在不损失可用性的前提下，提供更高的数据可靠性，给客户更多的选择。
在这样的背景下，MySQL三节点企业版应运而生，它是一款面向高端企业级用户的云数据库系列，除了维持原有的MySQL兼容性和可用性，还在AliSQL内核中引入Raft协议，借助MySQL Semi-sync Replication实现日志 『多副本同步复制』，来确保数据的强一致性，提供金融级的可靠性。他是如何做到这一点的，我们通过对比，进行简单分析。
双机高可用版
为了便于理解，我们先回顾下双机高可用版。
RDS双机高可用版采用一主一备架构，利用原生的逻辑复制，确保数据在两个节点同步，这种Share-Nothing的架构通过数据冗余获得了较高的可用性，是在成本、性能、可用性及可靠性之间权衡的结果。
这里有异步、半同步和双通道三种复制模式。
异步复制
为追求主库的性能及可用性，binlog以异步的方式复制到备库，因此不需要收到备库的反馈，事务即可提交。当主库故障的情况下，备库的数据可能是不完整的。
目前对 RDS for MySQL 5.5/5.6 提供这种模式。
半同步复制
半同步复制（Semi-sync Replication）默认采用同步机制进行复制，但为保证主库的可用性，一旦备库响应（ACK）超过1s（时长可配置），则退化为『异步复制』模式。因此这种情况下，备库数据也无法保证与主库完全同步，甚至当主库故障时，备库也无法知道自己的数据是否是完整的。
· 目前对 RDS for MySQL 5.5 提供这种模式。
· 对于MySQL 5.6，提供了增强版的半同步复制（双通道），细节可查询相关资料，不再赘述。
三节点企业版
三节点最大的亮点在于其较高的数据一致性和可靠性保护。
可靠性
三节点企业版，顾名思义，底层维护了三个数据库节点，一主两备的复制拓扑结构意味着每个节点都是全量的数据，数据库事务日志（Log）从主库同步复制到所有的备库，当集群中超过半数的节点都写入成功后，事务才能完成提交。虽然是同步复制，但由于是三个点，因此单个节点的故障不会影响到实例整体的可用性。这种设计的好处显而易见，即在不损失可用性的情况下，通过较高的数据冗余度来换取更好的可靠性，同时支持跨机房的部署方式，具备机房容灾能力。
如上图，对于每一条事务，执行（Execute）完成，写入binlog后，会同步发送给所有备库，当其中一个备库写入Relaylog，并返回响应（ACK）后，主库才完成提交（Commit）给应用（Client）返回。当主库故障时，至少可以找到一个备库具有完整的数据用于切换，并且通过Raft协议确保切换时的可靠性和原子性，保证任何时候都只有一个Leader（Master）可写。
在传统的复制模式下，主库和备库的状态受控于外部组件，很容易出现复制冲突、数据不一致问题。三节点在实现中，主备库的角色由内部通过选举决定，内核把集群内的所有节点当成一个整体来管理，从根本上解决数据一致性的问题，确保在整个Failover过程中主备数据的一致性。由于篇幅所限不能一一展开，举个例子简单说明。
· 假如主库在阶段②发生故障宕机，这时备库relay log并没有写入，主备库数据将会不一致。由于Client也未收到Commit返回，因此当主库恢复后我们会把这条备库没有写入的事务通过Flashback方法回滚掉。
· 在阶段③和④主库发生故障，数据都已写入主备库，并不会引起不一致，不需要做特殊处理，但由于应用没有收到commit，这个需要业务进行容错。
机房容灾
在满足三机房的Region，我们会提供多可用区部署。三个节点位于三个机房，整合依赖组件，全链路考虑，确保单机房故障时的数据可靠性以及整个实例的可用性。
此外，未来结合RDS的灾备实例，可轻松实现跨城的两地三中心部署方案，满足行业要求。