共计 6337 个字符，预计需要花费 16 分钟才能阅读完成。
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 吗？马上口头吧！
欢送私信，与更多小伙伴一起探讨。
对于 VoltDB
VoltDB 反对强 ACID 和实时智能决策的应用程序，以实现互联世界。没有其它数据库产品能够像 VoltDB 这样，能够同时须要低延时、大规模、高并发数和准确性相结合的应用程序加油。
VoltDB 由 2014 年图灵奖获得者 Mike Stonebraker 博士创立，他对关系数据库进行了从新设计，以应答当今一直增长的实时操作和机器学习挑战。Stonebraker 博士对数据库技术钻研已有 40 多年，在疾速数据，流数据和内存数据库方面带来了泛滥翻新理念。
在 VoltDB 的研发过程中，他意识到了利用内存事务数据库技术开掘流数据的全副后劲，岂但能够满足解决数据的提早和并发需要，还能提供实时剖析和决策。VoltDB 是业界可信赖的名称，在诺基亚、金融时报、三菱电机、HPE、巴克莱、华为等当先组织单干有理论场景落地案例。
