从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

28 | 业务高可用的保障:异地多活架构

应用场景
多活含义不同
跨国机房连接
适用业务类型
数据一致性问题
网络传输延迟
跨城机房连接
复杂度和成本
机房级别故障
同城机房连接
数据一致性要求和业务类型的影响
复杂度、成本和故障发生概率的综合考虑
异地多活的应用场景和架构模式
跨国异地
跨城异地
同城异区
跨国异地
跨城异地
同城异区
总结
架构模式
应用场景
异地多活架构

该思维导图由 AI 生成,仅供参考

无论是高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能所有服务器都出现故障。例如,典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫痪,而且即使有其他地区的备份,把备份业务系统全部恢复到能够正常提供业务,花费的时间也比较长,可能是半小时,也可能是 12 小时。因为备份系统平时不对外提供服务,可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复,那么就需要设计异地多活架构。
今天我来聊聊异地多活架构,接下来还会再讲异地多活架构的设计技巧和流程。

应用场景

顾名思义,异地多活架构的关键点就是异地、多活,其中异地就是指地理位置上不同的地方,类似于“不要把鸡蛋都放在同一篮子里”;多活就是指不同地理位置上的系统都能够提供业务服务,这里的“活”是活动、活跃的意思。判断一个系统是否符合异地多活,需要满足两个标准:
正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务。
某个地方业务异常的时候,用户访问其他地方正常的业务系统,能够得到正确的业务服务。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

异地多活架构是一种旨在提高系统可用性的设计方案,通过在不同地理位置上提供业务服务,以应对灾难性故障。文章介绍了同城异区、跨城异地和跨国异地三种异地多活架构,分析了它们的细节和优缺点。同城异区架构能有效解决机房级别故障,而跨城异地则能更好地应对极端灾难事件,但也带来了网络传输延迟和数据一致性难题。跨国异地多活则适用于为不同地区用户提供服务和只读类业务。总的来说,异地多活架构功能强大,但伴随着复杂的系统设计和高昂的成本,因此在选择是否采用异地多活架构时,需要根据业务特点和需求进行综合考虑。对于规模较大的业务来说,尽量实现异地多活架构是值得考虑的。异地多活架构的应用场景和常见架构模式为读者提供了深入了解,同时也提出了思考题,引发读者对高可用存储架构和自动化运维的思考。文章内容全面,对异地多活架构进行了深入剖析,为读者提供了宝贵的技术知识和思考角度。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(75)

  • 最新
  • 精选
  • 空档滑行
    备份系统平常没有流量,如果直接上线可能触发平常测试不到的故障。 再实时的系统也会有数据延时,如果涉及到金融这种系统,仍然是不敢直接切换的。 系统运行过程中会有很多中间数据,缓存数据等。系统不经过预热直接把流量倒过来,大流量会直接把系统拖垮

    作者回复: 分析全面,赞👍

    2018-06-30
    4
    156
  • Geek_88604f
    首先第一点业务会中断一分钟,这对于微信或支付宝这样的系统来说是不可接受的,特别是像春节这样的关键时刻,万万不可掉链子。         第二点数据不一致,如果在主分区故障前还没有将数据同步到备分区,那么在主分区恢复前数据一直不一致。对于像新闻或微博之类的应用还好说,对于电商或微信等系统就不可接受。         第三点备用分区的可用性,发生故障往往是在业务高峰期,这个时候备份区能否抗住是值得怀疑的。一个从来没有锻炼过的人,突然让他跑马拉松估计扛不住。         最后一点缓存,如果系统中存在缓存,缓存的数据在备分区是没有的,缓存需要预热,一下子切到备出现缓存击穿导致存储扛不住

    作者回复: 分析到位

    2019-09-17
    3
    54
  • 王磊
    文章提到异地多活的代价时,说到复杂的架构,但通篇没有一个架构图,从文字看,也没完全理解架构的细节,例如异地之间如何同步,一地出现问题,如何切换,例如北京的业务系统出问题了,怎么用广州的业务系统来抗过去。

    作者回复: 后面还有两篇

    2018-06-30
    26
  • 微风
    李老师,像文中提到的不同的异地多活架构产生的不同成本,没有直观印象,您能否系统性的给个具体的分析~

    作者回复: 支付宝为了底层支持异地多活,自己写了Oceanbase,Oceanbase写了7~8年了还没有完全代替MySQL😄

    2018-10-06
    21
  • Mr.Null
    现在流行云服务,对于企业做异地多活、灾备会不会很省事?

    作者回复: 不会,云服务一样宕机

    2018-06-30
    2
    13
  • CYH
    请教个问题:文章说支付宝类的金融服务一般采用的是同城异区架构.那假如真的发生了类似奥尔良水灾问题,支付宝如何保证业务正常?要解决这问题的话是多地部署(多地间服务状态不同步),存储高可用?

    作者回复: 支付宝也没法100%保障,不然蓝翔挖掘机就不会导致支付宝故障了

    2018-07-02
    12
  • 大宝
    最近看CIPS(人民币跨境支付系统)的相关信息,官网中有这么一条新闻:   “本次CIPS主备中心切换用时67秒,较上一次切换运行用时缩短了19秒,进一步提高了切换效率及系统连续运行能力。此次切换运行充分验证了CIPS二期全面投产后备份中心系统配置的正确性和可用性。后续,CIPS运营机构将进一步提高业务连续性保障能力,完善系统服务功能,提升用户使用体验。” 结合老师讲的最近几章,推断CIPS是主备系统架构,不是异地多活,使用的是数据分区备份,并且官网之前也提到主系统在上海,备份系统在无锡。 但是我感觉有两个奇怪的地方:一个是:主备在上海和无锡,这两个地方觉得不远也不近,看了下地图约150公里吧,感觉既不是“同城异区”,也算不上“跨城异地”。另一个他作为金融系统使用主备架构,而没有使用异地多活架构,是不是有点业余?

    作者回复: 1. 距离这么近确实有问题,例如台风或者地震,很可能两个机房都受影响 2. 金融系统大部分使用主备架构,不算业余但也算不上先进,金融系统对数据一致性要求很高,异地多活很多业务做不了

    2018-10-22
    2
    9
  • 夜行者
    支付宝跨国异地多活是怎么架构的?用户在国外也能用支付宝呀

    作者回复: 第一我真不知道,第二知道了也不能说😂

    2020-03-18
    2
    6
  • freebird4ever
    文章中支付宝转账的例子不对。支付宝通过分布式事务保证转账交易的原子性。oceanbase保证异地多个节点中大部分节点写成功。未写成功的节点异步恢复。未恢复前不可发生新的交易。

    作者回复: 文中的例子是多地都可以同时写,oceanbase底层基于paxos算法,从业务的角度看起来是多地都可以写,但本质上是通过一致性算法避免同时写,paxos同时写会出现冲突,冲突就要重新发起写操作

    2018-07-11
    6
  • 天使
    “您提到的支付宝同城异区万一主区出现故障。转账的时候正好停留在那1ms没能到达备用区域怎么解决?” 我理解的是:日志+补偿+人工处理肯定是能从业务上解决这个问题的;纯技术角度,区块链是另外的选择,就是不是很了解目前的技术成熟度是否能满足支付宝这么大的体量;还有一个就是未来量子计算机发展到一定程度了,或许就没有“异地多活”了。

    作者回复: 量子计算机会颠覆目前所有的技术,包括高性能,高可用,加解密,人工智能,如果真的出现了,人类估计已经去征服太空了,谁还在地球玩啊😄

    2018-07-07
    6
收起评论
显示
设置
留言
75
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部