最近作了一次数据迁移，由于不是分库或者分表，而是系统业务处理逻辑和结构的改变，须要将旧数据迁移并转换为新逻辑内的数据格式，还须要保证数据的一致性，而且服务器不能停机，即数据迁移，同步的过程是在工做时间段内完成。redis
这次数据迁移涉及到的业务系统，如下简称为旧业务和新业务。服务器
首先，迁移的过程是在生产时间内进行，因此迁移的过程不可以影响到用户的业务使用，同时也不能在数据迁移的过程当中被用户感知到，还须要考虑到，用户是实时产生新数据的，即你的旧数据是不断生成的，而你的新数据是不断的从旧数据迁移过来的，这个过程当中还须要作数据的格式以及逻辑的转换。分布式
因此能够明确这次迁移有几个要求：性能
数据迁移流程以下：测试
注明一下，在这次数据迁移过程当中，由于涉及到数据一致性要求极高，因此有步骤稍微作了修改。事务
数据迁移完成后，依然保持对旧业务的读写，而且监控一段时间保证数据的一致性。再次上新版本的时候再一次性将读写迁到新业务当中。同步
1.关于时间戳先后的判断监控
数据迁移使用的脚本，对时间戳以后的旧业务数据是不作迁移的，实现方法时须要注意几个点，以下：方法
a.条件是否已经达到最新的数据，这次根据的流水id时间戳
b.是否已经达到时间戳，时间戳后的数据不做处理
c.本次由于是多条数据合为一条，因此可能致使由于事务回滚致使的id缺失，从而使得获取数据size为0或者为null，从而使得在迁移中误判跳出。
因此根据业务的不一样，除开通用的判断注意点，还须要注意因业务问题而出现的误判现象，最好是上线运行前先作细致的业务迁移分析，再进行上线。
2.关于锁和记录的问题
线上项目运行的同时跑数据迁移，须要考虑到一个性能占用的问题，因此须要分批次处理，这里须要对检索的key作记录，又因此次业务的需求是多条数据合一条数据，多条数据又分几种状况，因此须要加锁，最后还须要对批次作一个记录。具体以下:
a.用id作key，因此用redis作记录
b.用redis记录跑的批数
c.用redis分布式锁来锁定多条数据的迁移，避免重复迁移致使数据不正确。
3.最后数据迁移完毕作核对
数据迁移完毕后，须要核对数据迁移是否正确，固然是须要如今测试环境上作过测试的，但也不能避免线上环境和数据的不一样可能存在的误差，因此不管如何迁移完毕后须要对数据进行校验，而且最好监控一段时间，验证新业务和旧业务的写入也一样没有问题。
以上，完。