记一次独角兽公司双系统迁移合并解决方案
前言
前几天遇上了前同事，简单地寒暄了几句。看着这个当初给我们辛苦测试的小伙伴，就联想起那个时候双系统迁移合并的事情，因为当初就是他来测试我做的这个项目工作。现在想来，这个项目倒还算可圈可点。所以记录分享一下，也来为自己怀念一下。
背景
上一家公司是一家 P2P 理财公司，那个时候 P2P 在杭州搞得如火如荼的。那个时候刚好遇上两个事情，一是我们自己的理财平台接入了银行存管系统，二是我们公司收购了一家在杭州本地的一家 P2P 公司（不得不说那个时候公司实力还是可以的）。所以公司层面决定想将收购的公司的用户数据迁移同步到我们自己的系统体系中来，一来不需要再重新对收购平台进行银行存管的接入，二来就是便于管理维护数据，再者，也是为了以后收购更多的平台做好示范工作（不得不说，野心很大；但是野心再大也抵不过一份红头文件，哈哈哈）。
分析
以下我分别用 A、B 系统来分别表示，B 系统是迁移的对象，需要合并到 A 系统当中。
系统迁移这类的工作，我个人是觉得要从两方面入手:
业务方面，数据的迁移工作需要兼容现有系统体系；
技术方面，数据的迁移工作需要做到双方数据的一致性，需要尽可能减少对用户的影响，做到理想的平滑迁移。
业务方面其实没什么好讲，因为系统业务的不同，导致如何兼容已有业务，都是要根据实际情况出发。例如 A、B 系统的用户表，多少是会存在不一样的字段，或者多了或者少了，或者概念上有冲突，都是有可能的，这个看各自的取舍。当然有一种特殊的场景需要考虑，就是用户在 A、B 系统中都有进行过注册以及存在用户行为。这个也是要根据业务场景进行选择。而当时我们的做法是依然保留 B 系统的记录，只是这条记录不会作为真实使用，而只是作为一个标识。根据 B 的记录可以查询到真正的用户数据 A。
当然，既然是解决方案，那么更多的是从技术上的角度出发。为此如何设计这个解决方案，则是一个统筹层面的任务。
首先我们要明确本次迁移想要达到的效果:
数据一致性；
尽可能的平滑迁移。
这里的数据一致性问题其实不是太大问题，虽然这个是最必要的环节。数据怎么进行平滑迁移才是最难的挑战。当我听到要求平滑迁移的时候，我第一反应就是之前看 JVM 的时候提到的几种垃圾回收器，尤其是那个经典的比喻：一边扫地一边吐瓜子壳。其实这个场景也是一样。因为平滑迁移的话，那么就意味着 A、B 两系统，尤其是 B 系统不停服。那么在迁移的时候就有可能还会产生新的数据，也就是用户流量当中的 DML 操作。
解决思路
看上去好像不是那么容易做到的，难道就没有解决思路吗？我能想到类似的解决方案就是 MySQL 的主从同步。目前大多数公司的 MySQL 都是采用主从的架构方案，来保证它的可用性。那么 MySQL 的从库在崩坏、修复之后是如何保证跟主库保持一直的呢？没错，大家想到的就是采用备份+binlog 日志的做法。
MySQL 的 binlog 日志，对于 MySQL 而言是十分重要的东西，是用来记录每一条记录的 DML 操作。对于一条记录来说，通过收集这一条记录上的 binlog 日志，就会保证数据保证多端的一致性，或者说，多条 binlog 的合并就是一个终态的数据库记录。这就让我想起在第一家公司工作的时候，曾经做过 MySQL 表聚合生成宽表的需求，它的做法就是通过监听 MySQL 上的 binlog 日志，并且发送到 Kafka 当中，通过消费 kafka 的消息来同步生成、维护库表记录，从而和主表保持数据的一致。
但是很遗憾，由于公司层面并没有相关 MySQL 监听 binlog 的工程服务，所以不能直接从 MySQL 层面进行出发，但是思路还是这样的一个思路，可以再代码层面上进行增量处理。
涉及哪些东西呢
A 系统
对于 A 系统来说，在这个迁移过程中的角色不是十分重要，但是值得一提的是，由于会新增 B 系统的用户，所以需要将用户表的自增 ID 空出一部分，例如 A 系统的用户表内已经有 200 多 w 的数据，B 系统内有 50 多 w 的数据，那么需要将自增 ID 改成 300w，从 300w 开始自增。而 B 系统的这部分用户按照(240w + B 系统用户 ID)这样映射的方式进行插入。
为什么要这样做呢？这主要是方便数据的定位已经校准。在数据迁移完之后，必不可少的就是数据的校准，否则只能根据用户的唯一信息进行判断，那么当 A、B 系统都存在该用户信息的时候，这个时候就会显得十分鸡肋。
B 系统
对于 B 系统而言，需要保证的是用户能够在迁移工作中能够正常的使用，当然，可以允许部分的性能损失，但是不能够说失去可用性。当用户进行查询操作的时候，这个不会产生影响；但是存在增删改操作的时候，这个时候就需要注意记录下相关的 SQL。因为按照上述的思路，会在某一时刻切出一个备份，那么迁移工作也是针对这个备份而言。用户在这之后产生的增删改操作，则需要通过增量 SQL 的形式进行同步。当然，这里也会有一些情况：如果此时正在迁移该用户数据，此时产生了 SQL 怎么办？如果此时迁移工作已经在处理增量 SQL，而 B 系统又产生了新的 SQL 怎么办？这几个关键场景我们都需要好好分析一下
迁移合并程序
迁移程序这边倒没什么具体的说法，因为更重的部分还是业务上的迁移和合并操作。只是需要注意的是和 B 系统之前的协调。在完成数据迁移合并工作之后，还需要执行那些增量 SQL。
校准程序
在完成迁移工作之后，还需要留出几天的观察期，这几天每天都需要定时执行这个校准程序，来检查这部分用户的信息、金额、产品等等信息的数据一致性。
方案
来了来了，前面说了一大堆，我猜你们肯定已经嫌烦了，再讲下去你们可就要关了网页了。什么，现在就要关！大爷，请留步，给个面子，看在我码字不容易的份上。
上图上图
这个是 B 系统的流程图。
这个是迁移程序的流程图。
在讲解之前，我会预先做两个事情:
将 B 系统的用户设置在 Redis 当中，并且标识内容为 0，例如 key 为 com:showyool:user:123，value 为 0，0 标识还没有开始迁移，1 标识正在迁移。
将这些用户 ID 发送到 RocketMQ 当中，当多台机器上的迁移程序启动之后，就会去消费这些消息，并且存储到内存当中的 ConcurrentLinkedQueue 当中。迁移程序当中的线程池就会去这个队列当中获取一个个用户并且并发处理。
B 系统的流程图
接下来我们就可以来讲解一下，首先线程 B 系统的流程图开始讲解:
当用户的 DML 操作请求过来之后，首先我们获取获取分布式锁 key1，当然这个是用户级别的锁。这个锁的作用就是为了跟迁移程序进行协调。
如果获取成功，那么需要去 redis 判断 com:showyool:user:xxx 是否存在，这里不管 0 还是 1 都没关系，因为只要存在，就说明这个用户数据还没有迁移，而且因为已经拿到分布式锁 key1，所以也不会担心迁移程序的操作，这个后续可以再看。如果存在，那么就正常的执行 DML 操作，然后将组织的 SQL 存入到 MySQL 当中，最后释放这个分布式锁 key1。如果不存在，说明用户的数据已经迁移完了，那么就组织 SQL 发送到 RocketMQ 中。（这里大家可能会问，为什么第一种情况将 SQL 存入到 MySQL 当中，第二种情况将 SQL 发到 RocketMQ 当中。这里当初的设想是，发到 RocketMQ 的话可能会被快速消费掉，而第一种情况还没有进行迁移，在一个连记录都没有情况下进行增删改 SQL 的追加有点不合适。所以存入 MySQL 当中是希望能够当迁移工作完成之后主动捞取这里的消息。当然，SQL 执行的顺序性，其实无论 MySQL 还是 RocketMQ 都能保证）。
回到上一层，如果一开始的分布式锁 key1 没有获取到，那么就去获取 redis 当中这个用户的内容。如果不存在，则表明用户数据已经迁移完，那这里是正常的用户流量的用法，也就是说之前的用户请求可能先获取了这个分布式锁。则进行正常的 DML 操作，并且组织 SQL 发到 RocketMQ 当中就好。如果这个内容是 0，则表情是正常的用户流量并发，而且这个时候数据还没有开始迁移，那么进行正常的 DML 操作，并且组织 SQL 存到 MySQL 当中就好。还有一种情况，也是比较复杂的，就是内容为 1，所以此时已经在迁移了。也就是说，迁移程序先是拿到了分布式锁 key1，然后将内容置为 1，已经开始在迁移。那么这个时候 B 系统可以进行正常的 DML 操作。接下来，就是比较麻烦的是，需要获取分布式锁 key2，也是用户级别的。为什么要再搞一个分布式锁呢？就是我们之前分析过的几种场景。我们看下下面的图
当我们的迁移程序在获取增量 SQL 并且执行的时候，可能存在三个时间点会面临来自 B 系统的新增 SQL。我们来简单分析下：
第一个新增 SQL，由于迁移程序还没有开始处理新增 SQL，所以在这个时间点新增 SQL 是合理的;
第二个新增 SQL，由于迁移程序已经获取了新增 SQL，却又新增了一条 SQL，这个其实在我们学数据库原理的时候就是一个典型的幻读问题，这个是不合理的;
第三个新增 SQL，由于迁移程序都已经处理员增量 SQL，这个地方新增的 SQL 也不会被处理，情况就跟第二个类似。
那么对于后面两种情况怎么处理呢？我们先来看看第三种新增 SQL，这种情况下就不需要再存入 MySQL 了，直接发送到 RocketMQ 去消费处理即可。麻烦的在于第二个情况。这个情况下，我们其实是不应该发生的，所以需要进行一个并发的控制，这也就是为什么我会引入第二个分布式锁的原因！
接着上面的说，如果获取分布式锁 key2 成功了，那么判断一下 redis 当中是否还有该用户，如果不存在了，所以迁移程序已经处理完，那么就是第三种情况，发送至 RocketMQ 就好。如果 redis 中还存在，那么就是第一种情况，存入 MySQL 就好。如果获取分布式锁失败了，要么是正常用户流量的并发问题，要么就是迁移工作正在处理增量 SQL，这个时候只要重试即可，重新获取该分布式锁，也就杜绝了第二种情况的发生。
迁移程序的流程图
如果已经了解上面 B 系统的流程图的话，那么对于这个迁移程序的流程肯定也是很快就能了解。本着认真的态度，我还是想着跟大家讲述一下: (你看我态度这么好，要不点个赞吧，嘤嘤嘤）
线程池当中的线程从 ConcurrentLinkedQueue 当中获取用户，于是从开始对这个用户进行迁移操作。
首先还是需要去获取分布式锁 key1，如果成功获取，那么就将 redis 当中的用户内容置为 1，表明已经进入到迁移状态。紧接着就是一段漫长的迁移合并工作，这个就是业务性质的代码操作，就不便多说。当迁移合并工作完成之后，那么就获取分布式锁 key2，也就是要进入到执行增量 SQL 的环节，大多数情况下，是很快就能获取成功的（毕竟都是后半夜操作，那个点正常人都睡了，什么，你没睡，那你？？）。然后就是执行增量 SQL，执行完了之后就清除 redis 当中的用户信息，最后就是释放分布式锁 key2，key1。那如果获取分布式锁 key2 失败了，说明此时用户正在操作，那么重试就好。
如果分布式锁 key2 获取失败了，那么说明此时用户流量已经进入 B 系统并且持有这个 key2，那么在 redis 当中记录一下这个用户，新开一个 key，例如 com:showyool:fail:user:123，value 就是失败的次数。然后隔一段时间之后再去获取这个分布式锁 key1，如果获取成功就执行上述流程，如果失败，则继续增加这个计数器。直到累计失败 15 次的话，那么就不再对这个用户进行操作，选择下一个用户。这个是考虑到，这个用户可能是一个十分活跃的用户，所以可能对这一类的用户进行单独特殊处理，虽然处理的流程跟主流程也差不多（在当时迁移的时候也没有出现过，倒是有几个用户失败个一两次的，这个还是蛮惊喜的，对，惊喜，你给翻译翻译，什么叫惊喜）。
实施
那么上面把核心的思路、方案都描述了一下，接下来把当时具体的实施情况也分享一下。
屏蔽 B 系统的注册入口，并且将用户注册引导到 A 系统当中。
选择凌晨 2 点开始进行操作。选择这个时间点，一是因为 2 点的时候，绝大多数用户已经睡觉了，所以用户的 DML 操作也不是特别多。另外凌晨会有一大波的定时任务会执行，例如计算利息、罚息等等情况（你看支付宝上余额宝的收益，并不是在 0 点准时显示，都是定时任务跑任务在计算）。因为定时任务在执行任务会有一大波 DML 操作，所以可以避开那个时间点，一般在 1 点半之前都可以执行完。
2 点的时候需要将 B 系统的服务下线，并且将写的好的代码发到 A、B 系统上，还要部署迁移合并程序。数据库层面，需要对 B 系统数据库进行一个备份，A 系统数据库当中的用户表的 auto_increment 修改成 300w。在 B 系统上线之前，需要在 redis 当中设置好用户数据，例如 com:showyool:user:123=0.要说完全的平滑迁移，那么这个时候其实算不得，毕竟这也是小小的停服了，好在这个地方需要的时间不是很多。
检查服务都已经上线，启动检查校准程序。关于这一块，我在上面没有怎么说到，因为我觉得这个程序就只是一个业务性质的校准，也是为了数据一致性。此外需要将用户 ID 发送到 RocketMQ，这些迁移合并程序就会对这个 topic 进行消费，并且存入到各自内存中的 ConcurrentLinkedQueue 的。线程池当中的线程会不断从这个队列当中获取用户 ID。一旦出现用户 ID，就开始进行迁移工作。
接着就是观察各项数据情况，例如迁移了多少用户，还剩下多少用户等信息。
当然，上面的流程图当中还提到了失败用户，虽然实际情况中确实没有出现，但是如果最后还有这种失败用户的话，重新发送到 RocketMQ 继续执行。
最后的最后，当然是交给测试了……而我就是看着东升的太阳，不知道是在发呆还是睡觉了。
后续
思绪把我从那个时候拉扯到眼前这个快秃了头的大叔，笑语之间，像是一种熟悉的默契。那终归是一场美好的回忆，也是我一身成长道路上的荼蘼花开。我的过去不一定完美，也会有欢迎的批评与斧正，但希望还是勇敢走下去，与你，与我，与 Java。
作者：showyool
链接：https://juejin.cn/post/6931718215177338893
来源：掘金
还未添加个人签名 2020.09.02 加入
还未添加个人简介
评论