多中心容灾实践:如何实现真正的异地多活?

简介: 在异地多活的实现上,数据能够在三个及以上中心间进行双向同步,才是解决真正异地多活的核心技术所在。本文基于三中心且跨海外的场景,分享一种多中心容灾架构及实现方式,介绍几种分布式ID生成算法,以及在数据同步上最终一致性的实现过程。

image.png

一 背景

为什么称之为真正的异地多活?异地多活已经不是什么新鲜词,但似乎一直都没有实现真正意义上的异地多活。一般有两种形式:一种是应用部署在同城两地或多地,数据库一写多读(主要是为了保证数据一致性),当主写库挂掉,再切换到备库上;另一种是单元化服务,各个单元的数据并不是全量数据,一个单元挂掉,并不能切换到其他单元。目前还能看到双中心的形式,两个中心都是全量数据,但双跟多还是有很大差距的,这里其实主要受限于数据同步能力,数据能够在3个及以上中心间进行双向同步,才是解决真正异地多活的核心技术所在。

提到数据同步,这里不得不提一下DTS(Data Transmission Service),最初阿里的DTS并没有双向同步的能力,后来有了云上版本后,也只限于两个数据库之间的双向同步,做不到A<->B<->C这种形式,所以我们自研了数据同步组件,虽然不想重复造轮子,但也是没办法,后面会介绍一些实现细节。

再谈谈为什么要做多中心容灾,以我所在的CDN&视频云团队为例,首先是海外业务的需要,为了能够让海外用户就近访问我们的服务,我们需要提供一个海外中心。但大多数业务还都是以国内为主的,所以国内要建双中心,防止核心库挂掉整个管控就都挂掉了。同时海外的环境比较复杂,一旦海外中心挂掉了,还可以用国内中心顶上。国内的双中心还有个非常大的好处是可以通过一些路由策略,分散单中心系统的压力。这种三个中心且跨海外的场景,应该是目前异地多活最难实现的了。

二 系统CAP

面对这种全球性跨地域的分布式系统,我们不得不谈到CAP理论,为了能够多中心全量数据提供服务,Partition tolerance(分区容错性)是必须要解决的,但是根据CAP的理论,Consistency(一致性)和Availability(可用性)就只能满足一个。对于线上应用,可用性自不用说了,那面对这样一个问题,最终一致性是最好的选择。

image.png

三 设计原则

1 数据分区

选择一个数据维度来做数据切片,进而实现业务可以分开部署在不同的数据中心。主键需要设计成分布式ID形式,这样当进行数据同步时,不会造成主键冲突。

下面介绍几个分布式ID生成算法。

SnowFlake算法

1)算法说明

+--------------------------------------------------------------------------+
| 1 Bit Unused | 41 Bit Timestamp |  10 Bit NodeId  |   12 Bit Sequence Id |
+--------------------------------------------------------------------------+
  • 最高位是符号位,始终为0,不可用。
  • 41位的时间序列,精确到毫秒级,41位的长度可以使用69年。时间位还有一个很重要的作用是可以根据时间进行排序。
  • 10位的机器标识,10位的长度最多支持部署1024个节点。
  • 12位的计数序列号,序列号即一系列的自增ID,可以支持同一节点同一毫秒生成多个ID序号,12位的计数序列号支持每个节点每毫秒产生4096个ID序号。

2)算法总结

优点:

  • 完全是一个无状态机,无网络调用,高效可靠。

缺点:

  • 依赖机器时钟,如果时钟错误比如时钟回拨,可能会产生重复Id。
  • 容量存在局限性,41位的长度可以使用69年,一般够用。
  • 并发局限性,每毫秒单机最大产生4096个Id。
  • 只适用于int64类型的Id分配,int32位Id无法使用。

3)适用场景

一般的非Web应用程序的int64类型的Id都可以使用。

为什么说非Web应用,Web应用为什么不可以用呢,因为JavaScript支持的最大整型就是53位,超过这个位数,JavaScript将丢失精度。

RainDrop算法

1)算法说明

为了解决JavaScript丢失精度问题,由Snowflake算法改造而来的53位的分布式Id生成算法。

+--------------------------------------------------------------------------+
| 11 Bit Unused | 32 Bit Timestamp |  7 Bit NodeId  |   14 Bit Sequence Id |
+--------------------------------------------------------------------------+
  • 最高11位是符号位,始终为0,不可用,解决JavaScript的精度丢失。
  • 32位的时间序列,精确到秒级,32位的长度可以使用136年。
  • 7位的机器标识,7位的长度最多支持部署128个节点。
  • 14位的计数序列号,序列号即一系列的自增Id,可以支持同一节点同一秒生成多个Id,14位的计数序列号支持每个节点每秒单机产生16384个Id。

2)算法总结

优点:

  • 完全是一个无状态机,无网络调用,高效可靠。

缺点:

  • 依赖机器时钟,如果时钟错误比如时钟不同步、时钟回拨,会产生重复Id。
  • 容量存在局限性,32位的长度可以使用136年,一般够用。
  • 并发局限性,低于snowflake。
  • 只适用于int64类型的Id分配,int32位Id无法使用。

3)适用场景

一般的Web应用程序的int64类型的Id都基本够用。

分区独立分配算法

1)算法说明

通过将Id分段分配给不同单元独立管理。同一个单元的不同机器再通过共享redis进行单元内的集中分配。

相当于每个单元预先分配了一批Id,然后再由各个单元内进行集中式分配。

比如int32的范围从-2147483648到2147483647,Id使用范围1,2100000000),前两位表示region,则每个region支持100000000(一亿)个资源,即Id组成格式可以表示为[0-20。

即int32位可以支持20个单元,每个单元支持一亿个Id。

image.png

2)算法总结

优点:

  • 区域之间无状态,无网络调用,具备可靠唯一性

缺点:

  • 分区容量存在局限性,需要预先评估业务容量。
  • 从Id中无法判断生成的先后顺序。

3)适用场景

适用于int32类型的Id分配,单个区域内容量上限可评估的业务使用。

集中式分配算法

1)算法说明

集中式可以是Redis,也可以是ZooKeeper,也可以利用数据库的自增Id集中分配。

2)算法总结

优点:

  • 全局递增
  • 可靠的唯一性Id
  • 无容量和并发量限制

缺点:

  • 增加了系统复杂性,需要强依赖中心服务。

3)适用场景

具备可靠的中心服务的场景可以选用,其他int32类型无法使用分区独立分配的业务场景。

总结

每一种分配算法都有各自的适用场景,需要根据业务需求选择合适的分配算法。主要需要考虑几个因素:

  • Id类型是int64还是int32。
  • 业务容量以及并发量需求。
  • 是否需要与JavaScript交互。

2 中心封闭

尽量让调用发生在本中心,尽量避免跨数据中心的调用,一方面为了用户体验,本地调用RT更短,另一方面防止同一个数据在两个中心同时写入造成数据冲突覆盖。一般可以选择一种或多种路由方式,如ADNS根据地域路由,通过Tengine根据用户属性路由,或者通过sidecar方式进行路由,具体实现方式这里就不展开说了。

3 最终一致性

前面两种其实就是为了最终一致性做铺垫,因为数据同步是牺牲了一部分实时的性能,所以我们需要做数据分区,做中心封闭,这样才能保证用户请求的及时响应和数据的实时准确性。

前面提到了由于DTS支持的并不是很完善,所以我基于DRC(一个阿里内部数据订阅组件,类似canal)自己实现了数据同步的能力,下面介绍一下实现一致性的过程,中间也走了一些弯路。

顺序接收DRC消息

为了保证对于DRC消息顺序的接收,首先想到的是采用单机消费的方式,而单机带来的问题是数据传输效率慢。针对这个问题,涉及到并发的能力。大家可能会想到基于表级别的并发,但是如果单表数据变更大,同样有性能瓶颈。这里我们实现了主键级别的并发能力,也就是说在同一主键上,我们严格保序,不同主键之间可以并发同步,将并发能力又提高了N个数量级。

同时单机消费的第二个问题就是单点。所以我们要实现Failover。这里我们采用Raft协议进行多机选主以及对主的请求。当单机挂掉之后,其余的机器会自动选出新的Leader执行同步任务。

消息跨单元传输

为了很好的支持跨单元数据同步,我们采用了MNS(阿里云消息服务),MNS本身是个分布式的组件,无法满足消息的顺序性。起初为了保证强一致性,我采用消息染色与还原的方式,具体实现见下图:

image.png

通过实践我们发现,这种客户端排序并不可靠,我们的系统不可能无限去等待一个消息的,这里涉及到最终一致性的问题,在第3点中继续探讨。其实对于顺序消息,RocketMQ是有顺序消息的,但是RocketMQ目前还没有实现跨单元的能力,而单纯的就数据同步而言,我们只要保证最终一致性就可以了,没有必要为了保证强一致性而牺牲性能。同时MNS消息如果没有消费成功,消息是不会丢掉的,只有我们去显示的删除消息,消息才会丢,所以最终这个消息一定会到来。

最终一致性

既然MNS无法保证强顺序,而我们做的是数据同步,只要能够保证最终一致性就可以了。2012年CAP理论提出者Eric Brewer撰文回顾CAP时也提到,C和A并不是完全互斥,建议大家使用CRDT来保障一致性。CRDT(Conflict-Free Replicated Data Type)是各种基础数据结构最终一致算法的理论总结,能根据一定的规则自动合并,解决冲突,达到强最终一致的效果。通过查阅相关资料,我们了解到CRDT要求我们在数据同步的时候要满足交换律、结合律和幂等律。如果操作本身满足以上三律,merge操作仅需要对update操作进行回放即可,这种形式称为op-based CRDT,如果操作本身不满足,而通过附带额外元信息能够让操作满足以上三律,这种形式称为state-based CRDT。

通过DRC的拆解,数据库操作有三种:insert、update、delete,这三种操作不管哪两种操作都是不能满足交换律的,会产生冲突,所以我们在并发级别(主键)加上额外信息,这里我们采用序号,也就是2中提到的染色的过程,这个过程是保留的。而主键之间是并发的,没有顺序而言。当接收消息的时候我们并不保证强顺序,采用LWW(Last Write Wins)的方式,也就是说我们执行当前的SQL而放弃前面的SQL,这样我们就不用考虑交换的问题。同时我们会根据消息的唯一性(实例+单元+数据库+MD5(SQL))对每个消息做幂等,保证每个SQL都不会重复执行。而对于结合律,我们需要对每个操作单独分析。

1)insert

insert是不满足结合律的,可能会有主键冲突,我们把insert语句变更insert ignore,而收到insert操作说明之前并不存在这样一条记录,或者前面有delete操作。而delete操作可能还没有到。这时insert ignore操作返回结果是0,但这次的insert数据可能跟已有的记录内容并不一致,所以这里我们将这个insert操作转换为update 操作再执行一次。

2)update

update操作天然满足结合律。但是这里又要考虑一种特殊情况,那就是执行结果为0。这说明此语句之前一定存在一个insert语句,但这个语句我们还没有收到。这时我们需要利用这条语句中的数据将update语句转成insert再重新执行一次。

3)delete

delete也是天然满足结合律的,而无论之前都有什么操作,只要执行就好了。

在insert和update操作里面,都有一个转换的过程,而这里有个前提,那就是从DRC拿到的变更数据每一条都是全字段的。可能有人会说这里的转换可以用replace into替换,为什么没有使用replace into呢,首先由于顺序错乱的情况毕竟是少数,而且我们并不单纯复制数据,同时也是在复制操作,而对于DRC来说,replace into操作会被解析为update或insert。这样无法保证消息唯一性,也无法做到防循环广播,所以并不推荐。我们看看下面的流程图也许会更清晰些:

 

image.png

 

四 容灾架构

根据上面的介绍,我们来看下多中心容灾架构的形态,这里用了两级调度来保证中心封闭,同时利用自研的同步组件进行多中心双向同步。我们还可以制定一些快恢策略,例如快速摘掉一个中心。同时还有一些细节需要考虑,例如在摘掉一个中心的过程中,在摘掉的中心数据还没有同步到其他中心的过程中,应该禁掉写操作,防止短时间出现双写的情况,由于我们同步的时间都是毫秒级的,所以影响很小。

image.png

五 结束语

架构需要不断的演进,到底哪种更适合你还需要具体来看,上述的多中心架构及实现方式欢迎大家来讨论。

我们的数据同步组件hera-dts已在BU内部进行使用,数据同步的逻辑还是比较复杂的,尤其是实现双向同步,其中涉及到断点续传、Failover、防丢数据、防消息重发、双向同步中防循环复制等非常多的细节问题。我们的同步组件也是经历了一段时间的优化才达到稳定的版本。

作者:开发者小助手_LS

原文链接

本文为阿里云原创内容,未经允许不得转载

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/514274.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

HBM3内存子系统传输速率惊人,带宽突破1TB/S!

记者 | 邓晓娟 8月25日&#xff0c;内存IP厂商Rambus推出HBM3内存接口子系统。内含完全集成的PHY和数字控制器&#xff0c;传输速率达8.4Gbps&#xff1b;可为AI/ML和高性能计算&#xff08;HPC&#xff09;等应用和解决方案提供1TB/s的带宽速率&#xff1b;采用标准的16通道设…

android 如何读取cgi_Python基础教程(十):CGI编程、MySQL数据库

Python CGI编程什么是CGICGI 目前由NCSA维护&#xff0c;NCSA定义CGI如下&#xff1a;CGI(Common Gateway Interface),通用网关接口,它是一段程序,运行在服务器上如&#xff1a;HTTP服务器&#xff0c;提供同客户端HTML页面的接口。网页浏览为了更好的了解CGI是如何工作的&…

10亿+文件数压测,阿里云JindoFS轻松应对

简介&#xff1a; Apache Hadoop FileSystem (HDFS) 是被广为使用的大数据存储方案&#xff0c;其核心元数据服务 NameNode 将全部元数据存放在内存中&#xff0c;因此所能承载的元数据规模受限于内存&#xff0c;单个实例所能支撑的文件个数大约 4亿。JindoFS块模式是阿里云基…

一文简单弄懂tensorflow_在tensorflow中设置梯度衰减

我是从keras入门深度学习的&#xff0c;第一个用的demo是keras实现的yolov3&#xff0c;代码很好懂&#xff08;其实也不是很好懂&#xff0c;第一次也搞了很久才弄懂&#xff09; 然后是做的车牌识别&#xff0c;用了tiny-yolo来检测车牌位置&#xff0c;当时训练有4w张图片&a…

打破“单点防护”缺陷,山石网科发布“云网端”XDR解决方案

编辑 | 宋 慧 供稿 | 山石网科 出品 | CSDN云计算 近年来&#xff0c;CISO面临的安全形势可谓“内忧外患”&#xff0c;对内面临多样化的网络接入途径、庞大且繁杂的IT资产&#xff1b;对外面临攻防关系、攻防手段、网络攻击的数量等呈指数级增长等问题&#xff0c;给组织的…

Serverless 场景下 Pod 创建效率优化

简介&#xff1a; 众所周知&#xff0c;Kubernetes 是云原生领域的基石&#xff0c;作为容器编排的基础设施&#xff0c;被广泛应用在 Serverless 领域。弹性能力是 Serverless 领域的核心竞争力&#xff0c;本次分享将重点介绍基于 Kubernetes 的 Serverless 服务中&#xff0…

安装wordcloud_COVID19数据分析实战:WordCloud 词云分析

↑↑点击上方蓝字&#xff0c;回复资料&#xff0c;N个G的惊喜前言上一篇文章(链接)我们对COVID19_line_list数据集进行了清洗以及初步分析。本文中我们将分析如何用词云来展示文本信息的概要。比如我们从词云百度百科截取文字&#xff0c;制作词云。简单来说&#xff0c;词云就…

到达率99.9%:闲鱼消息在高速上换引擎(集大成)

简介&#xff1a; 记录这一年闲鱼消息的优化之路 1. 背景 在2020年年初的时候接手了闲鱼的消息&#xff0c;当时的消息存在各种问题&#xff0c;网上的舆情也是接连不断&#xff1a;“闲鱼消息经常丢失”、“消息用户头像乱了”、“订单状态不对”&#xff08;相信现在看文章的…

1小时打造HaaS版小小蛮驴智能车

1、认识一下小小蛮驴真面目 1.1、组件部分 HaaS100核心板 HaaS100是一款物联网场景中的标准硬件&#xff0c;并配套嵌入到硬件中的软件驱动及功能模块&#xff0c;为用户提供物联网设备高效开发服务。 HaaS100核心板有着丰富的外设接口&#xff0c;如下所示&#xff1a; 智…

Spring Boot Admin 集成诊断利器 Arthas 实践

简介&#xff1a; Arthas 是 Alibaba 开源的 Java 诊断工具&#xff0c;具有实时查看系统的运行状况&#xff1b;查看函数调用参数、返回值和异常&#xff1b;在线热更新代码&#xff1b;秒解决类冲突问题&#xff1b;定位类加载路径&#xff1b;生成热点&#xff1b;通过网页诊…

设计方案,拿来吧你!

作者&#xff1a;零一来源&#xff1a;前端印象前言大家好&#xff0c;我是零一&#xff0c;今天要跟大家聊聊开发流程中不起眼的环节——设计方案。你们可能没听过&#xff0c;也可能只是简单得走过过场&#xff0c;别划走&#xff0c;这非常重要&#xff01;在字节&#xff0…

借力阿里云存储产品 延锋彼欧加速数字化重塑

简介&#xff1a; 延锋彼欧作为汽车外饰件生产的领航企业&#xff0c;通过基于业务和数据驱动的数字化管理&#xff0c;释放工业设备数据潜能提升产能。依托阿里云“稳定、安全、可靠、易用”的存储服务&#xff0c;延锋彼欧的发展步伐将更为稳健。 “一日骋千里&#xff0c;无…

英雄帖!移动云首批最有价值专家(MVP)招募开始了!

这是开发者的时代&#xff0c;这是价值重塑的时代。站在科技的潮头&#xff0c;我们期待去引领、去挖掘、去创造……移动云已迎来飞速发展的黄金期&#xff0c;移动云开发者社区将成为业界优秀开发者的聚集地。今天&#xff0c;移动云开发者社区正式开启移动云MVP首批招募&…

无责任畅想:云原生中间件的下一站

简介&#xff1a; 本文源自 2020 年 12 月 20 日作者在云原生社区 meetup 第二期北京站演讲 《Apache Dubbo-go 在云原生时代的实践与探索》的部分内容 自从以 2013 年开源的 docker 为代表的的容器技术和以 2014 年开源的 K8s 为代表的容器编排技术登上舞台之后&#xff0c;相…

深度剖析:Redis 分布式锁到底安全吗?看完这篇文章彻底懂了!

作者 | Kaito 来源 | 水滴与银弹阅读本文大约需要 20 分钟。大家好&#xff0c;我是 Kaito。这篇文章我想和你聊一聊&#xff0c;关于 Redis 分布式锁的「安全性」问题。Redis 分布式锁的话题&#xff0c;很多文章已经写烂了&#xff0c;我为什么还要写这篇文章呢&#xff1f;因…

Spring Boot 微服务性能下降九成!使用 Arthas 定位根因

简介&#xff1a; 接收到公司业务部门的开发反馈&#xff0c;应用在升级公司内部框架后&#xff0c;UAT&#xff08;预生产&#xff09;环境接口性能压测不达标。 背景 接收到公司业务部门的开发反馈&#xff0c;应用在升级公司内部框架后&#xff0c;UAT&#xff08;预生产&a…

阿里研究员:线下环境为何不稳定?怎么破

简介&#xff1a; 为什么线下环境的不稳定是必然的&#xff1f;我们怎么办&#xff1f;怎么让它尽量稳定一点&#xff1f; 这篇文章想讲两件事&#xff1a; 为什么线下环境[1]的不稳定是必然的&#xff1f;我们怎么办&#xff1f;怎么让它尽量稳定一点&#xff1f; 此外&#…

谁说技术男不浪漫!90后程序员2天做出猫咪情绪识别软件

整理 | 王晓曼出品 | CSDN&#xff08;ID&#xff1a;CSDNnews&#xff09;9月1日&#xff0c;一则关于#程序员2天做出猫咪情绪识别软件#的话题登上微博热搜&#xff0c;参与阅读的人数达到了8218.1万&#xff0c;讨论次数1.3万&#xff0c;引发网友们的热议。高手在民间&#…

闲鱼如何一招保证推荐流稳如泰山

简介&#xff1a; 风雨不动安如山 背景 近几年互联网的快速发展中&#xff0c;互联网业务发展越来越复杂&#xff0c;业务也被拆分得越来越细&#xff0c;阿里内部业务也发生着翻天覆地的变化&#xff0c;从最初的单体应用&#xff0c;到后面的分布式集群&#xff0c;再到最近…

电商直播平台如何借助容器与中间件实现研发效率提升100%?

简介&#xff1a; 经过实际场景验证及用户的综合评估&#xff0c;电商直播平台借助全面的云原生容器化能力和中间件产品能力&#xff0c;大幅提升开发部署运维效率达50%~100%&#xff0c;极大地提升了用户体验&#xff0c;为业务持续发展打下了坚实的基础。 前言 直播带货是近…