阿里自研分布式强一致关系型数据库——XDB,阿里分析型数据库-ESG跨境

阿里自研分布式强一致关系型数据库——XDB,阿里分析型数据库

阿里自研分布式强一致关系型数据库——XDB

0写在前面

今年双 11 是 XDB 的第一次大考，本次双 11XDB 服务于天猫 / 淘宝核心交易系统、核心物流系统、核心 IM 系统，经受了零点业务 32.5 万笔 / 秒峰值的性能考验（对应数据库峰值每秒破亿次的 SQL 调用）；同时 XDB 支撑起了新一代单元化架构，在分布式一致性算法 Paxos 的统一框架下，第一次提供了跨 Region 分布式强一致能力，实现高效的跨 Region 数据同步、跨 Region 容灾，保证金融级的数据质量服务。

XDB 为了降低用户的迁移和学习成本，选择了兼容成熟的 MySQL 生态，并且做到了真正 100% 兼容 MySQL 生态，为业务，为传统数据库赋能。基于 MySQL 的业务可以无缝从 MySQL 迁移到 XDB 上来，不需要任何评估和兼容测试，完全零成本迁移。基于 MySQL 的周边工具平台，甚至是 MySQL DBA 都可以非常平滑的转移到 XDB 上来。阿里内部从今年 6 月初第一个业务应用灰度切流，到目前为止 5 个月的时间里，XDB 已覆盖了阿里集团及多个关联公司旗下的多个事业群，为海量的线上业务提供服务，整个过程绝大部分业务都是无感知的。

XDB 拥有真正的跨 Region/ 跨国的数据强一致能力，并已得到实践的检验。双 11 前夕，核心物流系统、核心 IM 系统首次完成了中心 Region 所有数据库不可用的“中心城市容灾演练”，验证业务拥有在整个中心 Region 均不可用情况下，XDB 和应用仍可以正常提供服务的能力，并保证数据零丢失。

1XDB 的核心优势和技术解析

XDB 是阿里自研的全球级分布式关系型数据库。现在业界各种类型的分布式数据库不断涌现，互联网巨头、传统数据库厂商、数据库创业公司都在不断跟进。那么 XDB 到底有什么优势能战胜这些竞品，快速获得业务价值呢

1. XDB 生态 100% 兼容 MySQL

新一代分布式关系型数据库是对传统关系型数据库的传承和革新。分布式数据库虽然在高可能、强一致、高性能、低成本、高伸缩等多个方面作出了划时代的变革；但其依旧传承了传统数据库强大的 SQL 接口，系统管理能力。NoSQL 的衰弱和 NewSQL 的兴起，恰恰证明了这一点。一个新的分布式数据库，如果没有传承，自建一个新的生态，将会极大的提高用户的学习和使用成本，整个工具和支持配套也将面临很大的困难。因此，XDB 作为一个新一代分布式关系型数据库，设计之初就选了业界相对开放和成熟的 MySQL 开源生态作为自己的基础。这样不单可以让 MySQL 生态中的用户零成本的切换到 XDB 中，快速赋予业务分布式数据库所带来的多种能力；同时可以让 MySQL 生态中的各种周边工具和 DBA 等生态的参与者平滑的切换到分布式时代，赋予其支撑分布式数据库的能力。

事实证明 XDB 选择的这条路是正确的。在阿里集团及生态下的子公司内部，XDB 在短短的几个月内、在非常少的人力参与下，迅速的完成了对大量传统 MySQL/AliSQL 集群的换代升级，使得阿里数据库整体进入了分布式时代，整个过程业务几乎零参与。同时 XDB 对 MySQL 生态下的运维系统 / 工具、知识体系也实现了兼容，整个 MySQL 时代的支撑平台，支撑人员都可以平滑的过度到分布式数据库时代，拥有了支撑下一代数据库的能力，这个是非常难得的。

2. 跨 Region/ 全球强同步能力

业界支持分布式强一致的数据库很多，但是其强一致都是有范围的，有些支持 AZ 内强一致，有些支持跨 AZ 强一致，真正能做到跨 Region/ 跨国强一致的却是凤毛麟角。目前业界主流数据库中，只有 Spanner 宣称自己是 Global Distribution，包括 Amazon Aurora 在内的其他主流数据库目前都不支持跨 Region 的强一致。XDB 是真正做到了跨 Region/ 跨国强一致的分布式数据库，并且在业务上得到了验证。今年音视频服务全站迁移 XDB，同时 XDB 支撑了音视频服务国际化等多个国际化项目，实现跨国部署。包括核心交易系统、核心物流系统、核心 IM 系统在内的大量业务集群以跨 Region 强同步模式部署，使得业务拥有了城市级容灾情况下，数据零丢失，服务秒级恢复的能力。核心物流系统、核心 IM 系统在双 11 前夕分别进行了中心 Region 全不可用的容灾演练，XDB 在 15 秒内自动完成跨 Region 的重新激活，数据零丢失，这在整个行业都是先行者。

技术解析：XPaxos——高性能 Paxos 独立库

Paxos 是一种分布式一致性算法，其最基础也是最重要的功能是保证分布式系统中多个节点的数据（日志）的强一致，它是分布式系统的基石。虽然 Paxos 算法被图灵奖获得者 Leslie Lamport 首次提出到现在已经 19 年了，离第一个工业实现（Chubby）也已经 11 年了，但是近几年，顶级会议 / 业内文章中 Paxos 的优化和讨论还是非常的多，而且到目前为止真正工业级的、高性能的、高可扩展的 Paxos 算法库还是非常的少见。

XPaoxs 是阿里独立设计 / 研发的，真正工业级的 Paxos 独立库，其在性能上好于业界对手 1、2 个数量级以上，同时其强大的扩展性和完善的生态系统都是竞品所没有的，XPaxos 为分布式高性能数据库 XDB 奠定了坚实的基础。

XPaxos 从基础架构，到网络模型，再到算法本身都有大量的创新：

基于 SEDA 架构的异步并发调度框架

由于 Paxos 的内部状态复杂，实现高效的单实例多线程的 Paxos 变成一个非常大的挑战。大部分竞品例如 Oracle/MySQL 的 Group Replication 等针对单个 Paxos 对象都是单线程实现。

XPaxos 实现了一整套高效的异步并发调度框架，并基于 SEDA（Staged EventDriven Architecture）思想，对整个 Paxos 协议进行了并发切分和实现，采用了大量无锁设计；由异步并发调度框架进行调度和执行，充分利用多核资源，实现高性能。

基于 Batching  Pipelining 的网络优化

跨 Region/ 跨国场景下对 XPaxos 来说最大的挑战就是如何在高延迟网络下保持高吞吐和相对低延迟，XPaxos 针对高延迟网络做了大量的协议优化尝试和测试，并结合学术界现有的理论成果通过合理的 Batching 和 Pipelining，设计并实现了一整套自适应的针对高延迟高吞吐和低延迟高吞吐网络的通信模式，极大的提升了 XPaxos 的性能。类似的优化大部分还在理论阶段，在同类竞品中还非常的罕见。

Jepsen/TLA+ 的分布式原理 / 实现验证

《Paxos made live》中有过一个说法，证明一个 Paxos 实现是正确的，比实现这个 Paxos 本身会更难。因此我们在设计和实现 XPaxos 的时候，投入了大量的精力在 Paxos 的原理证明了实现验证上。我们用 TLA+ 对 XPaxos 进行建模，验证其理论正确性。我们将 Jepsen 对 XPaxos/XDB 进行适配，同时增加了大量的验证 Case 和注入错误，7X24 小时运行，验证其实现正确性。

3. 强一致下的高性能

业界习惯性的认为，强一致一定会带来性能的下降，开强 MP 的 Oracle，在 SemiSync 的 MySQL，MySQL Group Replication 甚至于跨 Region 部署以后的 Spanner，会面临大幅度的性能下降的问题。今年双 11 XDB 在核心交易系统、核心物流系统等交易核心链路上 100% 切流，经历了多轮全链路压测和双 11 零点业务 32.5 万笔 / 秒，数据库 SQL 上亿次 / 秒的峰值的性能考验，证明了 XDB 完全有能力实现强一致和高性能的鱼熊兼得。

XDB 从 Paxos 协议的实现，到 XPaxos 和 AliSQL 的日志结合，再到 AliSQL 本身的提交逻辑，锁策略都做了大量的优化。保证 XDB 无论是在多机房部署还是多 Region 部署下，都能保证性能和单节点模式（非强一致）下无大幅度劣化。特别是在跨 Region 部署时，和其他分布式数据库相比，优势尤为明显。这也是业务能够接受 XDB 跨 Region 部署的主要原因。

XDB 是 AliSQL 和 XPaxos 的紧密结合而产生的。高性能的 XPaxos 为不单为 XDB 带来了高可用和强一致的能力，同时为 XDB 的在强一致下的高可用奠定了坚实的基础。除此以外，我们在 AliSQL 和 XPaxos 的结合上也做了大量的优化，例如一体化日志设计和异步事务提交。

技术解析：一体化日志设计

XDB 的 Consensus 日志采用了单一事务日志的方案（区别于 MySQL 的 binlog 和 relaylog 两份日志），单一事务日志格式 MySQL binlog 的事务日志格式。这份日志被用于集群节点间数据的同步以及下游应用的消费。

一体化日志设计带来的好处是显而易见的，首先是日志量的减少。MySQL 接收到主库的网络消息后会先本地落一份 relaylog 日志，在消费后再产生一份 binlog 日志。虽然 relaylog 会很快被回收，但是日志的写入量是实实在在的两份。反观 XDB 在统一了日志后，同一个事务在一个实例节点上只需要记录一份日志。其次统一日志能够让日志真正按照产生的先后续做到逻辑和物理上的一致，这对于日志的检索效率来说是大有裨益的。首先是顺序扫描日志的时候可以做到物理 IO 上的顺序性，其次 Paxos 算法的运转对于日志的检索和获取都有较高的要求，如果检索一份日志需要先后扫描两份日志跳转来判断比较，那对于效率来说是非常低下的。

技术解析：异步事务提交

在数据库中，服务端的线程池是非常有效降低线程上下文切换开销，提升系统吞吐的技术。但是在跨城 / 跨国环境下，巨大的网络延迟使得线程池本身会成为一种瓶颈。例如 XDB 集群的节点分布在网络 RTT 达到几十毫秒级别的两个 Region 中，那么在实际的运行中会发现线程池中绝大部份线程都在等待日志跨 Region 同步回包，而客户端的请求就没有足够的线程去处理了，这其实造成了服务器资源的严重浪费。

重新回到非线程池的状态不是一个明智之举，既要低上下文开销又要有高资源利用率。我们采取的解决方案是将事务处理中可能最为费时的等待事务日志回报做成异步化。 这样就把一个完整的事务流程拆成了：处理请求 等待同步 事务提交的三个步骤，三个步骤可以分别由线程池的不同线程来完成。每个步骤 XDB 可以精确控制并发量，例如可以用最少的线程数量来处理事务等待日志同步的工作，用大量的线程来处理事务提交等等。在异步化改造后，只要用户的并发请求量足够多，系统吞吐量上可以有明显的提高。

4. 丰富灵活的部署模式

针对电商双 11 这种，不同时期不同需求的业务模型，XDB 提供了非常丰富并且灵活的部署模式，例如核心交易系统、核心物流系统，在今年双 11 前夕，将部署模式从跨城强同步模式一键切换回同城强同步模式，并动态调整拓扑，在保证机房级强一致的前提下，有效的降低了 RT，提升了吞吐。

集团内外不同的业务对数据库的部署需求各不相同，为了更广泛的支持不同的业务 XDB 支持的部署模式非常的灵活。业务可以根据自己的容灾和业务需求，在不同的部署范围内（同城多机房 / 国内多 Region/ 跨国等）选择任意数量、任意角色的节点进行部署，节点的部署和角色同样可以在线修改以适应业务的不同时期的不同需求，例如双 11。这样说有点抽象，这里举 2 个实际的案例.

案例：同城跨机房模式

上图是一个经典的同城跨机房强同步方案，满足以下需求

机房级容灾数据零丢失，10 秒级容灾切换

相对于主备方案零成本增加（2 数据副本，1 日志副本，日志副本资源需求可忽略）

RPO  1S（通过 XPaxos SDK 持续备份）

当然业务可以在这个模式的基础上做多种扩展，例如增加只读无选举权的 learner 节点；增加有选举权的 follower 节点等来提升容灾等级和读能力。

案例：跨城单元化模式

上图是一个经典的跨城强同步方案，满足以下需求

真正的跨城强一致能力：任意城市整体不可用不影响集群可用性，零数据丢失

高性能：在跨城强同步下依然保持高性能

灵活的切换策略：可分别设置同城节点，跨城节点切换优先级

高伸缩能力：可任意增加 / 删除 / 动态修改任意 Region 的数量和角色

目前核心交易系统、核心物流系统、核心 IM 系统等核心集群均采用类似部署方案保证跨城容灾能力。

更重要的是 XDB 支持动态切换部署模式，例如核心交易系统、核心物流系统等集群在双 11 期间一键动态将跨城模式切换到同城模式，在保持机房级容灾能力的前提下，获得更高的性能；音视频服务通过在海外 Region 动态扩展一个 Leaner 角色的节点实现国际化。

大促模式

扩展读 Region

技术解析：Paxos 框架下的角色定制和动态变更

在分布式数据库中经典的 Paxos 用法是将 Paxos 作为一个整体来解决高可用和强一致问题。然而 Paxos 算法不单单能解决高可用强一致问题。在 XPaxos 中我们对 Paxos 算法进行了扩展，将 Paxos 算法中节点的三个角色（Proposer/Accepter/Learner）进行了剥离和重组，形成了多种不同角色的节点，这些节点组合后，可以形成多种适合不同业务的部署模式，同时 XPaxos 设计了一整套动态 Configure Change 算法支持所有部署模式之间的动态切换，对业务非常友好。

2XDB 的演进

XDB 1.0 是整个 XDB 的计划的一部分，整个 XDB 计划将按照三步进行

XDB 1.0(XCluster): 集成 XPaxos，实现金融级分布式强一致能力、一体化的架构设计以及统一的生态环境。

XDB 2.0: 基于自研高性能低成本存储引擎 XEngine，与分布式存储结合打造的计算与存储分离架构，能独立扩展计算和存储的能力，为业务在不同场景的负载下，提供灵活的伸缩能力。同时得益于全新设计的存储引擎，能够提供其他同类产品难以匹敌的性能。

XDB 3.0: 新一代分布式关系型数据库，同时支持了数据自动分片负载均衡，多点可读可写，跨域强同步，AZ 内快速扩充计算节点的计算存储分离架构，应用了一系列技术：为充分发挥硬件性能的软硬件结合技术以及根据数据冷热特点的分层混合存储技术，无论上是在扩展性和高可用性，还是成本和性能上都做到极致，是 XDB 计划数据库系统演进的最终形态。

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。