随着网站的发展，原有的2个数据库，访问的用户通过取模的方式均衡到两个库中，不过现在已经支撑不住数据量了，我们需要更坏数据结构或者新增数据库实例，那么我们是怎么来做数据迁移的呢？
这里我们分享两种方式:
(1)停机方案
1、我们先在网站的首页来出一个公告：我们准备进行升级，大概需要XX小时之类的停止服务的公告。
2、写一个迁移的程序，将原来2个数据库的数据拆分到4个数据库（2+2）
3.数据迁移完成，将连接数据库的配置修改
4.重启服务，重新对外开启服务。
这其实不是今天的重点，但是这种方法在很多企业是用的比较平凡的，我们自己就是这么做的，相对于还是比较简单的，但是也有弊端，需要停服，用户感知不好。而且需要在规定的时间内，我们大多数是在夜里，对同学的们身心考验还是比较大的（以前公司都是每周一次升级都是在夜里，回到家的时候都是早晨了），因为时间越短，出错的可能性就越高。
（2）平滑、秒级、不停服
我们以前用过双写的方案：
数据迁移前，上游业务应用通过旧的服务访问旧的数据。
步骤1：服务（service-old->service-new）进行升级，对旧库上的数据修改，在新库上同样进行修改，包括 insert、delete、update，这就是"双写"
步骤二：研发一个数据迁移工具，把就数据库里的数据迁移到新的数据库。这个过程还是旧库对线上对接服务，可以限速慢慢迁移，技术同学压力不是很大。迁移完成之后，理论上就可以切换到新库上对外服务了。不过在切库之前，我们需要判断数据的一致性，对数据进行校验。
步骤三：当数据完全一致后，将流量切到新库，完成了平滑数据迁移。
总结一下：
（1）服务进行升级，“对旧库上的数据修改”进行新库的重复写，也就是所谓的“双写”；
（2）研发一个数据迁移小工具（需要深思），进行数据迁移；
（3）研发一个数据比对小工具(需要琢磨)，校验数据一致性（考虑下while(1)持续比较）；
（4）流量切到新库，完成平滑迁移；
◤好像今天一个图都没有，显得很单调！◥
下集预告：双倍扩容如何做？停服和不停服