在我们的日常工作中，因为各种各样的原因，比如机器裁撤、业务重构等都会遇到数据迁移的情况，下面就谈谈数据迁移的几种常见方法。
介绍方法之前，我们先来谈谈数据迁移的几个原则：
- 数据不能丢，不能错。数据的准确性、一致性、完整性是最基础的东西。
- 服务尽可能不中断，
- 数据迁移过程可以重入重迁。
1. 停机维护
停机维护指的是，选择一个时间（比如凌晨3、4点钟，这个时间用户量最小）对外挂出停服维护的公告，然后停止服务，留出一整段时间来进行数据迁移，当数据迁移完毕并且校验通过后，再将存储切换到新的存储系统上，然后开始提供服务。在整个数据迁移的过程中，服务都是停止的。该方式简单，不会带来额外的问题，但是却很少被使用，另外停机前也得做一系列的准备工作。
2. 主备备模式
这种方式适用于Master-Slave结构的存储系统，比如Mysql与Redis等。当主机需要被裁撤的时候，拿出一台新机器，将其挂载为备机的备机。当主机-备机-备机的备机的同步延迟为0的时候，将主的读写都切到备机上面，这样裁撤过程就完成了。
3. 双写-双读模式
双写就是在原有写旧存储系统的基础上，增加对新系统的同步或者异步写，保证增量数据可以在新系统中存在。双读就是既读取新系统又读取旧系统，双读分两种方式，其一就是读取旧系统，然后读取新系统，判断新系统没有就异步写入，返回返回旧系统的数据；其二是读取新系统，读取到了就返回，读取失败就读取旧系统，异步写入新系统，然后返回旧系统数据。除此之外，还得准备工具进行存量数据的主动迁移，这个可以开多机多进程来加速，我用单进程跑1000W数据，大概需要3天的时间（涉及4次redis的读写，无数据库操作）。
一些建议
- 整个过程需要加上详细的监控，知道迁移率，让整个过程尽在掌握
- 对迁移的数据可以打标，只要是打标的数据都可以引导到新系统中进行查询。
- 对存储的设计需要有些前瞻性，起码能保证两年不会做数据迁移的工作。
一个例子
我们有若干个redis集群，其中一个是运行时缓存，另外一个是账户缓存。因为历史原因账户信息存入了运行时缓存中，现在需要迁移到账户缓存中。方法1肯定是不能被采纳的，方法2挺简单，不过运行时缓存中远不止账户信息，同步完后再大批量删除不要的Key也是比较废的一个操作。所以我们选择了第三种方法，如下图所示：
