共计 2568 个字符，预计需要花费 7 分钟才能阅读完成。
简介：摘自刘永平（慕少）阿里云 PolarDB-X 技术专家在 PolarDB-X | 新品发布会中的解说内容。
理解更多 PolarDB-X 内容：https://developer.aliyun.com/…
一、DN 高可用计划
1.png
在 PolarDB-X 的系统结构中，DN 组件负责数据存储。一个 DN 节点是 一个 MySQL 实例。
为了数据安全，咱们须要多正本，一个逻辑实例是由多个 DN 节点组成的集群。
为了业务间断，咱们须要高可用，当局部机器或网络故障后集群仍然可能继续提供服务。
这些能力都须要 DN 节点自闭环实现，如果再引入第三方组件来治理，那么第三方组件的高可用又将是新的问题。
2.png
单机 MySQL，或者其余数据库，罕用的高可用计划有以下几种：
第一种是经典的一主一从构造，基于 KeepAlive 进行 HA 治理；
第二种具备更高的可靠性，能够一主多从，用更简单的节点管理器协调系统的运行；
另外还有 MySQL 社区的多主复制，有基于共享存储的部署模式等。
以上解决方案都有其各自适宜的利用场景，但在设计上，须要思考的问题是相似地，那就是：
实践上 CAP 中的分区可用性和数据一致性如何取舍？
工程上实现的复杂度、稳定性以及高可用对性能带来的损耗有多少？
3.png
PolarDB-X 的 DN 存储集群采纳了强统一计划，集群通过 X-Paxos 一致性协定进行数据复制。其特点是：
1) 在有 2n+1 节点的集群中可容忍最多 N 个节点故障；
2) 节点间数据强统一，对利用而言，RPO=0 内置了一致性协定；
3) 暗藏了简单的节点治理逻辑。
所以，此计划的外围是一致性协定的应用。
二、X-Paxos 协定
4.png
X-Paxos 是 Paxos 协定的具体实现，基于多数派实践保证数据一致性，其实践根底是经典的 Paxos 论文。
当协定失常运行时，集群中有一个 Leader 节点，其余为 Follower 节点。业务申请从 Leader 进入，Leader 将申请转化为一条增量日志并将日志播送到所有 Follower；等少数节点确认收到日志后，Leader 将日志利用到状态机，返回业务响应。过程中只有少数节点衰弱，协定就能失常运行，且可能保障集群数据的强统一。另外，在协定模型中还有 learner 角色，它不参加多数派决策，只是集群数据的订阅者。
协定的要害算法有两局部，首先是选主，选主是一个共识的过程，保障集群中同时只有一个 Leader 并且 Leader 已领有达成多数派的所有日志；其次，日志复制，即上图中的运行过程。
5.png
Paxos 是分布式协定，是音讯或事件驱动的异步解决模型。X-Paxos 测试协定组件有四个模块：网络层提供根底的异步网络通讯框架；算法模块实现协定的业务逻辑，包含选主、日志复制、源数据管理等；服务层是调度核心，负责响应定时器和网络事件，驱动算法模块的运行；日志解决本属于算法领域，但 X-Paxos 实现时将日志解决逻辑形象出通用接口，在算法模块调用接口，使日志的具体实现能够在日志模块实现，并且能够独自优化。
三、DN 高可用体系
6.png
MySQL 是多引擎架构，事务提交分为两阶段，第一阶段为引擎 Prepare，第二阶段进入 Binlog Ordered Commit。
Ordered Commit 为分组提交，又分为三个过程：Flush 将 Binlog 内容写到 Binlog 文件，Sync 将 Binlog 文件内容长久化，Commit 是引擎提交。
引入一致性协定后，Leader 节点上，在 Binlog 的 Flush 和 Sync 过程中将 Binlog 内容同时播送到所有 Follower。多数派达成后，Leader 再发动最初的引擎 Commit，以保证数据的强统一。
因为集群中只有 Leader 提供服务，所以 Leader 的状态对系统可用性至关重要。
7.png
Leader 任期内，所有 Follower 都不再发动选主申请，也不投票其余节点的选主申请。然而任期过后，如果 Follower 发现 Leader 曾经异样，将从新发动选主；如果 Leader 发现自己和少数 Follower 的通信异样，将主动降级，发动选主申请。
大部分状况下，集群各节点的状态都失常，Leader 节点的被动心跳会放弃他的 Leader 位置，集群不会产生 HA。
8.png
默认状况下，集群内所有节点都偏心选主。当心愿某些节点优先对外提供服务，能够对这些节点赋予更高的选主权重。权重高的节点入选 Leader 的几率大，但这是弱限度，不保障相对按权重选主。因为选主最根本的准则还是节点须要领有集群中曾经达成共识的所有数据，这是相对限度。
9.png
DN 集群节点间同步的数据是 Binlog，当新主被选出后，须要实现两个步骤能力对外提供读写服务：一是将日志同步给其余落后的 Follower 节点，二是将本节点 Binlog 利用到最新位点。如果须要利用的 Binlog 很多，Leader 将迟迟无奈对外提供服务，从而影响零碎可用性。此时 Leader 会探测其余 Follower 节点，如果发现更适合的，则会将 Leader 角色让出。
10.png
定义集群是否可用，最终还要看以后 Leader 是否够提供业务服务。有时候从协定层面看，集群是衰弱的，然而 Leader 节点的业务服务异样，比方磁盘满，则此时集群不可用。因而 Follower 节点会定期向 Leader 发动反向心跳，用于检测 Leader 的业务服务是否失常，如果不失常则从新选主。
四、DN 部署和优化
11.png
上图为最罕用的部署模式，三个节点参加集群决策，一个或多个 Learner 作为订阅者提供只读服务。此处 Logger 不是一种新角色，在协定层面，它就是 Follower，但它不回放 Binlog，仅保留 Binlog，用于整个集群数据的强统一，可能缩小一份 MySQL 实例的数据空间，升高存储老本。
12.png
同城 3 正本部署模式实现了三个可用区各一个节点，两个实体节点，一个 Logger 节点，相比传统的主备模式，根本不减少存储老本，然而能够实现数据的强统一。
13.png
跨城 5 正本模式下，有了更多节点后，能够实现单 Region 不可用的容灾，同时配合权重选主能够定制 Region 的切换程序。
以上就是是对于 PolarDB-X 高可用存储服务的整体介绍。
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。