业务高可用, 2023-08-05

(2023.08.05 Sat @KLN)

异地多活

高可用的计算/存储架构，设计目的是解决在部分服务器出现故障的场景下，系统能够继续提供服务。极端场景下，字机房断电、火灾、地震、水灾等，系统所有服务器都可能出现故障。即便采用备份，恢复的时间也比较长。此时需要异地多活架构。

异地多活架构的两个关键点如命所示，分别是异地和多活。异地，指的是服务放在不同的地方；多活指不同地理位置的系统都能够提供业务服务。判断异地多活的两个标准：

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

异地多活中的活字，与之对应的是备字。备，即备份，正常情况下不对外提供服务，若提供服务则需要大量人工干预和操作，才能让备变成活。

显然异地多活具备不低的代价，保证多个地点的机房同时能对外提供服务。并非所有业务功能都需要异地多活，比如新闻网站仅提供信息，企业内部的IT系统、博客站等，异地多活对这类服务来说成本过高，仅需要备份就就可以。而打车、在线支付等业务，需要保证服务的实时性连续性，异地多活就变得很有必要了。

异地多活架构

1. 同城异地
2. 跨城异地
3. 跨国异地

1. 同城异地
   在一个城市部署多个机房，之前用专用高速网络连接在一起。该架构优势在于同城，逻辑上可视为一个机房，设计复杂度和成本比较低。但应对自然灾害和城市灾害的能力不高。

2. 跨城异地
   异地之间距离要远，避免出现区域性大停电和区域性自然灾害的情况。同时，距离远也导致了架构复杂度提升，机房的网络传输速度会降低。

距离的提升导致期间不可控因素也提升。可能导致延迟提升。

网络延迟提升给业务带来了复杂性。真正的多活需要再不同地点部署机房，又要从数据的角度保证业务多活，这就带来看似矛盾的地方：(异地引起的网络延迟导致)数据不一致，会使得业务不会正藏，但跨城异地肯定会导致数据不一致。

解决问题在于数据，根据数据的特性来做架构设计。强一致性的数据，如银行存款余额、支付宝余额，实际上无法做到跨城异地多活。即便实现出来也可能被黑客利用。对数据一致性要求不高，或数据改变不多，或即便丢失也影响不大的业务数据，跨城异地就可以使用了。比如登录数据(数据不一致时重新登录即可)、新闻类网站(日内数据变化较少)和微博类网站(丢失用户发布的微博和评论则影响不大)，可应用跨城多活。

3. 跨国异地
   距离更远，延迟更长。应对的是如下情况：

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

每个架构的关键点提炼如下：

• 同城异区
  搭建高速网络将两个机房连接起来，达到近似于一个本地机房的效果，可以将两个机房当做本地机房来设计，无须额外考虑
• 跨城异地
  在数据不一致的情况下，业务不受影响或很小。设计的目的就是为了解决这个矛盾
• 跨国异地
  面相不同地区用户，或提供只读业务，对架构设计要求不高

异地多活设计技巧

异地多活主要针对跨城异地这种复杂度最高的架构。

• 技巧一：保证核心业务异地多活
  避免误区：保证所有业务的异地多活
  优先实现核心业务的异地多活架构
  举例来说，登录是核心业务，但是用户注册和用户信息修改非核心业务

• 技巧二：核心数据最终一致性
  通过异地的数据冗余，保证极端情况下业务也能够正常提供给用户。数据同步是异地多活架构设计的核心。避免完美主义误区：所有数据都实时同步。但异地多活理论上不可能很快，这是物理定律决定的。
  有几种方法：

1. 减少异地多活机房的距离，搭建高速网络
2. 减少数据同步，只同步核心业务相关数据
3. 保证最终一致性，不保证实时一致性：CAP理论中的BASE理论，业务不依赖数据同步的实时性，只要数据最终能一致就可以

• 技巧三：采用多种手段同步数据
  数据同步是异地多活架构设计的核心。各个数据库的存储系统都提供了数据同步功能。一个不得不注意的问题是数据库提供给的同步功能往往有各种问题。MySQL 5.1版的复制是单线程复制，在网络抖动或大量数据同步时常发生延迟较长的问题。Redis 3.0出现的Cluster功能提供主从复制，但是从机down机或主机断开时连接都需要重新连接主机，重新连接都会触发全量的主从复制。
  有如下几种数据同步方式：

1. 消息队列方式
   比如创建用户信息，账号只创建不会修改和删除，可将账号数据通过消息队列同步到其他业务中心
2. 二次读取方式
   假设消息队列也出现了延迟，用户在A中心注册，访问B中心的业务，B中心暂时拿不到用的账号数据。为解决这个问题，B中心读取本地数据失败，可根据路由规则，去A中心访问一次，也就是二次读取，第一次读取本地，本地失败后第二次读取对端。这样就解决了异常情况下同步延迟的问题。
3. 存储系统同步
   使用数据库自带的数据复制功能
4. 回源读取方式
   比如登录的session数据，数据量大，可不同步数据。用户在A中心登录后，又在B中心登录，B中心拿到用户上传的session id后，根据路由判断session属于A中心，去A中心请求session数据。
5. 重新生成数据方法
   同样是session数据，如果A中心down机，B请求数据失败，则要求用户在B登录，重新生成session数据

• 技巧四：只保证绝大部分用户的异地多活

异地多活设计步骤

1. 业务分级

2. 数据分类

3. 数据同步

4. 异常处理

5. 业务分级
   只有核心业务实现异地多活，降低整体复杂度和实现成本

常见的分级标准有这几种：

• 访问量达的业务：用户的登录、注册、信息管理，其中的登录是访问量最大的业务
• 核心业务：QQ空间和聊天业务 中，聊天是更加核心的业务
• 产生收入的业务：空间广告和聊天业务，空间广告是收入来说。实际上很可能聊天和空间都实现了异地多活

2. 数据分类
   对数据的特别分析维度包括下面几项

• 数据量：数据量大，则同步延迟的概率越高，同步方案需要考虑对应的解决方案
• 唯一性：多个异地机房才产生的同类数据必须保证唯一。比如用户ID。如果数据要求必须唯一，要么只能一个中心点产生数据，要么需要设计一个数据唯一生成的算法
• 实时性：对数据同步的实时性要求越高，方案越复杂
• 可丢失性：是否可丢失，比如session数据可丢失，但是用户ID不可丢失
• 可恢复性：用户密码丢失，可通过手机号找回；用户账号丢失，就无法找回

下面是三类数据的维度分析

数据	数据量	唯一性	实时性	可丢失性	可恢复性
用户ID	每天新增1万注册用户	全局唯一	5s内同步	不可丢失	不可恢复
用户密码	每天1千用户修改密码	用户唯一	5s内同步	可丢失	可重置密码恢复
登录session	每天1000万	全局唯一	无须同步	可丢失	可重复生成

3. 数据同步

• 存储系统同步：最简单的同步方式
• 消息队列同步：Kafka，ActiveMQ，RocketMQ等
• 重复生成：cookie，session，缓存数据

数据	数据量	唯一性	实时性	可丢失性	可恢复性	同步方案
用户ID	每天新增1万注册用户	全局唯一	5s内同步	不可丢失	不可恢复	消息队列同步
用户密码	每天1千用户修改密码	用户唯一	5s内同步	可丢失	可重置密码恢复	MySQL同步
登录session	每天1000万	全局唯一	无须同步	可丢失	可重复生成	重复生成

4. 异常处理
   同步延迟、数据丢失、数据不一致等。常见的异常处理方式有以下几类：

• 多通道同步
  以多种方式来进行数据同步， 其中某条通道故障的额情况下，系统通过其他方式来进行同步，可以应对同步通道处故障的情况。
  以用户账号注册为例。一开始挑选了MQ的方式同步。异常情况下，MQ通道可能中断，也可能延迟严重。为保证新注册的账号能快速同步到异地机房，再增加MySQL同步方式作为备份。除非两种方式都发生故障，不然数据总能同步到异地。
  注意，多通道同步有几个关键点

1. 采取两通道就可以，多了付出更高成本
2. MQ通道和DB同步通道不能采用相同的网络连接，因为网络一旦发生故障，通道将会阻塞。可选方案是一个连接公网，一个连接内网
3. 需要数据可以重复覆盖(幂等)，无论通过哪个通道写入异地，最终结果都是一样的。新建用户数据符合这个标准，但是密码数据不符合这个标准。

• 同步和访问结合
  异地机房通过系统接口进行数据访问。异地的B机房通过接口访问A的系统，获取用户账号信息。
  注意，同步和访问相结合方案的关键点：

1. 访问通道和数据库同步通道不能采用相同的网络连接/网络通道
2. 数据有路由规则，根据数据可推断应该由哪个机房的接口来获取数据
3. 有同步通道，故优先读取本地数据，本地数据无法读取再去接口访问，这样可降低跨机房的异地接口访问数量，适用于实时性要求高的数据

• 日志记录

• 用户补偿

Reference

1 从零开始学架构-照着做，你也能成为架构师，李运华著，电子工业出版社
2 excalidraw·