这是学习笔记的第 2130 篇文章

  在实际的工作场景中，我们如果要对一个系统进行改造，很可能需要进行充分的验证，一来能够对已有的系统进行重构改造，满足新的业务需求，另一方面，我们希望能够提供一种保险箱的业务属性，即业务发生问题的时候我们可以快速恢复，这一层的恢复已经远远超出了数据库层面的数据恢复，所以这是一个略带矛盾的需求现状，也是很多问题处理的背景情况，我们需要改进，同时也需要不断迭代，直到满足需求，实现系统的蜕变。

  最近在一个数据业务的架构改造中，我们沉淀了一些设计思想，对于服务的双活和业务可持续性方面做了一些实际的探索，感觉还是比较有收获的，我把设计的一些思想方法总结一下。

首先这个问题的背景是上层是存在一些流量服务的，流量服务是总线型设计，不需要绑定太多的业务属性在里面，而在具体的业务层面，就会有相应的业务系统，我们可以举一个例子，比如你去银行参与活动，获得了一些会员积分，会员积分这种的数据在流量入口进来之后，会有相应的积分服务来支撑，这里的服务就是类似这样的含义，要对已有的数据服务进行改造，同时这个改造的过程是对上层业务无感知的，我们需要构建一套新的数据服务，我们简称为数据服务-new吧，其中的一个改造方向就是从商业数据库中改造迁移出来，完成数据存储层的分布式架构设计，类似下面的设计方式。

而在这个过程中，一大改进就是对于开发层面的重要变化，我们引入了旁路的概念，即下面绿色箭头的设计方式，已有数据服务的数据可以通过旁路的形式“同步”到新的数据服务中，而底层的数据库之间是互相不“串门”，而且完全没有任何关联的。

这一层的好处就是我们可以通过旁路完成部分流量的切换，比如5%，10%，直至100%，也可以完成多倍的流量模拟，比如200%，400%等等。

背景说差不多了，我们看一下这样的系统是如何完成迁移的过程的，首先迁移的过程是不允许服务中断的。假设这个数据量有2T,那么我们就需要想办法把这2T的数据从一个数据库中“搬迁”到另外一个异构数据库中。不管带宽速度如何，这个过程的耗时都在2小时以上，所以服务不能中断2个小时，我们所有的迁移工作就需要保证在异步的状态下完成。

所以整个阶段会分为三个部分：

第一层就是全量同步，即把数据从商业数据库中全量同步到分布式集群中。

在这个过程中已有的数据服务还是有数据写入的，那问题来了，如果数据持续写入，那就始终是一个动态变化的数据集，对于迁移来说，就没法得到一个基线了，实际迁移中基线是极为重要的，因为它能够直接决定我们的过程是否可控，是否可以及时修复，我碰到过很多数据迁移中莫名其妙多了一些数据，或者漏了一些数据，没有基线，拍胸脯说没问题是没用的，我们得用数据来说话，所以一种行之有效的方式，应该是一个快照，全量同步应该是静态数据的全量迁移，这样一来，我们可以肯定知道我们的数据迁移是否成功。

全量完成之后，那这个过程中的数据变化如何获取呢，通过快照显然是不能满足需求的，所以我们需要引入一个临时中转库，只负责增量数据的提取，这个提取过程基于时间戳的方式来完成，在分布式节点中存储的是状态数据。

这样一来我们实际进行的是两部分的工作，新增的数据进行写入，而更新的数据进行覆盖，这个过程类似于MySQL中的insert into on duplicate的处理方式。

当然在进行增量提取到恢复的过程中，时间虽然很短，但是依然会有新的数据写入，这部分的数据如何保证呢。我们其实是基于两个维度来实现的，第一部分是增量数据，第二部分是数据稽核，即在这个过程中还是可能出现数据不一致的情况，我们就需要进行数据稽核，数据稽核的逻辑是在进行增量同步开始，数据服务会把这个过程中的用户id给记录下来，这要用户的状态发生变化，就把id记录下来，这样一来就是一个user_list,

在增量同步完成之后，需要进行数据稽核时会提取到这个user_list,会在两套异构数据库中进行实时比较，如何状态不一，则以已有数据服务的数据覆盖数据服务-new的，这样一来源头数据只有一个，而且校验的标准也是单向的。

完成这个之后，就是上层流量的整体切换了，我们在下一次来分享一下。

个人公众号：jianrong-notes