四步构建异地多活.docx

? ? ? ? ? ? ? ? 四步构建异地多活 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 第一步：业务分级 按照一定的标准将业务进行分级，挑选出核心的业务，只为核心业务设计异地多活，降低方案整体复杂度和实现成本。 常见的分级标准有如下几种。 访问量大的业务 以用户管理系统为例，业务包括登录、注册、用户信息管理，其中登录的访问量肯定是最大的。 核心业务 以QQ为例，QQ的主场景是聊天，QQ空间虽然也是重要业务，但和聊天相比，重要性就会低一些，如果要从聊天和QQ空间两个业务里面挑选一个做异地多活，那明显聊天要更重要（当然，腾讯此类公司，应该是两个都实现了异地多活的）。 产生大量收入的业务 同样以QQ为例，聊天可能很难为腾讯带来收益，因为聊天没法插入广告，而QQ空间反而可能带来更多收益，因为QQ空间可以插入很多广告，因此如果从收入的角度来看，QQ空间做异地多活的优先级反而高于QQ聊天了。 以我们的用户管理系统为例，“登录”业务符合“访问量大的业务”和“核心业务”这两条标准，因此我们将登录业务作为核心业务。 第二步：数据分类 挑选出核心业务后，需要对核心业务相关的数据进行进一步分析，目的在于识别所有的数据及数据特征，这些数据特征会影响后面的方案设计。 常见的数据特征分析维度如下。 数据量 这里的数据量包括总的数据量和新增、修改、删除的量。对异地多活架构来说，新增、修改、删除的数据就是可能要同步的数据，数据量越大，同步延迟的概率越高，同步方案需要考虑相应的解决方案。 唯一性 唯一性指数据是否要求多个异地机房产生的同类数据必须保证唯一。例如，用户ID，如果两个机房的两个不同用户注册后生成了一样的用户ID，这样业务上就出错了。 数据的唯一性影响业务的多活设计，如果数据不需要唯一，那就说明两个地方都产生同类数据是可能的；如果数据要求必须唯一，要么只能一个中心点产生数据，要么需要设计一个数据唯一生成的算法。 实时性 实时性指如果在A机房修改了数据，要求多长时间必须同步到B机房，实时性要求越高，对同步的要求越高，方案越复杂。 可丢失性 可丢失性指数据是否可以丢失。例如，写入A机房的数据还没有同步到B机房，此时A机房机器宕机会导致数据丢失，那这部分丢失的数据是否对业务会产生重大影响。 例如，登录过程中产生的session数据就是可丢失的，因为用户只要重新登录就可以生成新的session；而用户ID数据是不可丢失的，丢失后用户就会失去所有和用户ID相关的数据，例如，用户的好友、用户的钱等。 可恢复性 可恢复性指数据丢失后，是否可以通过某种手段进行恢复，如果数据可以恢复，至少说明对业务的影响不会那么大，这样可以相应地降低异地多活架构设计的复杂度。 例如，用户的微博丢失后，用户重新发一篇一模一样的微博，这个就是可恢复的；或者用户密码丢失，用户可以通过找回密码来重新设置一个新密码，这也算是可以恢复的；而用户账号如果丢失，用户无法登录系统，系统也无法通过其他途径来恢复这个账号，这就是不可恢复的数据。 我们同样以用户管理系统的登录业务为例，简单分析如下表所示。 ? 数　　据 数　据　量 唯　一　性 实　时　性 可丢失性 可恢复性 用户ID 每天新增1万注册用户 全局唯一 5s内同步 不可丢失 不可恢复 用户密码 每天1千用户修改密码 用户唯一 5s内同步 可丢失 可重置密码恢复 登录session 每天1000万 全局唯一 无须同步 可丢失 可重复生成 第三步：数据同步 确定数据的特点后，我们可以根据不同的数据设计不同的同步方案。常见的数据同步方案如下。 存储系统同步 这是最常用也是最简单的同步方式。例如，使用MySQL的数据主从数据同步、主主数据同步。 这类数据同步的优点是使用简单，因为几乎主流的存储系统都会有自己的同步方案；缺点是这类同步方案都是通用的，无法针对业务数据特点做定制化的控制。例如，无论需要同步的数据量有多大，MySQL都只有一个同步通道。因为要保证事务性，一旦数据量比较大，或者网络有延迟，则同步延迟就会比较严重。 消息队列同步 采用独立消息队列进行数据同步，常见的消息队列有Kafka、ActiveMQ、RocketMQ等。 消息队列同步适合无事务性或无时序性要求的数据。例如，用户账号，两个用户先后注册了账号A和B，如果同步时先把B同步到异地机房，再同步A到异地机房，业务上是没有问题的。而如果是用户密码，用户先改了密码为m，然后改了密码为n，同步时必须先保证同步m到异地机房，再同步n到异地机房，如果反过来，同步后用户的密码就不对了。因此，对于新注册的用户账号，我们可以采用消息队列同步了；而对于用户密码，就不能采用消息队列同步了。 重复生成 数据不同步到异地机房，每个机房都可以生成数据，这个方案适合