异地多活高可用架构设计方案

异地多活在近年越来越多大型互联网公司采用的方案,几乎也是大型应用发展到一定阶段的必然选择,综合比较一下各个互联网公司的方案,会发现有很多共性的东西,也有很多差异化的东西,这是最有意思的地方

什么是异地多活

异地多活一般是指在不同城市建立独立的数据中心,“活”是相对于冷备份而言的,冷备份是备份全量数据,平时不支撑业务需求,只有在主机房出现故障的时候才会切换到备用机房,而多活,是指这些机房在日常的业务中也需要走流量,做业务支撑。冷备份的主要问题是成本高,不跑业务,当主机房出问题的时候,也不一定能成功把业务接管过来。

CAP原则

分布式架构设计无论怎样都绕不开CAP原则,C一致性 A可用性 P分区容错性,分区容错性是必不可少的,没有分区容错性就相当于退化成了单机系统,所以实际上架构设计是在一致性和可用性一个天平上的两端做衡量。为什么强一致性和高可用性是不能同时满足?假如需要满足强一致性,就需要写入一条数据的时候,扩散到分布式系统里面的每一台机器,每一台机器都回复ACK确认后再给客户端确认,这就是强一致性。如果集群任何一台机器故障了,都回滚数据,对客户端返回失败,因此影响了可用性。如果只满足高可用性,任何一台机器写入成功都返回成功,那么有可能中途因为网络抖动或者其他原因造成了数据不同步,部分客户端独到的仍然是旧数据,因此,无法满足强一致性。

异地多活的挑战

  • 延迟 异地多活面临的主要挑战是网络延迟,以北京到上海 1468 公里,即使是光速传输,一个来回也需要接近10ms,在实际测试的过程中,发现上海到北京的网络延迟,一般是 30 ms。
  • 一致性 用户在任何一个机房写入的数据,是否能在任何一个机房读取的时候返回的值是一致性的。

误区

  • 所有业务都要异地多活
    以用户中心为例,注册是没必要做异地多活的,假如用户在A机房注册了,在数据没有向外同步的时候,A机房网络中断,这个时候如果让用户切换到B机房注册,就有可能发生数据不一致,出现两个基本相同的账号,这是不可容忍的。但是相对应的来说,用户登录这种是关键核心业务,就有必要做到异地多活了,用户在A机房登录不了,那就让用户在B机房登录。虽然有极端的情况,用户在A机房修改了密码,但是出现网络中断,B机房的用户仍然保存的是旧密码,但是相对于不可登录来说,这种情况是可容忍的。同时有些业务仍然是无法实现异地多活的,比如涉及到金钱的业务,加入有一个用户有100块,消费了50块,A机房发生异常,数据没有同步出去,这时候用户在B机房登录后发现自己还有100块,可以继续消费,就会对业务造成严重的影响。

  • 必须做到实时一致性
    受限于物理条件,跨地域的网速一定会存在延迟,一般是几十毫秒,如果遇上网络抖动,延迟超过几秒甚至几十秒都有可能。解决方法只能是减少需要同步的数据和只保证数据的最终一致性,有时候用户在A机房修改了一条数据,业务上实际上是能容忍数据的短时间不一致的,即使其他用户在B机房读到的是旧数据,实际上对业务也没有任何影响。

  • 只使用存储系统的同步功能
    大部分场景下,MySQL Redis自带的同步功能已经足以满足需求了,但是在某些极端情况下,可能就不合适了,MySQL的单线程复制可能会产生较大的延迟,Redis可能会有全量复制,所以系统要灵活使用各种解决方案。
  1. 用消息队列把数据广播到各个数据中心
  2. 回源读取,当A机房发现没有这条数据的时候,根据路由规则去B机房去读取该数据
  3. 重新生成数据,A机房登录后生成session数据,这时候A机房挂了,可以把用户切换到B机房,重新生成session数据。
  • 实现100%的高可用
    100%的高可用是无法保证的,硬件的损坏,软件的BUG,光纤传输等太多不可控的因素,而且也要在成本上做一个权衡,尤其是对于强一致性业务,C和A只能取一个平衡,容忍短时间的不可用来保证数据的完全一致性。

饿了么异地多活方案

特点
  1. 业务内聚,单个订单的所有流程保证在一个机房内完成调用,不允许进行跨机房调用。每一个机房称为一个ezone,对服务进行分区,让用户,商户,骑手按照规则聚合到一个ezone内。根据业务特点,饿了么选择了把地理位置作为划分业务的单元,以行政省界用围栏
    把全国分为多个shard。在某个机房出现问题的时候,也可以按照地理位置把用户,商户,骑手打包迁移到别的机房即可。
    456913-20180702113903184-712386610.jpg

  2. 可用性优先,当机房发生故障的时候,优先保证可用,用户可以先下单吃饭,有限时间窗口内的数据不一致可以事后再修复。每个 ezone 都会有全量的业务数据,当一个 ezone 失效后,其他的 ezone 可以接管用户。用户在一个ezone的下单数据,会实时的复制到其他ezone。

  3. 保证数据的正确性,在切换和故障时,检测到某些订单在两个机房不一致,会锁定改订单,避免错误进一步扩散。

通过DRC复制MySQL数据

MySQL的数据量最大,每个机房产生的数据,都通过 DRC 复制到其他 ezone,每个ezone的主键取值空间是ezoneid + 固定步长,所以产生的 id 各不相同,数据复制到一起后不会发生主键冲突。按照分区规则,正常情况下,每个 ezone 只会写入自己的数据,但万一出现异常,2个 ezone 同时更新了同一笔数据,就会产生冲突。DRC 支持基于时间戳的冲突解决方案,当一笔数据在两个机房同时被修改时,最后修改的数据会被保留,老的数据会被覆盖。

通过Global Zone保证强一致性

对于个别一致性要求很高的应用,我们提供了一种强一致的方案(Global Zone),Globa Zone是一种跨机房的读写分离机制,所有的写操作被定向到一个 Master 机房进行,以保证一致性,读操作可以在每个机房的 Slave库执行,也可以 bind 到 Master 机房进行,这一切都基于我们的数据库访问层(DAL)完成,业务基本无感知。

新浪微博异地多活方案

微博使用了基于 MCQ(微博自研的消息队列)的跨机房消息同步方案,并开发出跨机房消息同步组件 WMB(Weibo Message Broker)。
每个机房的缓存是完全独立的,由每个机房的 Processor(专门负责消息处理的程序,类 Storm)根据收到的消息进行缓存更新。由于消息不会重复分发,而且信息完备,所以 MytriggerQ 方案存在的缓存更新脏数据问题就解决了。而当缓存不存在时,会穿透到 MySQL 从库,然后进行回种。可能出现的问题是,缓存穿透,但是 MySQL 从库如果此时出现延迟,这样就会把脏数据种到缓存中。解决方案是做一个延时 10 分钟的消息队列,然后由一个处理程序来根据这个消息做数据的重新载入。一般从库延时时间不超过 10 分钟,而 10 分钟内的脏数据在微博的业务场景下也是可以接受的。
由于微博对数据库不是强依赖,加上数据库双写的维护成本过大,选择的方案是数据库通过主从同步的方式进行。这套方案可能的缺点是如果主从同步慢,并且缓存穿透,这时可能会出现脏数据。这种同步方式已运行了三年,整体上非常稳定,没有发生因为数据同步而导致的服务故障。

阿里异地多活方案

阿里在部署异地多活的时候同样是碰到延时问题,解决方案是访问一次页面的操作都在本机房完成,不做跨机房调用。阿里把业务划分成各种单元,如交易单元,这个单元是完成交易业务,称之为单元化。

服务延时

让操作全部在同一中心内完成,单元化
比如用户进入以后,比如说在淘宝上看商品,浏览商品,搜索、下单、放进购物车等等操作,还包括写数据库,就都是在所进入的那个数据中心中完成的,而不需要跨数据中心

部署:

异地部署的是流量会爆发式增长的,流量很大的那部分。流量小的,用的不多的,不用异地部署。
其他一些功能就会缺失,所以我们在异地部署的并非全站,而是一组业务,这组业务就成为单元
比如:在异地只部署跟买家交易相关的核心业务,确保一个买家在淘宝上浏览商品,一直到买完东西的全过程都可以完成

路由一致性:

买家相关的数据在写的时候,一定是要写在那个单元里。要保障这个用户从进来一直到访问服务,到访问数据库,全链路的路由规则都是完全一致的。如果说某个用户本来应该进A城市的数据中心,但是却因为路由错误,进入了B城市,那看到的数据就是错的了。造成的结果,可能是用户看到的购买列表是空的,这是不能接受的。

延时:

异地部署,我们需要同步卖家的数据、商品的数据。能接受的延时必须要做到一秒内,即在全国的范围内,都必须做到一秒内把数据同步完中心之间骨干网。

数据一致性:

把用户操作封闭在一个单元内完成,最关键的是数据。在某个点,必须确保单行的数据在一个地方写,绝对不能在多个地方写。
为了做到这一点,必须确定数据的维度。淘宝除了用户本身的信息以外,还会看到所有商品的数据、所有卖家的数据,面对的是买家、卖家和商品三个维度。因为异地的是买家的核心链路,所以选择买家这个维度。按买家维度来切分数据。但因为有三个维度的数据,当操作卖家、商品数据时,就无法封闭。

在所有的异地多活项目中,最重要的是保障某个点写进去的数据一定是正确的。这是最大的挑战,也是我们在设计整个方案中的第一原则。业务这一层出故障我们都可以接受,但是不能接受数据故障。

多个单元之间一定会有数据同步。一方面,每个单元都需要卖家的数据、商品的数据;
另一方面,我们的单元不是全量业务,那一定会有业务需要这个单元,比如说买家在这个单元下了一笔定单,而其他业务有可能也是需要这笔数据,否则可能操作不了,所以需要同步该数据。
所以怎样确保每个单元之间的商品、卖家的数据是一致的,然后买家数据中心和单元是一致的,这是非常关键的。

总结

各种方案都是针对不同的业务场景设计的,所以会有一定的不同,但是基本思路都是一致的。通过各种手段避免进行跨机房调用,消除延迟,让用户无感知。必要的时候通过业务的妥协,牺牲一致性来获取更高的可用性和更低的部署复杂程度。细读CAP理论就知道,这个问题是不存在完美的解决方案的,只有尽量贴合业务,逐渐迭代出更合适的方案。

引用:
异地多活设计辣么难?其实是你想多了!
饿了么异地多活技术实现(一)总体介绍
微博“异地多活”部署经验谈
绝对干货:解密阿里巴巴“异地多活”技术
阿里和微博的异地多活方案zt

转载于:https://www.cnblogs.com/jaychan/p/9242325.html

你可能感兴趣的:(数据库,大数据)