为什么主动跨数据复制在 5G 时代非常重要？

01 概述

5G 和 IoT 等新技术的融合给电信行业带来了快速而巨大的变革。这些新技术正在推动数据量、速度和多样性的空前增长。数据的增长导致传统系统发生故障，所以电信公司不得不面临一个艰难的选择：继续尝试“传统系统与现有系统一起使用”，抑或寻找新的事物，并且越快越好，因为世界上没有哪家电信公司的数据会变得越来越慢，与此同时，黑客数量变得越来越多且更具侵略性。

为了更及时地提供最新数据，跨数据中心复制（XDCR）应运而生。这种技术已经存在了数十年，但使用传统技术来运作变得昂贵，且使用 5G 技术来运作也很困难，无法正确执行。传统 RDBMS 上的主动 XDCR 变得很复杂且容易出错。企业也很快意识到，他们要么完全替换其数据库，要么将冒着在永久性技术和经济上处于不利地位的风险。

在本文中，我们将讨论 XDCR 是什么，以及为什么需要 XDCR；什么是主动-主动 XDCR，为什么这么多公司面临这种挑战？最后，VoltDB 如何以一种主动-主动 XDCR 的方式避免冲突，还可以对复杂的流数据进行全面的容错，并进行 10 毫秒以下的智能决策，而同时不会损害数据准确性。

首先，让我们定义我们的术语。

02 什么是 XDCR？

在最基本的级别上，XDCR 仅意味着更改会朝多个方向进行，即，一次在多个地理位置上拥有多个实时数据库集群，以便在更新本地数据库时，更改会自动传播到所有其他副本。您要这样做的主要原因有两个：

1.业务连续性：中断是不可避免的，但不应决定您的命运

不同位置具有多个数据库实时副本的最初动机是，如果地震、火灾或其他事件导致原始副本无法运行，企业可以继续运行。

早期的实现具有数据库的一个主副本和一个或多个远程只读副本，这些副本可能已经完全更新，也可能尚未完全更新。将此副本设为“实时”是一个手动过程，很容易需要 30 分钟。从业务角度来看，这带来了明显的问题。首先，数据丢失的数量可能很大。其次，主管人员对于任何需要复杂的，经过精心排序的手动事件链才能工作的系统，可能会感到不安。当切换只会在最大混乱的时刻发生时，他们会特别紧张。

最终，XDCR 涉及到两个相互连接的可互换数据库，从而避免了整个切换过程。这就是所谓的“主动-主动”架构（更多内容请参见下文）。但是提供数据库行业所谓的“主动-主动解决方案”要比看起来困难得多。

在实践中，使用传统技术进行跨数据中心复制已经有十多年的历史了，但是它很容易将项目成本增加了十倍，同时又带来了足够的运营挑战和“陷阱”，从而使净可靠性成为现实。没有比单个系统更好的了。

2. 5G 和延迟：您的数据需要在您的客户所在的地方

如果您是对延迟要求极其严苛的应用程序的企业，则数据中心与终端用户之间的距离将会变得很重要。

数据以约 124 英里/毫秒的速度通过光缆进行传输。因此，如果您的数据中心位于纽约，而您的客户位于 2,900 英里之外的旧金山，则任何消息往返至少须花费 23 毫秒至 46 毫秒。如果您决定是否必须在 20 毫秒内接通电话，而决策过程本身又需要 10 毫秒，那么数据中心的距离不能超过 5 毫秒（约 600 英里）。

这意味着您将需要备份多个实时的运营数据副本，以便在不同的地理位置运营您的业务。实际上，您可能需要两个以上。

03 什么是主动-主动 XDCR？

关于什么是 XDCR 以及“主动－主动”的含义是什么有很多困惑。如今，许多数据库架构师和管理员可能会交换使用这些术语。这是不太确切的——主动—主动和 XDCR 并不相同，因为“主动-主动”是一种进行 XDCR 的方式。但是，它的确指出了主动-主动架构的普遍性和亟需性。

因此，首先，我们将定义“主动-主动”，并将其与“主动-被动”区分开。主动-被动意味着有多个数据库副本，但是只有一个是可更改的（即，主动的），而其他副本则被告知更改。这看起来很简单，但是将备份数据库设置为“主动”（因原始的“主动”数据库已失败，通常需要人工干预），它却无法分辨出将“主动”数据库刻录到地面的数据中心与拔下网络电缆的人的区别。而我们的目标是降低系统范围的延迟，这对我们的目标毫无帮助。

Active-active 意味着您有两个数据库，这两个数据库都可以实时更新，并且两个数据库都可以相互沟通同步更新。这避免了上面我们讨论过的“何时成为主动”的问题决策，并且现在我们可以解决冲突（更多内容请参见下文）。

主动-主动-主动，这意味着将另一个集群添加到您的部署中。而这种配置比您想象的更常见。如果客户对地理冗余有严格的要求（跨越多个地理位置的数据中心的物理隔离）并且还必须进行主体 OS /硬件升级，那么最简单的方法通常是使用新的设备——在弃用较旧的群集之一之前，可以对其进行测试的配置。这样做的成果是，我们的大多数“主动-主动-主动”集群将在某个时候变成“主动-主动-主动-主动”。

04 为什么主动-主动 XDCR 如此困难？

借助足够的“血液和财富”（即以开发人员时间的形式和附加的第三方软件），我们几乎可以创建任何数据库来支持某种形式的主动-主动 XDCR。这就是为什么如此众多的供应商声称他们可以这样做。因此，问题不是“‘某产品’是否符合支持主动-主动的法律要求？”而是“我能否负担得起以主动-主动模式部署 X 产品相关的人力、技术和财务成本？”。

许多企业在未首先了解如何在不增加运营成本的情况下实现主动-主动 XDCR，或试图主动-主动 XDCR，最终要么放弃，要么为妥协的解决方案而苦恼。

主动-主动 XDCR 的核心问题是冲突的处理。

为了说明冲突可能造成的麻烦，我们假设我们正在谈论预付费移动电话信用，并且在三个位置（位置 A，位置 B 和位置 C）中复制了相同的数据库，每个位置相距数百英里。我们假设系统跟踪大约 5000 万终端用户，每个终端用户拥有 50-100 条各种记录。

在这种情况下，避免冲突几乎是不可能的。最明显的冲突类型是，用户在位置 A 上连接到数据库并花费其最后的信用额度，然后以某种方式连接到位置 B 并再次花费相同的额度，然后此活动的消息到达位置 A。

这听起来似乎不太可能，但是在多个用户共享预付费呼叫方案时常常会发生。如果用户位于流量在位置 A 和位置 B 之间不断切换的边界时，也会发生这种情况。但是，更大的问题不是您有一个单一的冲突，您可以花点时间修复所有问题，然后停止所有冲突。您可能拥有的不止一个冲突，而当您发现这一点时，错误决策的二阶和三阶后果已经在您的整个企业中蔓延开来。

为什么我们不能在两站点之间仅使用“两阶段提交”？“两阶段提交”是一种过去常用于协调多个站点之间的更改的技术。对于每笔交易，其形式为站点之间的漫长对话，并最终双方认可数据项已更改。虽然它可以完成其核心任务，但由于以下原因，对于主动-主动 XDCR 来说并不实用：它无法缩放。我们需要每秒能够完成数千笔交易，而两阶段提交根本无法扩展到该级别。它假设所有事情一直在起作用。在两阶段提交体系里，我们假设所有站点始终处于打开状态并且彼此可见。这意味着在站点中断或网络问题的情况下，整个系统都将停止。

05 如何使主动-主动 XDCR 更加轻松

处理冲突的难易程度取决于您使用的数据库，但是企业可以做很多事情来避免冲突。鉴于我们无法“设计出”冲突，因此我们需要考虑减少冲突发生的频率，并在发生冲突时有效地进行处理。

您可以按照以下方法进行操作：

1.使用快速传播

您在站点之间传播与更新的速度有多快，与您将遇到多少冲突之间，存在反比关系。如果花费 5 秒钟而不是 500 毫秒，那么发生冲突的窗口将增加 10 倍，并且您的冲突计数也会相应增加。

XDCR 的传统实现通常建立在最初设计用于填充数据仓库的更改数据捕获 （CDC） 应用程序之上。因此，它们可能是基于批处理的，但是速度会很慢。它们在设计时还考虑了单向复制，这在尝试双向或多方向时会导致问题。

2.最小化配置和自动化

传统数据中心复制产品的其他负面后果通常是数据库与 CDC 产品的差强结合。其一是基础配置的复杂性：数据库对象及其复制方式在 DDL 级别完全脱钩，这具有显著的复杂性。

且在出现问题时，也普遍缺乏自动恢复功能。即使在理想条件下，无论使用什么技术，XDCR 都对人们的操作构成挑战。客户在 XDCR 上的操作经验向我们表明，即使自动化程度高且配置简单，最可能造成停机的原因还是人为错误。

3.程序冲突地址

鉴于冲突是不可避免的，我们需要解决它们在现实系统中造成的后果。这必须以自动化的方式完成，因为尽管每小时平均冲突数量很少，但网络中断可能导致大量冲突，从而压倒人类决策者。

这意味着对冲突消息采用标准格式，适用于自动分析和处理。这只是第一步，因为冲突将在部署中的每个站点的不同时间发生。我们还需要一种存储冲突的机制。

4.迅速解决冲突，避免造成负面影响

尽管大多数产品使用“最后写赢”的某种形式来决定数据的最终外观，但我们仍然必须处理冲突发生后但在意识到之前做出的决策的下游后果。实际上，这意味着如果没有解决冲突的程序机制，在终端用户注意到这些不可避免的问题之前，您将无法解决不可避免的问题。如果你迅速解决冲突，你将能够尽量减少不准确决策的二阶和三阶效应，否则会导致混乱。

5.严苛适应

一旦我们承认冲突是不可避免的，我们需要自动解决冲突，另一个要求突然变得显而易见：我们观察和试图解决的任何冲突都必须是完整和彻底的。找出大约一半的冲突是没有用的，因为我们将无法解决冲突造成的任何潜在的业务问题。因此，我们需要一个符合严苛要求的机制来报告冲突，您可以可靠地假设，一旦您被告知冲突，您就知道这一切，而不仅仅是其中的一部分 。

6.支持自动恢复

任何花时间处理分布在局域网或地理上的数据库的人都会告诉您，当您正在说话的节点消亡时切换到可行的替换节点可能会有问题，但真正的挑战是让节点重新加入群集或在组件负载不足时向集群添加新的节点，而不会导致"失效"或完全中断。

对于许多较老的产品，重新加入过程的外观、感觉和行为都像事后诸葛亮。但是，如果节点在无计划停机和随之而来的剧情下无法重新加入，那么您将发现自己身处一个仅需保持系统正常运行就会耗费数十甚至数百小时的世界。

06 VOLTDB 如何进行主动-主动 XDCR

除了针对大量事务性工作负载进行了优化之外，鉴于多种原因，VoltDB 还是应用主动-主动 XDCR 的理想平台。

尽管 VoltDB 已经启用了被动数据库复制功能，用以在主群集和副本群集之间提供并行二进制复制，但是 VoltDB 的 Version 6 发行版引入了 XDCR 和主动-主动数据库复制，也可以称为主动-主动复制。XDCR 支持跨两个数据库集群的双向主动复制。借助此功能，VoltDB 提供了在两个不同位置维护独立且已同步的可写数据库的功能。

VoltDB 将传入的请求路由到确定性队列中，这些确定性队列统称为“命令日志”，每个队列都由称为分区的单线程处理引擎使用。在每个服务器上，分区和 CPU 内核之间通常存在 1：1 的关系，因此每个内核都忙于快速处理一次事务。

在处理交易时，它们对数据库所做的二进制更改将写到所谓的“ Binlog”中。Binlog 与传统 RDBMS 中的“重做日志”不同，后者仅限于描述对行的更改。相反，它包含在冲突发生时我们需要解决的元数据：

Binlog 的一个关键方面是它具有 ACID 严苛语义：如果我更新两行，则 Binlog 要么包含两个更改，要么不包含任何更改。正如我们稍后将讨论的那样，我们认为这是任何 XDCR 系统的关键要求。

编写 Binlog 时，它会流式传输到所需的目标位置。每个分区使用一个流，这意味着我们可以扩展。如果站点之间的链接断开，更改将被缓冲直到返回。

到达目的地后，它将处理多个 Binlog 流，并将它们所包含的更改应用于本地表（前提是它们不会引起冲突）。我们可以检测到冲突，因为在 XDCR 模式下，我们为每一行存储了最后修改的时间戳，因此可以查看是否存在。

VoltDB 在发生冲突时会做两件事：

• 它会使用更改的时间戳并通过比较所涉及群集的数字 ID（如果时间戳相同）来自动解析它们。

• 它向事件流报告它们的存在，该事件流通常与 Kafka 连接。这意味着您可以编写代码来解决冲突事件，并弄清楚如何在发生冲突的几秒钟内减轻后果。

以上两者都需要提供可信且可管理的主动-主动 XDCR 解决方案。VoltDB 不仅满足主动-主动 XDCR 的必要要求，而且我们通过提供所有使主动-主动 XDCR 运转良好的上述所有内容，使其既可靠又具有成本效益，包括：

1.最小配置的自动化

与其他数据库技术产品和服务不同，VoltDB 的“杠杆”最少。主动-主动 XDCR 是 VoltDB 的集成功能。一旦我们的主动-主动 XDCR 启动并运行，它通常会保持这种状态。

2.始终如一的高性能

一般来说，更改在大约 400 毫秒内传播，外加网络时间。这 400 毫秒大致平分在确保更改记录在源环境中的本地磁盘上、拆开目的地的流以及将更改应用于目标环境之间。

3.自动恢复

如果单个 VoltDB 群集中的节点出现故障，则重新加入时会自动重新同步。或者，可以手动添加新的替换节点。VoltDB 将继续为客户请求提供服务，而这种情况正在进行中。重新同步节点将从幸存的节点获取所需的数据，并将重新加入，而不会对延迟产生重大影响使用主动-主动 XDCR 时，恢复连接后，群集会自动重新同步。

4.支持程序解决冲突

如上所述，VoltDB 在处理来自其他站点的更改流时会自动识别相互冲突的事务。冲突将被 JSON 化，并出现在每个站点的导出流中，使其适合快速自动化处理。

5.严苛合规

主动-主动 XDCR 系统 ACID 严苛合规性的关键功能。如果开发人员不知道他们看到的是完全冲突的交易还是部分冲突的交易，则解决程序化冲突几乎变得不可能。

07 实施主动-主动 XDCR 的真实应用案例

1.XDCR 用于电信计费

电信服务提供商利用 XDCR 可近乎实时地管理帐户余额。例如，欧洲的移动运营商运行一个应用程序，该应用程序每次用户拨打电话时都会检查用户的帐户余额。根据用户所在的位置，请求将被路由到最近的数据中心，在该中心执行余额检查并迅速返回响应。XDCR 负责将更改复制到远程数据库以进行异步备份。帐户余额检查必须在 200 毫秒内完成，因此实施所需的等待时间极短。这些均可通过依靠 VoltDB 得以实现。

2.XDCR 用于金融服务组织

金融服务公司也转向 XDCR，以确保事务一致性和低延迟。例如，银行可以在东海岸和西海岸数据中心之间实施 XDCR，以支持信用卡交易。如果加利福尼亚的用户需要获得信用卡交易的批准，并且那一刻到洛杉矶数据中心的流量很高，那么银行可以通过自动将交易重新路由到其纽约数据中心来避免延迟或不必要的交易下降。同样，交易中心可以实施 XDCR 以确保在数据中心流量过大时在正确的时间输入订单。

VoltDB 是唯一为大规模主动-主动 XDCR 构建，而不会增加成本或损害数据准确性的数据平台。您看好 VoltDB 吗？ 马上行动吧！欢迎私信，与更多小伙伴一起探讨。

关于 VoltDBVoltDB 支持强 ACID 和实时智能决策的应用程序，以实现互联世界。没有其它数据库产品可以像 VoltDB 这样，可以同时需要低延时、大规模、高并发数和准确性相结合的应用程序加油。VoltDB 由 2014 年图灵奖获得者 Mike Stonebraker 博士创建，他对关系数据库进行了重新设计，以应对当今不断增长的实时操作和机器学习挑战。Stonebraker 博士对数据库技术研究已有 40 多年，在快速数据，流数据和内存数据库方面带来了众多创新理念。在 VoltDB 的研发过程中，他意识到了利用内存事务数据库技术挖掘流数据的全部潜力，不但可以满足处理数据的延迟和并发需求，还能提供实时分析和决策。VoltDB 是业界可信赖的名称，在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等领先组织合作有实际场景落地案例。