spring中有一个AbstractRoutingDataSource的抽象类可以很好的支持多数据源，我们只需要继续它即可。
很简单，就一个方法。其中DBContext的代码如下：
这里我模拟了一个分库的场景：假设一个应用允许用户注册，但是用户数量太多，全都放在一个数据库里，记录过多，会导致数据库性能瓶颈，比较容易想到的办法，把用户的数据分散到多个数据库中保存（注：可能马上有同学会说了，分开存了，要查询所有用户怎么办？这确实是分库带来的一个弊端，但也有相应的解决方案，本文先不讨论这个，以免跑题）。
假设我们有二个数据库，里面的表结构完全相同，有一张表T_USER用于保存用户数据，问题来了，如果有N个用户要注册，id分别是1、2、3...，服务端接到参数后，怎么知道把这些数据分别插入到这二个库中，必然要有一个规则 ，比较简单的办法就是取模，所以上面的getDBKeyByUserId就是干这个的。
然后是jdbc的属性配置文件：
接下来是spring的配置文件：
View Code
关键的是parentDataSource,dataSource1,dataSource2,dataSource这几个bean的配置，一看就懂。
服务端的核心代码：
注意：25，32行在调用mybatis操作数据库前，先根据需要切换到不同的数据库，然后再操作。
运行完成后，可以看下db_1,db_2这二个数据库，确认数据是否已经分散存储到每个库中：
如果不喜欢在代码里手动切换db，也可以用注解的方式自动切换，比如：我们又增加了一个db_main
然后在spring配置文件里，要做些调整：
注意：67-81行，主要是增加了一个单独的sqlSessionFactoryMain，然后将一个新的MapperScannerConfigurer关联到它。
新库里对应表的Mapper类可以这么写：
注解里name对应的值，必须与刚才spring文件里新增的MapperScannerConfigurer对应。
这样，服务层就可以省去手动切换的代码了，即：
上述二种方式可以共存在同一个项目中，个人建议：如果分库的表结构相同，且表数量较多，第1种手动切换的方式比较适合，这样mapper类不用重复建多个，如果分库的表结构完全不同，第2种比较合适，因为表结构不同，mapper肯定也不同，所以mapper多个是无法避免的，这时候就宁可加点配置，代码中就不用手动切换，可以省事点。