高可用架构模式——异地多活设计步骤
目录
-
- 一、步骤1——业务分级
-
- 1.1、分级标准
-
- 1.1.1、访问量大的业务
- 1.1.2、核心业务
- 1.1.3、产生大量收入的业务
- 二、步骤2——数据分类
-
- 2.1、数据特征分析维度
-
- 2.1.1、数据量
- 2.1.2、唯一性
- 2.1.3、实时性
- 2.1.4、可丢失性
- 2.1.5、可恢复性
- 三、步骤3——数据同步
-
- 3.1、数据同步方案
-
- 3.1.1、存储系统同步
- 3.1.2、消息队列同步
- 3.1.3、重复生成
- 四、步骤4——异常处理
-
- 4.1、异常处理的目的
- 4.2、常见的异常处理措施
-
- 4.2.1、多通道同步
-
- 4.2.1.1、多通道同步设计的方案关键点
- 4.2.2、同步和访问结合
-
- 4.2.2.1、同步和访问结合方案的设计关键点
- 4.2.3、日志记录
-
- 4.2.3.1、常见的日志保存方式
- 4.2.3、用户补偿
本文来源:极客时间vip课程笔记
一、步骤1——业务分级
- 按照一定的标准将业务进行分级,挑选出核心的业务,只为核心业务设计异地多活,降低方案整体复杂度和实现成本。
1.1、分级标准
1.1.1、访问量大的业务
- 以用户管理系统为例,业务包括登录、注册、用户信息管理,其中登录的访问量肯定是最大的。
1.1.2、核心业务
- 以 QQ 为例,QQ 的主场景是聊天,QQ 空间虽然也是重要业务,但和聊天相比,重要性就会低一些,如果要从聊天和 QQ 空间两个业务里面挑选一个做异地多活,那明显聊天要更重要(当然,此类公司如腾讯,应该是两个都实现了异地多活的)。
1.1.3、产生大量收入的业务
- 同样以 QQ 为例,聊天可能很难为腾讯带来收益,因为聊天没法插入广告;而 QQ 空间反而可能带来更多收益,因为 QQ 空间可以插入很多广告,因此如果从收入的角度来看,QQ 空间做异地多活的优先级反而高于 QQ 聊天了。
二、步骤2——数据分类
- 挑选出核心业务后,需要对核心业务相关的数据进一步分析,目的在于识别所有的数据及数据特征,这些数据特征会影响后面的方案设计。
2.1、数据特征分析维度
2.1.1、数据量
- 这里的数据量包括总的数据量和新增、修改、删除的量。对异地多活架构来说,新增、修改、删除的数据就是可能要同步的数据,数据量越大,同步延迟的几率越高,同步方案需要考虑相应的解决方案。
2.1.2、唯一性
-
唯一性指数据是否要求多个异地机房产生的同类数据必须保证唯一。
例如用户 ID,如果两个机房的两个不同用户注册后生成了一样的用户 ID,这样业务上就出错了。
-
数据的唯一性影响业务的多活设计,如果数据不需要唯一,那就说明两个地方都产生同类数据是可能的;如果数据要求必须唯一,要么只能一个中心点产生数据,要么需要设计一个数据唯一生成的算法。
2.1.3、实时性
- 实时性指如果在 A 机房修改了数据,要求多长时间必须同步到 B 机房,实时性要求越高,对同步的要求越高,方案越复杂。
2.1.4、可丢失性
-
可丢失性指数据是否可以丢失。例如,写入 A 机房的数据还没有同步到 B 机房,此时 A 机房机器宕机会导致数据丢失,那这部分丢失的数据是否对业务会产生重大影响。
例如,登录过程中产生的 session 数据就是可丢失的,因为用户只要重新登录就可以生成新的 sessi