迁移数据是一个比较常见的操作，在很多情况下，我们都需要将数据从一个位置迁移到另一个位置，以满足一些需求，比如获得更大的存储容量，或者将压力均衡分布到多个节点。举例来说，下面这些场景都需要迁移数据：
- 将数据从单个数据库迁移到多个数据库中，以提升存储容量
- 将数据从关系型数据库迁移到NoSQL数据库中，使之更适合业务场景
- 在分布式数据库内部，比如hbase，当节点数目发生变化时，也需要将数据进行迁移，使集群负载均衡
这里主要的难点在于，如何在迁移数据的过程中，保证上层服务仍然可以读取到数据。
对于上面第三个场景，很多分布式数据库已经能够自动处理，即迁移数据以达到负载均衡，并且在这个过程中能够做到不影响正常读写请求的处理。
在讨论具体的方案之前，我们先明确一下几个细节：
- 需求是将数据从一个位置迁移到另一个位置
- 在迁移过程中可以处理读写请求
- 读写数据的请求具体包括read、write、update这三种
基于这些假设，可以抽象出几个参与数据迁移的模块，包括：
- 之前的数据库，存放着当前所有数据，这个数据库记为old_db
- 新的数据库，数据将会从old_db迁移到此处，这个数据库记为new_db
- 请求路由层，路由层告诉应用程序，应该将读写请求发送到哪个数据库，路由层记为router
下面描述几种可行的方案。
同步+双写
这种方案的核心思想是保证稳定性，即如果迁移过程或者迁移后出现了问题，那么仍然可以回滚到之前的架构，数据不会丢失或者出错。它的大致过程是这样：将数据从old_db拷贝到new_db，保证两个数据库中的数据是一致的，然后每次进行write和update时，同时write/update两个数据库中的数据，等到new_db稳定后，再将old_db下线。
具体的实施会比较复杂，在数据量和请求量都很大的情况下，这个过程也比较长，中间需要使用到一个临时数据库，这里记为temp_db，详细的执行步骤如下：
- 准备好new_db，temp_db
- 选择一个时间点，获取这个时间点old_db的快照。取快照是一个很快的操作（需要数据库支持快照功能）。这个过程需要短暂的停止向数据库写入和更新数据，在快照取完后，更新router的策略，将每次更新操作同时写到两个位置，一个是old_db，一个是temp_db。
- 将快照数据导入到new_db中
- 快照数据导入完成后，开始将temp_db中记录的操作应用到new_db中。这需要额外开发一个程序来完成这个工作，这个程序会持续运行，消费temp_db中记录的操作。
- 在上面两步执行的过程中，应用程序还在继续发起读写请求，因此会不停的有更新操作写入到temp_db中。
- 等到某个时刻，temp_db中记录的操作被清零，即全部应用到了new_db，同时还没有新的更新操作进来。此时切换router的逻辑，开始双写，每一次更新操作同时写入old_db和new_db。（temp_db可以销毁了）。
- 观察双写情况下，new_db和old_db的数据是否完全一致，这里也需要额外开发一个比对的程序。
- 等待一段数据，如果new_db和old_db的数据没有出现不一致，则可以切换router的逻辑，将所有读写请求发送到new_db。
实施这个方案，需要一次短暂的停止写入，这个时间取决于获取old_db快照所需要的时间，大多数数据库的快照实现都是非常高效的（取快照的实现本质上就是计一个时间戳，然后使用类似copy on write的机制来处理后续的更新）。
此外，还需要两个额外的程序：
- 一个用来将temp_db中记录的更新操作应用到new_db中
- 一个用来比对new_db和old_db中的数据
router也需要增加几个逻辑： - 同时写old_db和temp_db
- 同时写old_db和new_db
- 写new_db
同步+双写的方案最大的优势是：整个过程中，任何一步如果有问题都可以随时停止，对历史数据没有任何影响。这个过程比较复杂，需要额外的开发，在实施的过程也需要人工参与。
redis的主从同步过程和这个方案有点相似，使用了快照+temp_buffer来同步历史数据。
渐进式+后台迁移
渐进式的迁移数据是比较简单的方式。具体如下：
- 准备new_db
- 更新router的策略，对于read操作：先从new_db中读，如果没有的话再去old_db中读，如果从old_db中读到了数据，则将数据写入到new_db中。对于update操作：使用类似的逻辑，如果在old_db中有数据，而new_db中没有，则将数据迁到new_db中，再进行update。对于write操作：写入到new_db，然后将old_db中的数据删除。（这些逻辑可能不太适合在router这一层实现，而是需要在应用程序中实现）
- 等到old_db中的数据全部迁移完成，更新router的策略，改为直接读写new_db。
这个迁移的过程完全依赖于应用程序对数据的访问，如果存在一部分数据长时间没有被访问，那么这些数据也就没有机会被迁移到new_db。因此这种渐进式的迁移一般都需要搭配一个后台迁移程序，这个迁移程序会主动的将数据从old_db迁移到new_db。
很明显，这种方案不能像双写方案那样随时回滚到old_db，因为数据只会存在一份，要么在new_db，要么在old_db，一旦从old_db迁移到new_db，就没有方法迁移回来了（当然可以开发一个反向迁移的工具，但是大多数时候并没有这个必要）。
总结
数据迁移虽然没有特别复杂的难以理解的地方，但是在实际工作，这是一个很重要的事情，因为数据非常重要，大多数应用程序都是在围绕数据进行一些逻辑处理，数据本身一旦出问题，整个应用也就会跟着出问题，而且是比较严重的问题。此外，实际的业务系统中，对数据的读写模式往往不仅仅是read、write、update这么简单，可能会包括一些其他的操作，比如scan读取，事务操作等，迁移的过程还需要额外的考虑这些操作。因此，实际工作中进行数据迁移是一件很耗时耗力的事情，需要定制精确的执行步骤，做详尽的测试验证，实操时也需要格外谨慎。
