5G和物联网等新技术的融合带来了快速而巨大的变革。这些新技术正在推动数据量、速度和多样性的空前增长。数据的增长导致传统系统出现故障,迫使电信公司面临一个艰难的选择:继续尝试“传统系统与现有系统一起使用”,抑或寻找新的事物,并且越快越好,因为世界上没有哪家电信公司的数据会变得越来越慢,与此同时,黑客数量变得越来越多且更具侵略性。
为了能及时提供最新数据,跨数据中心复制(XDCR)应运而生。这种技术已经存在了数十年,但使用传统技术来运作的成本变得昂贵,且使用5G技术来运作也很困难,无法正确执行。传统RDBMS上的主动XDCR变得异常复杂且容易出错。企业很快意识到,要么完全更换数据库,要么冒着在技术和经济上长期处于劣势的风险。
在本文中,我们将讨论5G如何改变企业对延迟和XDCR的需求;什么是主动-主动XDCR,为什么这么多公司面临这种挑战?最后,VoltDB如何以一种主动-主动XDCR的方式避免冲突,还可以对复杂的流数据进行全面的容错,并进行10毫秒以下的智能决策,而同时不会损害数据的准确性。
企业意识到5G不仅仅是4G加一个G,这是一场全新的球赛,具有新的挑战和机遇,其最大的挑战和机遇是延迟。如果企业希望将5G商业化,并将产品扩展到一个要求越来越高、越来越不耐烦的客户群,那么可靠的低延迟(即,使事件在不到半秒的时间内发生,理想情况下不到四分之一秒)已不再可有可无,而是必需属性。
麻省理工学院在2020年技术审查报告“5G与企业机遇”中提到:
仅对服务提供商而言,基于数字化的增长是一大机遇。
利用这一机遇,通过提供上述吞吐量、延迟等功能,特别是在规模上,需要运营商围绕业务模型、架构和技术能力在思维和行为上进行巨大的转变。
对于第二类和第三类——架构和技术,XDCR将发挥重要作用。
如今,电信运营商有两个关键需求:1、通过XDCR,应用程序及其数据需要存在于不同且地理位置相隔遥远的数据中心(为了避免同一灾难性事件同时摧毁一切)。2、需要在个位数毫秒内响应客户请求以满足SLA。
然而,使用位于多个位置的数据始终是一项技术挑战,因为在两个地理位置遥远的数据中心执行数据操作时,很难维持低延迟。传统的关系型数据库管理系统会提供一种主备配置,即所有流量都发送到一个数据中心,而更改会被注入到一个备份数据中心,但这些部署的规模有限,操作复杂性和软件许可成本却几乎无限。
特别是在整个电信网络继续运行的情况下,使“备用”站点“主动”的过程和与其相反的过程是复杂的手动过程,在真实的灾难场景下很难做好。
下面举例说明基本主动/备用XDCR存在问题的原因:
Alice负责旧金山的“主动”数据中心。
Bob负责洛杉矶的“被动”数据中心。
据报道,位于旧金山和洛杉矶之间的加州金城附近发生了地震。
Bob发现他收不到来自洛杉矶的数据更改,因此无法联系Alice。
Bob能做什么?
如果他将站点设为主动状态,而Alice的站点也处于主动状态,他将打破一切阻碍。
如果他等待连接恢复,那么他的数据中心将无法为客户提供服务。
这是Catch-22场景。如果Bob拥有从备用切换到主动所需的可靠信息,则无需进行切换。与此同时,在金城外,一名反铲挖掘机司机试图通过他刚刚发现的意外电缆拨打电话,但一直收到正忙信号。
XDCR是在多个物理位置同时更改相同数据,并让数据存储平台修复更改后发生的任何冲突的过程。在最基本的层面上,XDCR意味着多个方向的更改,即在多个地理位置同时拥有多个实时数据库集群,以便在更新本地数据库时,让更改自动传送到所有其他副本。
“五个9”目标应用于计划外停机,计划内停机是另一回事。虽然应用程序供应商可以在升级过程中投入工程时间来最大限度地减少停机时间,但他们不会影响下面的任何人,因此,操作系统的升级和安全补丁等事件所需的时间与他们所需的时间一样长。硬件更改可能也需要很久时间。
客户假定计划的停机时间是数周。那么,他们需要在三个数据中心安装该系统,因为在不同时间只使用两个数据中心。
虽然覆盖三个数据中心的主动-备用-备用配置是可能的,但它会导致更大的人力和财务成本,并带来新的风险和令人心梗的故障模式。
4.1.2 应用程序实现低延迟需要附近的主动数据中心
大型市场的运营商需要维持几毫秒的行业标准SLA,即使他们的客户共享余额,并且距离他们的本土市场数千英里。
然而5G具有严格的延迟要求,这使得它实际上不可能从内布拉斯加州奥马哈的一个数据中心为美国这样的市场提供服务。因此,如果想满足5毫秒SLA的要求,则需要大量的主动数据中心,而该SLA现在受到光速限制(186英里/毫秒)。
边缘计算以超低延迟为前提,尽管业界对将应用程序放在离用户很近的地方,甚至放在国内DSL路由器内有着很大的市场,但很少有人思考其在国家层面上的运作机理。
可以肯定的一件事是,边缘端设备最终需要与位于三个或更多数据中心的控制应用程序进行通信。
新的数据平台使主动-主动XDCR变得更加容易。但一旦部署了主动-主动系统,就需要解决数据冲突问题。
如果在洛杉矶和旧金山的数据中心独立做出满足SLA要求的决策,那么两个不同的人可能会两次花费相同的最后一美元,从而导致负余额。这就导致了数据冲突。
大多数现代数据平台将此视为数据争用问题,并使用内置功能确保数据在多个位置保持一致。
所以,如果他们能做到这一点,为什么不给你最喜欢的数据库供应商写一张支票,让他们担心呢?要是这么简单就好了。
这并不是说现代数据平台根本不管理冲突,而是他们管理冲突时不考虑任何次要后果。如果航班上的座位被双重预订,航空公司可以通过删除其中一个预订来“修复”问题,但他们仍须处理刚刚取消航班的人。
XDCR系统中的现代数据平台也存在同样的问题。
1、使用无冲突复制数据类型(CRDT)合并数值更改,通常会导致负余额。这种策略只适用于简单的数字事件,并且以静默方式发生,这意味着在用户再次尝试使用设备之前,应用程序不知道负平衡。(如果它知道这样就可以为用户提供完美的时间来购买更多的信用卡,这不是很好吗?)
2、使用基于时间戳的对账来选择赢家,赢家通常是最后一个做出更改的人,而输家的交易便会消失。
无论哪种方法,金钱(很可能也是客户)都会损失。显然,在5G的快速数据时代,需要更好的解决方案来管理数据冲突。
VoltDB的Active(N)将三个主动-主动数据中心XDCR与应用程序级冲突解决方案相结合,使企业级应用程序能够修复不可避免的数据冲突问题,同时仍能提供超可靠的低延迟应用程序,显著提高5G用例的资本化和货币化能力。
要使上述功能成为可能,VoltDB的XDCR/Active(N)实现有许多关键点:
4.6.1 数据更改的快速实现
进行更改所花费的时间与冲突的数量之间存在直接关系。如果数据平台需要5秒而不是半秒,那么发生冲突的窗口将扩大10倍,冲突计数也将相应增加。
VoltDB可以在大约半秒钟加上网络时间内实现数据更改。
4.6.2 数据更改的显著压缩
如果每个数据中心将收到的请求发送到其他所有站点,则系统上的工作负载将以数量级增长。
与原始请求相比,VoltDB将更改压缩约80%,以减少数据中心增加时的数据负载。
Active(N)使用三个(或更多)具有高可用性集群的数据中心,并通过Kubernetes增强数据观测能力,以实现具有应用程序级冲突解决功能的主动XDCR。
4.6.3 快速解决冲突
鉴于冲突不可避免,需要以自动化和可预测的方式解决它们在现实系统中造成的后果。虽然每小时平均冲突数量很少,但网络中断可能导致大量冲突,从而压倒人类决策者。在如何解决冲突的问题上每犹豫一毫秒就会带来更多的冲突,所以时间至关重要。根据定义,冲突可能在多个地方同时发生,所以解决冲突的逻辑也需要完全对称。
VoltDB通过使用基于时间戳的算法来实现对称性,该算法将位置作为分界线,并将这些决策传达给应用程序。
4.6.4 自动恢复
任何花时间处理分布在局域网或地理位置上的数据库的人都会告诉您,当您正在说话的节点消亡时,切换到可行的替换节点可能会有问题,但真正的挑战是让节点重新加入集群,或者在组件负载不足时向集群添加新的节点,而不会导致"失效"或完全中断。对于许多较老的产品,重新连接过程的外观、感觉和行为都像事后诸葛亮。但是,如果节点在无计划停机和随之而来的剧情下无法重新加入,那么您将发现自己身处一个仅保持系统正常运行就会耗费数十甚至数百小时的世界。
VoltDB的实现自动化了单个节点和整个集群的重新连接和恢复。
4.6.5 严苛适应
一旦您接受冲突是不可避免的,并且需要在应用程序级别解决冲突,另一个需求就会突然变得显而易见:需要观察和处理整个冲突。您将发现一半的冲突是没有用的,因为您无法可靠地修复由于冲突而产生的任何潜在业务问题。因此,您需要符合严苛的ACID机制来报告冲突,这种机制可以确保您了解整个冲突,而不仅仅是其中的一部分。
VoltDB将直接涉及冲突的所有行发送到应用程序。
4.6.6 应用程序级冲突解决
主动(N)无损XDCR使用了基于时间戳的协调,也使用了Kafka告诉应用程序如何解决每个冲突。在上例中,Bob的事务将被拒绝,因为它是在Alice的事务之后启动的,但是应用程序将在几秒钟内知道发生了什么,并且可以做出关于怎么办的智能业务决策。在很多情况下,应用程序会忽略情况并继续运行,但如果Bob在交易被Alice“踩”到时增加了100美元的信用额度,该怎么办?在该情况下,应用程序可以重新提交Bob的100美元,从而避免愤怒和潜在的诉讼客户。Bob和公司都省了钱,达到了双赢。
电信服务提供商利用XDCR可近乎实时地管理账户余额。例如,欧洲的移动运营商运行一个应用程序,该应用程序在用户每次拨打电话时都会检查用户的帐户余额。根据用户所在的位置,请求被路由到最近的数据中心,在该中心执行余额检查并快速返回响应。XDCR负责将更改复制到远程数据库以进行异步备份。帐户余额检查必须在200毫秒内完成,因此该实施要求低延迟。
金融服务公司也转向XDCR,以确保事务低延迟和一致性。例如,银行可以在东海岸和西海岸数据中心之间实施XDCR,以支持信用卡交易。如果加利福尼亚州的用户需要获得信用卡交易的批准,并且此时洛杉矶数据中心的流量很高,那么银行可以通过自动将交易重新路由到其纽约数据中心来避免延迟或不必要的交易拒绝。同样,交易中心所可以实施XDCR,以确保在数据中心流量过大时在正确的时间输入订单。
VOLTDB——唯一通过主动(N)无损XDCR为大规模主动-主动 XDCR构建,而不会增加成本或损害数据准确性的数据平台。
VoltDB通过揭示5G数据的价值,使企业级公司能够更快地创新、表现更好,并创造新的收入流。作为唯一为实时、低于10毫秒的决策而构建的数据平台,使公司能够重新设计延迟相关的解决方案,以前所未有的速度处理更多的数据,使得不仅能够在5G、物联网以及任何下一代的系统中生存,而且能够蓬勃发展。
通过将内存中的数据存储与可预测的低延迟和其他关键功能相结合,我们可以为BSS/OSS、客户管理和收入保障应用程序提供驱动,这些应用程序需要在一位数毫秒内运行,以推动收入或防止收入损失,而不会影响数据准确性。

如果您想了解更多
请与我们联系!
VoltDB中国网站:👇
https://www.voltdb-china.cn/
欢迎扫码添加小助手
进入到我们的官方微信交流群
扫描二维码
加入VoltDB交流群
注明公司 实时探讨