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

导读：《架构设计》系列为极客工夫李运华老师《从 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 开始学架构