# 29-异地多活设计4步走

跨城异地设计的4个步骤：

# 第一步：业务分级

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

常见的分级标准：

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

# 第二步：数据分类

挑选出核心业务后，需要对核心业务的数据进一步分析，目的在于所有数据及数据特征。这些数据特征会影响后面的方案设计。

常见的数据特征维度：

• 数据量

  数据量包括总的数据量和新增、修改、删除的量。对异地多活的架构，新增、修改、删除的数据就是需要同步的数据。数据量越大，同步的延迟的概率就越高，同步方案需要考虑相应的解决方案。

• 唯一性

  唯一性是批多个异地机房产生的同类数据必须保证唯一。例如：用户ID，如果多个机房的二个不同用户产生相同的用户ID，那么业务上就是错误的。

  数据的唯一性影响业务的多活设计，如果数据不要求唯一，那说明二个地方都产生同类数据是可能的。如果数据要求必须是唯一的，要么就是只能由一个中心点产生数据，要么就需要设计一个数据唯一生成算法。

• 实时性

  实时性是指A机房修改数据后，要求多长时间同步到B机房，实时性要求越高,对同步的要求越高，方案越复杂。

• 可丢失性

  可丢失性是指数据是否可以丢失。例如：写入A机房的数据还没有同步到B机房，此时A机房机器宕机会导致数据丢失，那这部分数据的丢失是否会对业务产生影响。

  例如：用户session数据是可以丢失的，而用户ID数据是不可以丢失的。

• 可恢复性

  可恢复性是指在数据丢失后，是否可以使用某种方式进行恢复。如果数据可以恢复，至少说明对业务的影响不会很大，这样可以降低异地多活架构设计的复杂度。

# 第三步：数据同步

确定数据的特征后，我们可以根据不同的数据特征选择不同的数据同步方案：

• 存储系统的同步,例如：使用Mysql的数据主从数据同步，主主数据同步。

  这类同步方案简单，几乎所有的存储方案都会有自己的数据同步方案，缺点是这类方案都是通用的，无法根据业务数据特点进行定制化的控制。

• 消息队列同步

  采用独立的消息队列进行数据同步，常见的消息队列有：kafka，ActiveMQ，RocketMQ等。

  消息队列同步适合无事务性或无时序性要求的数据。

• 重复生成

  数据不同步到异地机房，每个机房可以生成数据,这个方案适合生成可以重复生成的数据。

# 第四步：异常处理

无论数据同步方案如何设计，一旦出现极端异常的情况，总是会有部分数据会出现异常的。例如：同步延迟、数据丢失、数据不一致等。异常处理就是假设在出现这些问题时，系统将采取什么措施来应对。异常处理主要有以下几个目的：

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

常见的异常处理方案：

• 多通道同步设计 多通道同步设计是采取多种方式进行数据同步，其中某条通道故障的情况下，系统可以通过其它方式进行同步,这各方式可应对单通道故障出故障的情况。

  多通道同步设计的关键点有：

  • 一般情况下，设计双通道即可，采取更多的通道理论上能够降低风险，但付出的成本也会增加很多。
  • 数据库同步和消息队列同步通道不能采用相同的网络连接,否则一旦网络故障,二个通道同时故障,可以一个走公网连接，一个走内网连接。
  • 数据是可以重复覆盖的,即无论哪个通道先到哪个通道后到，最终结果都是一致的。

• 同步和访问结合 访问是指异地机房通过系统的接口来进行访问。 同步和访问结合的设计关键点：

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

• 日志记录 日志记录主要用于故障恢复后进行数据恢复，其主要方式是在关键操作前后增加日志记录,然后将日志保存到一个独立的地方，当故障恢复后，拿日志跟数据进行对比，对数据进行修复。

  为了应对不同级别的故障，日志保存的要求也不一致，常见的日志保存方式有：

  • 服务器上保存日志，数据库服务器上保存数据，这种方式可以应对数据库服务器宕机或故障的情况。
  • 本地独立系统保存日志，可以应对应用服务器和数据库服务器同时出现故障的情况。
  • 日志异地保存，这种方式可以应对机房宕机的情况。

  上面不同的日志保存方式，应对的故障越严重，方案本身的复杂度和成本就越高，实际选择时要考虑成本和效益。

• 用户补偿

  无论采取合种措施，都只能最大限度的降低受到影响的范围和程度，无法完全做到没有任何影响。无论多么完美的方式，故障的情况下都有可能有一小部分用户业务出现问题，系统无法弥补这部分用户的损失。但我们可以用人工的方式对业务进行补偿，减少用户损失，增加用户忠诚度。简单来说，系统的方案是为了保障99.99的用户在故障情况下不受影响，人工的补偿是为了弥补这0.01%的损失。