服务化带来的问题---之数据迁移经历

上一篇文章我们介绍了服务化带来的一系列问题。以及我们解决服务雪崩、链路过长问题难定位、服务调用关系错综复杂这几个问题的经历。

本文聊聊服务化过程中我曾经的数据迁移经历。

服务化，其中一个重要意义在于数据隔离，也就意味着服务化过程要拆分现有数据库，进而涉及到数据迁移。

数据迁移过程我们要注意哪些关键点呢？第一，保证迁移后数据准确不丢失，即每条记录准确而且不丢失记录；第二，不影响用户体验（尤其是访问量高的C端业务需要不停机平滑迁移）；第三，保证迁移后的性能和稳定性。

数据迁移我们经常遇到的两个场景：

1，业务重要程度一般或者是内部系统，数据结构不变，这种场景下可以采用挂从库，数据同步完找个访问低谷时间段，停止服务，然后将从库切成主库，再启动服务。简单省时，不过需要停服避免切主库过程数据丢失

2，重要业务，并发高，数据结构改变。这种场景一般需要不停机平滑迁移。下面就重点介绍这部分经历。

互联网行业，很多业务访问量很大，即便凌晨低谷时间，仍然有相当的访问量，为了不影响用户体验，很多公司对这些业务会采用不停机平滑迁移的方式。因为对老数据迁移的同时，线上还不断有用户访问，不断有数据产生，不断有数据更新，所以我们不但要考虑老数据迁移的问题，还要考虑数据更新和产生新数据的问题。下面介绍一下我们之前的做法。

关键步骤如下：

1. 开启双写，新老库同时写入（涉及到代码改动）。注意：任何对数据库的增删改都要双写；对于更新操作，如果新库没有相关记录，先从老库查出记录更新后写入数据库；为了保证写入性能，老库写完后，可以采用消息队列异步写入新库。同时写两个库，不在一个本地事务，有可能出现数据不一致的情况，这样就需要一定的补偿机制来保证两个库数据最终一致。下一篇文章会分享最终一致性解决方案
2. 将某时间戳之前的老数据迁移到新库（需要脚本程序做老数据迁移，因为数据结构变化比较大的话，从数据库层面做数据迁移就很困难了），注意：1，时间戳一定要选择开启双写后的时间点，避免部分老数据被漏掉；2，迁移过程遇到记录冲突直接忽略（因为第一步有更新操作，直接把记录拉到了新库）；迁移过程一定要记录日志，尤其是错误日志
3. 第二步完成后，我们还需要通过脚本程序检验数据，看新库数据是否准确以及有没有漏掉的数据
4. 数据校验没问题后，开启双读，起初新库给少部分流量，新老两库同时读取，由于时间延时问题，新老库数据可能有些不一致，所以新库读不到需要再读一遍老库。逐步将读流量切到新库，相当于灰度上线的过程。遇到问题可以及时把流量切回老库
5. 读流量全部切到新库后，关闭老库写入（可以在代码里加上可热配开关），只写新库
6. 迁移完成，后续可以去掉双写双读相关无用代码。

第二步的老数据迁移脚本程序和第三步的检验程序可以工具化，以后再做类似的数据迁移可以复用。

目前各云服务平台也提供数据迁移解决方案，大家有兴趣也可以了解一下！