如何通过技术实现更好的业务可靠性保障？在特殊情况下如何实现业务、数据的恢复、容灾和多活？如何在实现多活业务架构中降低系统架构的复杂性及 IT 成本？
本次，青小云从技术角度出发，推出「真正多活，不惧宕机」系列专题文章，为大家解密高可用的企业 IT 架构背后的技术实现，同时也会从一些具体的电商、金融客户案例中，给大家带来一些经验分享，帮助从业者快速掌握自身业务高可用和多地访问、容灾备份等业务场景的具体应对之策。
数据库服务于企业的核心交易业务和实时交互应用，承载着企业的核心数据，因此企业对于数据库的数据一致性和高可用性有强烈的需求。
今天的内容主要集中在金融级数据库如何保证自身的高可用，支撑企业业务稳定运行。
金融级数据库——MySQL Plus
作为 MySQL 的升级版本，QingCloud MySQL Plus 是一款具备金融级强一致性、主从秒级切换，集 InnoDB + TokuDB 双存储引擎支持的增强型 MySQL 集群应用，适用于对数据一致性和高可用性有强烈要求的企业用户。
目前关于 MySQL 集群的方案、架构比较多，常见的方案是存在中心管理节点。而 MySQL Plus 的一个核心特性就是无中心化自主选主，不需要依赖中心节点去管理控制集群中的服务节点。
另外两个特性：一是集群数据强一致性；二是集群主从秒级切换的特性。
MySQL Plus 核心架构
MySQL Plus 是基于 Raft 构建的 MySQL 中自动选主及维护主从的套件，上图是 MySQL Plus 的核心架构，一个典型的 3 节点集群。之所以这样配置是因为： Raft 协议的机制要求集群节点数是奇数个，例如 3 个节点、5 个节点和 7 个节点。
图中圆圈节点是 Xenon 进程，可以认为它是一个 Agent。在其下面为 MySQL 服务，一个主机节点上会有一个 Xenon，它会管理 MySQL 服务。每个节点上有一个 Agent 和 MySQL 服务，Agent 之间通过 Raft 机制来为集群选主。
通过 MySQL 本身的 Semi-Sync 实现数据同步，在数据一致性层面完全由 MySQL 本身的同步机制实现。Raft 主要用于选主，每一个 Xenon 进程会探测 MySQL 服务是否正常，集群中 Leader 节点会定期向 Follower 节点发送心跳，Follower 节点接收 Leader 节点心跳超时后会发起新的选举。
以上就是 MySQL Plus 的一个整体架构。
MySQL Plus 实现原理
Raft 主要有两个功能：一是选主，二是数据同步。
MySQL Plus 只用 Raft 的选主功能，数据同步是基于GTID + Binlog方式，多数派确认通过 Semi-Sync 机制。
下面详细和大家介绍基于 Raft 选主和 Leader 自动降级机制，以及关于 Semi-Sync 的一些配置。
Raft 选主机制
如上图所示，MySQL Plus 集群节点的三种状态：一是 Leader，二是 Follower，三是 Candidate。
Leader 会定期给 Follower 发心跳，以确定这个节点的状态。Follower 节点会定期接收 Leader 的心跳，当 Follower 无法接收到 Leader 的心跳，它将会变为 Candidate 角色，并发起选举操作。
Leader 定期给 Follower 发送心跳，如果 Follower 无法接收 Leader 发送的心跳，它会把自己的状态变成 Candidate，然后向所有的节点发起选举请求，如果它能获得多数(n/2 + 1，n 为集群节点数，比如 3 节点集群至少需要获得两票赞成票)节点投的赞成票就会提升为 Leader。
Raft 选主规则
集群选主机制，主要基于 Raft，跟 MySQL 相关的是选主投票时，如何决定投赞成票，这与 MySQL 相关，通过比较 binlog 位点决定是否给候选人投赞成票。
集群初始节点状态都是 Follower ，所有 Follower 节点定期接收 Leader 心跳，如果在超时后没有接收到 Leader 心跳，就会发起选举。接收到选举请求节点会通过比较 MySQL binlog位点来决定是否投赞成票。
发起选举的节点如果获得多数票，就会成为 Leader，如果没有获得多数选票，则会把自己的状态降级为Follower。
左图是上面介绍的集群选举的一个过程。集群初始化起来后，这三个节点是 Follower 的状态。其中有一个节点 Timeout，等待接收 Leader 的心跳超时后，它自己会成为 Candidate 状态，会给其他节点发起投票。如果其他节点给它投的赞成票，这个节点就会当选成为 Leader。
右图是选主结束后集群正常的状态。Leader 节点定期给其他节点发送心跳。Follower 节点会从 Leader 节点同步数据。
集群节点不同角色状态时对应的操作
集群中节点成为 Leader 后，需要定期向Follower节点发送心跳，检查、获取集群中所有节点的状态。
对应的 MySQL 服务作为 Master节点，首先要等待 Relay-log 应用完成，其实就是 SQL 线程将 relay日志重放完， 然后 Stop Slave，清理复制配置信息。
下来设置数据库服务可以读写。等完成这一系列操作后，整个集群对外可用，这时候才会启动 VIP，应用就可以连接进来。
Leader 降级处理，首先会把 VIP 停掉，保证集群处于不可用时，不会对外提供服务。Leader 会把自己降级为 Follower 角色。
Follower 会接收 Leader 心跳，接收到 Leader 心跳后，根据Leader节点信息，配置并启动复制线程，从 Leader 上同步数据。
Candidate 比较简单，发起选举，获得多数票后成为 Leader，获得少数票会降级为 Follower。
Leader 自动降级机制
以上是集群节点不同角色对应的操作处理，下面介绍下 Leader 自动降级机制，基本分为两种情况：第一，网络隔离问题；第二，Leader 故障。
网络隔离的故障处理，Leader 节点跟 Follower 节点之间网络不通，这种情况下，Leader 会把自己降级成 Follower。
其他 Follower 节点无法接收 Leader 发送的心跳，会把自己变为 Candidate，然后发起选举。获得多数选票后，把自己升级为 Leader 节点，这时候整个集群可以对外服务。
MySQL 服务不可用之后，Leader 会把自己降级成 Follower 角色。降级成 Follower 角色后，整个集群中目前没有 Leader，这两个 Follower 节点接收 Leader 心跳会超时，其中有一个节点会发起选举。
目前集群中剩余的两个 Follower 节点至少有一个节点跟之前 Leader 节点数据完全一致。如果集群中数据同步有延时的节点首先发起选举，会收到完整数据节点投的反对票，发起选举失败会降级为 Follower 角色。
拥有完整数据的节点接收 Leader 心跳 Timeout 后会把自己变成 Candidate，发起选举。这时候数据不完整节点会给它投赞成票，加上自己的一票，获得两票赞成票后会升级为 Leader。变成两个节点后，这两个节点之间目前是完全强一致的同步。如果故障节点恢复加进来后，整个集群中只要有一个节点数据跟主节点保持一致就可以了。
前面谈到 MySQL Plus 其中一个特性就是秒级切换，集群故障后，不需要依靠其他的中心节点，集群内的节点可以快速选出主节点。通过数据库并行复制和相关 I/O 参数的优化，切主后能快速重放完成 Relay 日志对外提供服务，实现集群秒极切换、服务快速响应。
Leader 故障后，大家会想到数据一致性问题。MySQL Plus 是基于 Semi-Sync 机制做的数据同步，比如三个节点，集群中会至少有一个从节点跟主节点数据保持一致。
MySQL Plus 中 Semi-Sync 配置
大家对 MySQL 比较了解，也比较熟悉 Semi-Sync 机制。MySQL Plus 集群用的 MySQL 是基于 5.7 版本的，对于 rpl_semi_sync_master_timeout 参数设置比较大，所以不会出现降级的情况，参数 rpl_semi_sync_master_wait_point 默认配置是 AFTER_SYNC，来避免出现幻读的情况。
前面大家看到的是三个节点集群，通过 Semi-Sync 机制，集群中配置的 rpl_semi_sync_master_wait_for_slave_count 是 1，如果是 5 个节点，需要配置成 2，至少要保证集群中有 2 个从节点和 Leader 的节点数据保持一致。
MySQL Plus 自动化运维
目前集群数据同步主要依靠 MySQL 自身的复制，MySQL 本身的复制由于一些原因，或多或少会存在不稳定的情况。
MySQL Plus 提供自动化运维的工具，通过这些工具可以获取集群的状态，对集群中故障节点做诊断，对于预期的故障类型，可以快速对故障节点进行自动化重建。
获取集群的状态，包括 Leader、Follower 及 SQL 线程的运行情况。获取集群状态后，可以了解到 IO 或者 SQL 线程的状态，针对错误信息来做相应处理。
获取集群 GTID ，了解节点 GTID 的变化，可以了解节点数据同步是否存在异常。
例如，通过比较时间段内节点获取到的 GTID 和 已经执行的 GTID 变化，来判断SQL 线程重放是否有 wait 或者 hang 住的异常情况。
这是 MySQL Plus 提供快速重建的工具，是基于 Xtrabackup 做的。当集群中有节点故障，需要重建时，可以通过 Rebuildme 工具快速重建，节点快速恢复后会自动再加到集群。重建可以基于 Leader 节点，也可以指定基于某个节点重建，避免对 Leader 节点产生过多的负载影响。
目前青云新用户基本使用的 MySQL Plus，很多老用户也在逐步迁移到 Plus。上面是 QingCloud 云平台上 MySQL Plus 的几个相关监控展示，包括事务提交，查询数量、连接数。还有一些没有列出来的，如慢查询、全表扫描相关等。
总结
◆ ◆ ◆
认识高可用架构，部署实现实现高可用架构，每一家互联网企业可能摸索出数千种探索道路并给出数万种答案，但符合自身企业技术环境发展的答案可能有且只有一种，帮助用户用最快速度安全便捷方式构建高可用系统，是青云QingCloud 一直在努力实现的目标。
