专栏首页性能与架构异地多活架构

异地多活架构

异地指地理位置上的不同,多活指不同地理位置上的系统都能够提供业务服务。

判断标准:

  1. 正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务。
  2. 某地异常时,用户访问其他地方正常的业务系统,能够得到正确的业务服务。

异地多活的代价:

  1. 系统复杂度会有质的变化。
  2. 成本大大增加。

架构模式

1. 同城异区

部署在同一个城市不同区的机房,用专用网络连接。

同城异区两个机房距离一般就是几十千米,网络传输速度几乎和同一个机房相同,降低了系统复杂度、成本。

这个模式无法解决极端的灾难情况,例如某个城市的地震、水灾,此方式是用来解决一些常规故障的,例如机房的火灾、停电、空调故障。

2. 跨城异地

部署在不同城市的多个机房,距离要远一些,例如北京和广州。

此模式就是用来处理极端灾难情况的,例如城市的地震、相邻城市的大停电。

跨城异地主要问题就是网络传输延迟,例如北京到广州,正常情况下的RTT(Round-Trip Time 往返时延)是50毫秒,当遇到网络波动等情况,会升到500毫秒甚至1秒,而且会有丢包问题。

物理距离必然导致数据不一致,这就得从“数据”特性来解决,如果是强一致性要求的数据(如存款余额),就无法做异地多活。

举例,存款余额支持跨城异地多活,部署在北京和广州,当光缆被挖断后,会发生:

  • 用户A余额有10000,北京和广州是一致的。
  • A在广州机房给B转5000,广州余额为5000,由于网络不通,北京此时的余额为10000。
  • A在北京发现余额还是10000,给C转10000,由于网络不通,广州的余额为5000。
  • A在广州又可以给D转5000。

这就出事儿了,所以这类数据不会做跨城异地多活,只能用同城异区架构,因为同城的网络环境要好很多,可以搭建多条互联通道,成本也不会太高。

跨城异地模式适用于对数据一致性要求不高的场景,例如:

  1. 用户登录,数据不一致时重新登录即可。
  2. 新闻网站,一天内新闻数据变化较少。
  3. 微博网站,即使丢失一点微博或评论数据也影响不大。

3. 跨国异地

部署在不同国家的多个机房。

此模式的延时就更长了,正常情况也得几秒,无法满足正常的业务访问。

所以,跨国异地多活适用于:

  • 为不同地区用户提供服务

例如,亚马逊美国是为美国用户服务的,亚马逊中国的账号是无法登录美国亚马逊的。

  • 只读类业务

例如谷歌的搜索,不管用户在哪个国家搜索,得到的结果基本相同,对用户来说,跨国异地的几秒延迟,对搜索结果没什么影响。

跨城异地多活设计技巧

1. 保证核心业务的异地多活

思维误区:要保证所有业务都能异地多活。

假设用户子系统,负责注册、登录、用户信息这3个业务,由于有海量用户,所以对用户进行分区,分配到不同数据中心,正常情况下某个用户属于某个主分区,并在其他分区也有备份,通过hash计算得出属于哪个中心。

如果想要保证注册业务多活,可能会有问题,例如,A中心注册了用户,数据还未同步到B中心时A宕了,为了支持多活,需要可以让用户到B中心重新注册,但一个手机号只能注册一个账号,A恢复后就有冲突了。

如果要保证用户信息业务多活,也会有问题,例如,A、B两个中心在异常情况下都修改了用户信息,如何处理冲突?

可以发现,注册、登录、用户信息这3个业务都支持多活的话,是非常难的,有的问题甚至是无解的。解决的方法就是:优先实现核心业务的异地多活

这个示例中,“登录”才是核心业务,例如系统的日活是1000万,每天的注册可能是几万,修改用户信息的可能还不到1万,但登录是1000万,很明显要保证登录的异地多活。

2. 保证核心数据最终一致性

思维误区:要保证所有数据实时同步。

由于物理上的限制,所有数据都实时同步,是一个无法达到的目标。

必须要尽量减少数据同步,只同步核心业务相关的数据。

例如上面的例子,登录产生的token或session信息,数据量很大,实际上不需要同步到其他中心,即使丢失了重新登录就可以了,会影响用户体验,但是可以接受的。

3. 采用多种手段同步数据

思维误区:只使用存储系统的同步功能。

存储系统本身就有强大的同步功能,例如 mysql redis 都可以很好的实现同步,但某些场景下是无法满足需要的,所以要使用多种手段配合,例如:

  • 消息队列

创建账号后,将账号数据通过消息队列同步到其他业务中心。

  • 二次读取

例如用户在A中心注册了,然后访问了B中心,此时B还没有拿到账号数据,为了解决这个问题,B中心在读取本地数据失败时,可以根据路由规则,再去A中心访问一次。

  • 回源读取

例如session数据没有同步,用户在A中心登录,B中心可以拿着 session id 到A中心请求session数据。

4. 只保证绝大部分用户的异地多活

思维误区:要保证业务 100% 可用。

物理规律决定了异地多活无法保证100%的业务可用。

以转账业务为例,在北京和上海两个中心实现了实时转账的异地多活,在异常情况下会出现问题,例如用户有一万存款,在北京给人转了一万,又到上海给人转了一万。

所以,无法做到实时转账的异地多活,需要通过特殊业务受到实现。

例如,除了“实时转账”外,还提供“转账申请”业务,用户在上海提交了转账请求,并不立即转账,而是后台异步处理,如果发现北京中心不可用,就等待重试,北京恢复后,如果发现余额不足就转账失败。

这个方式牺牲了一些用户体验,本来一次完成的操作变为了2次,一次提交转账申请,另一次是确认转账结果。

对于用户体验,可以采取一些补偿措施,例如:

  • 公告

例如由于xxx原因导致您的不便,技术哥哥正在紧急处理等等。

  • 事后补偿

例如送代金券、小礼品等。

  • 补充体验

例如上面的转账例子,可以在转账结果出来后给用户发个短信,减少用户不时的登录查看。

小结

内容整理自《从0开始学架构》

本文分享自微信公众号 - 性能与架构(yogoup),作者:杜亦舒

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-04-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 轻量集群管理工具PSSH

    PSSH 的意思是 Parallel SSH,并行的SSH,很好理解,PSSH 可以让一条命令在多个服务器上同时执行 这就简化了集群的管理工作,例如想查看一下...

    dys
  • 分布式限流

    在单机系统中,限流逻辑直接放在服务接口中即可,Guava RateLimiter 可以方便的实现。

    dys
  • 微信朋友圈的技术思路

    本文根据微信朋友圈负责人陈明在2015年ArchSummit大会的演讲“微信朋友圈技术之道”整理的,由于声音不清晰,所以整理的不够全面,抱歉 朋友圈每天的发表...

    dys
  • 应用商店优化: 如何提升App的评级?

    译者:Lisa 本文长度为2603字,预估阅读时间6分钟。 摘要:作者从提升App的评级以及用户体验等方面,用于展示应用商店的优化。 App评级是应用商店优化...

    iCDO互联网数据官
  • 调研现场

    上两篇文章中写到为什么要做用户调研以及用户调研的流程,今天来说下调研现场应该怎么做。

    靠谱先生
  • 干货!产品经理职责:如何对产品进行数据分析?

    1、Query 这是一切搜索或者类似产品的质量提升源泉没有之一 //至少我是这么认为的。 看了Query你才能知道用户真的在你这里干什么,于是就会理解了“访谈里...

    CDA数据分析师
  • 2.4.2、Google Analytics高级应用——行为流报告

    GA 里面有一个用户流报告,还有一个行为流报告,如果不去细看,第一感觉会是这两个报告不是一样的吗,长得那么像。下面就要介绍一下用户流报告和行为流报告的异同点:

    GA小站
  • 【扩展阅读】流氓软件你造吗?

    “流氓软件”是介于病毒和正规软件之间的软件,通俗地讲是指在使用电脑上网时,不断跳出的窗口让自己的鼠标无所适从;有时电脑浏览器被莫名修改增加了许多工作条,当用户打...

    腾讯大讲堂
  • App 数据分析到底要分析什么

    DAU、MAU、留存率、频率、时长.....到底产品经理要分析什么数据?笔者结合海外移动端产品的数据分析实践与MTA服务的客户案例,带你从产品初创到成熟不同阶段...

    旺仔小小鹿 .
  • SQL数据分析淘宝用户分析实操

    常见的数据清洗,预处理,数据分类,数据筛选,分类汇总,以及数据透视等操作,用SQL一样可以实现(除了可视化,需要放到Excel里呈现)。SQL不仅可以从数据库中...

    1480

扫码关注云+社区

领取腾讯云代金券