前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >架构设计 7-高可用架构设计之异地多活

架构设计 7-高可用架构设计之异地多活

作者头像
aneutron
发布于 2022-08-19 03:29:03
发布于 2022-08-19 03:29:03
7720
举报
文章被收录于专栏:闲余说闲余说

导读:《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第七部分,主要介绍异地多活,异地多活缩短了时延,提高可用性,但是带来复杂度和成本无疑是巨大的,不是一般公司可以承受的,只有在对可用性要求特别高的业务场景才建议使用。

应用场景

两个标准

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

代价很高

  • 系统复杂度会发生质的变化,需要设计复杂的异地多活架构。
  • 成本会上升,毕竟要多在一个或者多个机房搭建独立的一套业务系统。

架构模式

同城异区

  • 结合复杂度、成本、故障发生概率来综合考虑,同城异区是应对机房级别故障的最优架构。
  • 关键在于搭建高速网络将两个机房连接起来,达到近似一个本地机房的效果。架构设计上可以将两个机房当作本地机房来设计,无须额外考虑。

跨城异地

  • 跨城异地距离较远带来的网络传输延迟问题,给异地多活架构设计带来了复杂性,如果要做到真正意义上的多活,业务系统需要考虑部署在不同地点的两个机房,在数据短时间不一致的情况下,还能够正常提供业务。
  • 关键在于数据不一致的情况下,业务不受影响或者影响很小,这从逻辑的角度上来说其实是矛盾的,架构设计的主要目的就是为了解决这个矛盾。
  • 这就引入了一个看似矛盾的地方:数据不一致业务肯定不会正常,但跨城异地肯定会导致数据不一致。
  • 如果是强一致性要求的数据,例如银行存款余额、支付宝余额等,这类数据实际上是无法做到跨城异地多活的。

跨国异地

  • 为不同地区用户提供服务
  • 只读类业务做多活

技巧

  • 保证核心业务的异地多活
  • 保证核心数据最终一致性
    • 尽量减少异地多活机房的距离,搭建高速网络
    • 尽量减少数据同步,只同步核心业务相关的数据
    • 保证最终一致性,不保证实时一致性
  • 采用多种手段同步数据
    • 消息队列方式:对于账号数据,由于账号只会创建,不会修改和删除(假设我们不提供删除功能),我们可以将账号数据通过消息队列同步到其他业务中心。
    • 二次读取方式:第一次读取本地,本地失败后第二次读取对端
    • 存储系统同步方式:对于密码数据,由于用户改密码频率较低,而且用户不可能在 1 秒内连续改多次密码,所以通过数据库的同步机制将数据复制到其他业务中心即可,用户信息数据和密码类似。
    • 回源读取方式:当用户在 A 中心登录后,然后又在 B 中心登录,B 中心拿到用户上传的 session id 后,根据路由判断 session 属于 A 中心,直接去 A 中心请求 session 数据即可;反之亦然,A 中心也可以到 B 中心去获取 session 数据。
    • 重新生成数据方式:对于“回源读取”场景,如果异常情况下,A 中心宕机了,B 中心请求 session 数据失败,此时就只能登录失败,让用户重新在 B 中心登录,生成新的 session 数据。
  • 只保证绝大部分用户的异地多活
  • 核心思想:采用多种手段,保证绝大部分用户的核心业务异地多活!

四步走

业务分级

按照一定的标准将业务进行分级,挑选出核心的业务,只为核心业务设计异地多活,降低方案整体复杂度和实现成本。常见的分级标准:

  • 访问量大的业务
  • 核心业务
  • 产生大量收入的业务

数据分类

挑选出核心业务后,需要对核心业务相关的数据进一步分析,目的在于识别所有的数据及数据特征,这些数据特征会影响后面的方案设计。常见的数据特征分析维度:

  • 数据量:这里的数据量包括总的数据量和新增、修改、删除的量。对异地多活架构来说,新增、修改、删除的数据就是可能要同步的数据,数据量越大,同步延迟的几率越高,同步方案需要考虑相应的解决方案。
  • 唯一性:唯一性指数据是否要求多个异地机房产生的同类数据必须保证唯一。
    • 数据的唯一性影响业务的多活设计,如果数据不需要唯一,那就说明两个地方都产生同类数据是可能的;
    • 如果数据要求必须唯一,要么只能一个中心点产生数据,要么需要设计一个数据唯一生成的算法。
  • 实时性:实时性要求越高,对同步的要求越高,方案越复杂。
  • 可丢失性:可丢失性指数据是否可以丢失。
  • 可恢复性:可恢复性指数据丢失后,是否可以通过某种手段进行恢复,如果数据可以恢复,至少说明对业务的影响不会那么大,这样可以相应地降低异地多活架构设计的复杂度。

数据同步

常见的数据同步方案:

  • 存储系统同步:
    • 优点:使用简单,因为几乎主流的存储系统都会有自己的同步方案
    • 缺点:这类同步方案都是通用的,无法针对业务数据特点做定制化的控制。
  • 消息队列同步:消息队列同步适合无事务性或者无时序性要求的数据。对于新注册的用户账号,我们可以采用消息队列同步了;而对于用户密码,就不能采用消息队列同步了。
  • 重复生成:数据不同步到异地机房,每个机房都可以生成数据,这个方案适合于可以重复生成的数据。

异常处理

无论数据同步方案如何设计,一旦出现极端异常的情况,总是会有部分数据出现异常的:

  • 同步延迟
  • 数据丢失
  • 数据不一致

异常处理主要目的

  • 问题发生时,避免少量数据异常导致整体业务不可用。
  • 问题恢复后,将异常的数据进行修正。
  • 对用户进行安抚,弥补用户损失。

常见的异常处理措施

多通道同步

采取多种方式来进行数据同步,其中某条通道故障的情况下,系统可以通过其他方式来进行同步,这种方式可以应对同步通道处故障的情况。方案关键点:

  • 一般情况下,采取两通道即可,采取更多通道理论上能够降低风险,但付出的成本也会增加很多。
  • 数据库同步通道和消息队列同步通道不能采用相同的网络连接,否则一旦网络故障,两个通道都同时故障;可以一个走公网连接,一个走内网连接。
  • 需要数据是可以重复覆盖的,即无论哪个通道先到哪个通道后到,最终结果是一样的。例如,新建账号数据就符合这个标准,而密码数据则不符合这个标准。
同步和访问结合

访问指异地机房通过系统的接口来进行数据访问。设计关键点:

  • 接口访问通道和数据库同步通道不能采用相同的网络连接,不能让数据库同步和接口访问都走同一条网络通道,可以采用接口访问走公网连接,数据库同步走内网连接这种方式。
  • 数据有路由规则,可以根据数据来推断应该访问哪个机房的接口来读取数据。
  • 由于有同步通道,优先读取本地数据,本地数据无法读取到再通过接口去访问,这样可以大大降低跨机房的异地接口访问数量,适合于实时性要求非常高的数据。
日志记录

主要用于用户故障恢复后对数据进行恢复,其主要方式是每个关键操作前后都记录相关一条日志,然后将日志保存在一个独立的地方,当故障恢复后,拿出日志跟数据进行对比,对数据进行修复。常见日志保存方式:

  • 服务器上保存日志,数据库中保存数据,这种方式可以应对单台数据库服务器故障或者宕机的情况。
  • 本地独立系统保存日志,这种方式可以应对某业务服务器和数据库同时宕机的情况。
  • 日志异地保存,这种方式可以应对机房宕机的情况。
用户补偿
  • 无论多么完美的方案,故障的场景下总是可能有一小部分用户业务上出问题,系统无法弥补这部分用户的损失。
  • 可以采用人工的方式对用户进行补偿,弥补用户损失,培养用户的忠诚度。简单来说,系统的方案是为了保证 99.99% 的用户在故障的场景下业务不受影响,人工的补偿是为了弥补 0.01% 的用户的损失。

个人思考

异地多活在前司个人感觉是个默认选项。比如 Redis 存储三地域双副本,一份数据要存6份:即本机房一主一从,然后同步到余下两个机房,而且是N+1冗余,也就是一个机房挂了,余下 N 个机房能够承接全部流量。这样做的好处就是:

  1. 用户都是就近访问的,速度快
  2. 可用性高,一个机房挂,直接自动切机房了,光缆挖断了、机房断电了也分分钟止损。

缺点就是:太浪费了,也比较复杂。比如我当时负责的几个 Redis 集群,有的是基础架构提供的多机房同步,有的是业务自己异步写远程机房,当然当时只是权衡之后这么搞的,如果要搞成 CP 就复杂了,也不适合业务自己搞。

现司就比较粗暴了,大部分业务只是单地域,然后通过同城多机房来做容灾。这种方式其实比较简单,比如在上海和苏州个有一个机房,但是对于业务来说这两个机房无差别,请求会均匀分配到两个机房的机器上,当上海的机房挂了,请求自然到了苏州了。简单粗暴,效果好。问题就是,如果服务都部署在深圳的机房了,北京的用户请求也要跑到深圳再回来,耗时多了几十毫秒。

简单的说,异地多活,是富家子的操作,追求最后的 0.00001 的收益。大厂可以搞搞,小厂如果不是对可用性有特别特别高的需求还是算了吧。

reference

  1. 从 0 开始学架构
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-05-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 闲余说 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
异地多活架构
同城异区两个机房距离一般就是几十千米,网络传输速度几乎和同一个机房相同,降低了系统复杂度、成本。
dys
2019/05/07
3.3K0
异地多活架构
工作十年,在腾讯沉淀的高可用系统架构设计经验
👉腾小云导读 在系统的开发过程中,很多开发者都为了实现系统的高可用性而发愁。本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用系统的架构设计需要有哪些关键的设计和考虑。希望腾讯的经验方法,能够给广大开发者提供参考。内容较长,您可以收藏后持续阅读。 👉看目录点收藏,随时涨技术 1 高可用系统的架构设计思想     1.1 可用性和高可用概念     1.2 高可用系统设计思想 2 研发规范层面     2.1 方案设计和编码规范     2.2 容量规划
腾讯云开发者
2023/03/14
5.5K0
工作十年,在腾讯沉淀的高可用系统架构设计经验
详解:淘宝高可用异地多活架构
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读:异地多活,作为一种高可用部署架构,成为大中型互联网公司的选择。像大家熟知的大型互联网公司,如阿里
xcbeyond
2020/11/30
2.7K0
详解:淘宝高可用异地多活架构
技术角 | 架构学习书摘总结(三)高可用架构模式(下)
最近阅读了一本架构方面的入门图书叫《从零开始学架构:照着做,你也能成为架构师》,部分内容比较不错,先做书摘总结,以便加深印象与未来回顾学习。
ZNing
2020/05/13
9020
数据库高可用架构设计,看这篇就够了!!!
又赶上一年一度的金九银十的日子,这段期间的招聘岗位相对前几个月会多些,如果在目前公司没有进步、没有前途时,这段时间可以准备一下,去外面看看机会。不过在外面找工作时,可以提前在网上看看招聘信息,看看自己是否达到公司要求。如果多看下高薪资的技术人员招聘要求时,就会发现对三高都有一定的要求,比如下面一家公司的要求就对高并发、高负载和高可用性系统设计要有开发经验。
一个会写诗的程序员
2023/03/08
2.9K0
数据库高可用架构设计,看这篇就够了!!!
聊聊高可用的“异地多活”架构设计
来源:https://blog.dogchao.cn/?p=299  前言 后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过 F5 或者任何代理
程序猿DD
2022/10/11
1.8K0
聊聊高可用的“异地多活”架构设计
谈谈异地多活架构
无论是高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能所有服务器都出现故障。例如,典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫痪,而且即使有其他地区的备份,把备份业务系统全部恢复到能够正常提供业务,花费的时间也比较长,可能是半小时,也可能是12小时。因为备份系统平时不对外提供服务,可能会存在很多隐藏的问题没有发现。如果业务期望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复,那么就需要设计异地多活架构。
iMike
2019/06/02
3.4K0
同城双活与异地多活架构分析
采用高可用系统架构支持重要系统,为关键业务提供7x24的不间断服务,已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
2020labs小助手
2020/09/14
12.9K0
饿了么的异地多活架构设计是什么样的?
饿了么技术团队花了1年多的时间,实现了业务的整体异地多活,能够灵活的在多个异地机房之间调度用户,实现了自由扩容和多机房容灾的目标。本文介绍这个项目的整体结构,还简要介绍实现多活的5大核心基础组件,为读者建立基本的概念模型,后续会有系列文章陆续介绍每个组件的实现细节。读者能够从中了解到做异地多活的大方向,为实现自己的异地多活,或者是容灾备份提供参考。
肉眼品世界
2020/11/17
1.8K0
饿了么的异地多活架构设计是什么样的?
微服务高可用容灾架构设计
相对于过去单体或 SOA 架构,建设微服务架构所依赖的组件发生了改变,因此分析与设计高可用容灾架构方案的思路也随之改变,本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
腾讯云中间件团队
2023/09/09
1.3K0
微服务高可用容灾架构设计
异地双活实践笔记
最近恰好在搞异地双活,以下是一个梳理: 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候,另外一个机房只是当做备份。 2、异地双(多)活。而异地双(多)活,却是指有两个或者多个可以同时对外服务的节点,任意一个点挂了,也可以迅速切换到其他节点对外服务,节点之间的数据做到准实时同步。 分类 根据是否需要数据同步大体分为三类: 1、必须同步型。(比如数据库) 2、无须同步型。比如缓存,仅仅是当做缓存,就可以这样做(这个有待商榷,其实缓存也需要同步的,严格来说的话)。 3、只能单活(对全局原
ImportSource
2018/04/03
12.3K0
异地双活实践笔记
搞懂异地多活,看这篇就够了
在软件开发领域,「异地多活」是分布式系统架构设计的一座高峰,很多人经常听过它,但很少人理解其中的原理。
_Kaito
2021/10/20
2.8K0
企业级 IP 电话系统高可用架构设计详解
设计高可用架构需要合理部署以下核心组件,每个组件的高可用性都直接影响系统的整体表现:
杜金房
2025/03/27
2980
企业级 IP 电话系统高可用架构设计详解
面向业务的高可用架构设计
· 再好的技术、再完美的规章 , 在实际操作层面也无法取代人自身的素质和责任心 。
架构精进之路
2021/03/15
8190
B 站崩了,总结下「高可用」和「异地多活」
不用想象一种异常场景了,这就真实发生了:B 站晚上 11 点突然挂了,网站主页直接报 404。
悟空聊架构
2021/07/16
8570
B 站崩了,总结下「高可用」和「异地多活」
架构设计---高可用的处理
系统的高可用架构就是要在上述各种故障情况下,保证系统依然可用提供服务,具体包括以下几种架构方案。
小马哥学JAVA
2023/02/27
4240
架构设计---高可用的处理
拆解交易系统--异地多活
很多产品发展到一定规模之后,可能会走出国门,技术架构要做到国际化。或者基于高可用 / 高性能的需求,需要做异地多活。
春哥大魔王
2020/01/16
8040
拆解交易系统--异地多活
什么是异地双活及应用场景
依托于阿里云高速通道专线、事件总线EventBridge和MSHA(Multi-Site High Availability)多活容灾平台,消息队列RocketMQ版提供异地双活功能,通过跨实例间数据的双向同步和业务切流能力,实现业务恢复和故障恢复解耦,保障故障场景下的业务连续性。本文介绍异地双活的概念、应用场景、功能优势、使用限制和计费说明。
码农编程进阶笔记
2022/12/21
1.8K0
什么是异地双活及应用场景
借“云”飞天:云原生时代异地多活架构设计新范式
摘要: 随着数字化转型的加速,企业对于应用系统的高可用性、高性能和可扩展性提出了更为严苛的要求。云原生技术的兴起为异地多活架构的设计与实现带来了全新的机遇与变革。本文深入探讨云原生如何赋能异地多活架构,详细阐述其关键技术与实践策略,并分析在云原生环境下构建异地多活架构所面临的挑战与应对措施,旨在为企业在云时代构建健壮、灵活且高效的分布式系统提供全面的技术参考与实践指南。
华仔爱技术
2024/12/25
2330
借“云”飞天:云原生时代异地多活架构设计新范式
高可用架构:如何做到应用升级无感知
十几年前,我参加阿里巴巴面试的时候,觉得阿里巴巴这样的网站Web应用开发简直小菜,因为我之前是做类似Tomcat这样的Web容器开发的,所以面试的时候信心满满。
wayn
2024/03/11
3910
高可用架构:如何做到应用升级无感知
推荐阅读
相关推荐
异地多活架构
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档