背景
一般来说，单mysql的写入瓶颈在3000-5000条每秒，读qps在3w-10w。单表的存储极限在2000w条，全库的极限在4-5亿条。
我们在构建一个新业务时，会评估这个业务的总体数据量，读写高峰请求量等等。大多数时候，对于to B业务，单库单表策略，是可以满足需求的；对于to C业务，单库分表策略一般也足够了。
用数据库去抗特别大的用户流量，往往都不是一个好的设计，一般都是通过增加redis/memcache/localCache的缓存层来解决。
但对于一些比较特殊的业务，比如涉及到金钱的，对一致性要求特别高的业务，如果这个时候使用缓存的策略，就非常容易产生不一致的问题，虽然也有一些办法可以解决，但复杂性比较高，而且往往会有一些意想不到的坑。这种时候，使用数据库直接去抗用户请求，看起来很“笨拙”，可也许是性价比最高的做法。

我们最近的一个业务，就有这种一致性的要求，而且是to C的业务，在第一期实现的时候，使用了单库分表的策略，运行良好。但随着业务量不断增大，单库压力越来越大，在一次活动时，库被打满，造成服务出现10分钟左右的不可用。后来短期的解决方案是在接口层增加限流，超过限流时，牺牲一定的用户体验。
长期的解决方案，就是拆库，把原来的一个库，拆分成10个或者更多个库。

难点
1 服务不可停，用户无感知。就好比给行进中的公交车换轮子一样。
2 数据必须强一致，不能出现数据错误的情况。
3 方案必须可回滚，在出现问题时，必须回滚，让风险可控。

拆库前置条件
这里需要说明一下拆库的前置条件：
1 程序对数据库的访问必须经由zoomkeeper，如果是通过代码写死ip:port的方式访问db，必须先改成可动态配置的模式。
2 必须已完成分表，一般这种to C业务的表，都把userId作为分库分表的shardId。举个例子，在单库100个分表的情况下，用userId对100取模，比如userId=1的，在table_1 (1 % 100)中，userId=1003的，在table_3 (1003 % 100)中。这个时候，将单库拆成10个库时，依旧使用userId对库分组，比如userId=1的，在 database_1 (1 % 10)中的table_1中，userId=1003的，在database_3 (1003 % 10) 的table_3中。

拆库流程
当时一共设计了3个方案，最终使用了第3个方案，整个拆库的过程很成功，这里贴一下大概的流程。
1 向dba申请10个新的库，并基于dba的工具完成3张表的数据同步
(数据同步一般是这样做的，首先把10个新库都作为老库的备库，通过mysql的binlog及snapshot机制，自动完成数据的同步)
2 新库数据及读验证
(可以通过一个离线的脚本简单验证一下，由于这是mysql的同步机制，所以准确性及可靠性非常高。只验证读是正常的，保证配置正常就可以，注意：不能验证写，写会导致新老库数据不一致)
3 切换使用binlog的服务源
(对于使用binlog的一些服务，这个时候需要切换到新库的binlog配置)
4 增加一个新的dataSource，先让它指向老库
(这里解释一下，原来的库A的dataSourceA配置在zk中，程序中访问库的代码都通过dataSourceA完成。这个时候，新配置一个dataSourceB，让dataSourceB的配置和dataSourceA一致)
5 修改DAO层代码，将使用dataSourceA的地方统一改成dataSourceB
(正常的编码规范，对数据库的操作都会放在DAO层，因此改动是非常收敛的，如果发现需要改的地方非常多，一定是代码写的太随意)
6 上线所有访问库的服务
(这个上线过程也需要灰度上线，一旦发现问题，很可能是配置问题，需要立刻回滚)
7 将dataSourceB的zk配置切成新的库
(这是最核心的一步，通过zk的观察者模式，自动将新的配置通知到所有客户端，有一定的风险性，最好在流量低峰期进行。同时要看着监控，一旦出现问题，立刻把配置刷回来)
8 关闭新老库的数据同步
(把新库从老库的备库列表摘除就可以)
9 删除老库中的表