1.引言
笔者最近在做一个互联网的“类SNS”应用,应用中用户数量巨大(约4000万)左右,因此,简单的使用传统单一数据库存储肯定是不行的。 参考了业内广泛使用的分库分表,以及使用DAL数据访问层等的做法,笔者决定使用一种最简单的数据源路由选择方式来解决问题。 严格的说,目前的实现不能算是一个解决方案,只能是一种思路的简易实现,笔者也仅花了2天时间来完成(其中1.5天是在看资料和Spring/ibatis的源码)。这里也只是为各位看官提供一个思路参考,顺便给自己留个笔记 2.系统的设计前提 我们的系统使用了16个数据库实例(目前分布在2台物理机器上,后期将根据系统负荷的增加,逐步移库到16台物理机器上)。16个库是根据用户的UserID进行简单的hash分配。这里值得一说的是,我们既然做了这样的横向切分设计,就已经考虑了系统需求的特性,
在系统中,我们使用Spring和iBatis。Spring负责数据库的事务管理AOP,以及Bean间的IOC。选择iBatis的最大原因是对Sql的性能优化,以及后期如果有分表要求的时,可以很容易实现对sql表名替换。 3.设计思路 首先,要说明一下笔者的思路,其实很简单,即“在每次数据库操作前,确定当前要选择的数据库对象”而后就如同访问单库一样的访问当前选中的数据库即可。 其次,要在每次DB访问前选择数据库,需要明确几个问题,1.iBatis在什么时候从DataSource中取得具体的数据库Connection的,2.对取得的Connection,iBatis是否进行缓存,因为在多库情况下Connection被缓存就意味着无法及时改变数据库链接选择。3.由于我们使用了Spring来管理DB事务,因此必须搞清Spring对DB Connction的开关拦截过程是否会影响多DataSource的情况。 幸运的是,研究源码的结果发现,iBatis和Spring都是通过标准的DataSource接口来控制 Connection的,这就为我们省去了很多的麻烦,只需要实现一个能够支持多个数据库的DataSource,就能达到我们的目标。 4.代码与实现 多数据库的DataSource实现:MultiDataSource.class
这个类实现了DataSource的标准接口,而最核心的部分是getConnection()方法的重载。下面具体阐述:
(PS:关于DataSource的路由选择规则,可以根据应用场景的不同,自行设计。笔者这里提供两种简单的思路,1.根据HashCode,在上述例子中可以是UserId,进行取模运算,来定位数据库。2.根据上下文设置的关键字key,从map中选择映射的DataSource) 5.将MultiDataSource与Spring,iBatis结合 在完成了上述的编码过程后,就是将这个MultiDataSource与现有Spring和iBatis结合起来配置。 STEP 1。配置多个数据源 笔者这里使用了C3P0作为数据库连接池,这一步和标准的Spring配置一样,唯一不同的是,以前只配置一个,现在要配置多个
STEP 2。将多个数据源都注入到MultiDataSource中
STEP 3。像使用标准的DataSource一样,使用MultiDataSource
至此,我们的程序就可以让Spring来管理多库访问了,但请注意,数据库事务仍然限于单库范围(之前已经说过,这里的应用场景不存在跨库的事务)。 6.Java代码使用例子 首先要说明的是,这里我们只是提供了一个简单的使用范例,在范例中,我们还必须手动的调用API,以确定DataSource的路由规则,在实际的应用中,您可以针对自己的业务特点,对此进行封装,以实现相对透明的路由选择
OK,我们的多库横向切分的实验可以暂告一个段落。实际上,要实现一个完整的DAL是非常庞大的工程,而对我们推动巨大的,可能只是很小的一个部分,到处都存在着8-2法则,要如何选择,就看各位看官了!!
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
| |
返回顶楼 | |
对DataSourceRouter里面的东西比较感兴趣,不知能否贴点出来看看?
| |
返回顶楼 | |
SNS里大部分信息都是面向文档的而不是面向数据的,事务要求又不严格,用MongoDB来解决才是王道。
| |
返回顶楼 | |
ray_linn 写道
SNS里大部分信息都是面向文档的而不是面向数据的,事务要求又不严格,用MongoDB来解决才是王道。
MongoDB怎么用?一个user一个collection?MongoDB允许的最多那几万个Collection个数根本就不够。 都说ibatis是做大系统的,根本就不是,连原生的水平垂直切分数据库都不支持,这么多年还是那样,放弃它吧! | |
返回顶楼 | |
myreligion 写道
ray_linn 写道
SNS里大部分信息都是面向文档的而不是面向数据的,事务要求又不严格,用MongoDB来解决才是王道。
MongoDB怎么用?一个user一个collection?MongoDB允许的最多那几万个Collection个数根本就不够。 都说ibatis是做大系统的,根本就不是,连原生的水平垂直切分数据库都不支持,这么多年还是那样,放弃它吧! 每个user怎么也只是一份document而不是一个collection。如果需要切分,可以每数万个user放入一个collection中。这种问题只需要做个规划就成: 每100个id 存在一个collection里,名字叫 user100,user200,user300....(假设100是个很大的数) 每500个collection 存在一个db中,名字叫 db50000,db100000...... 现在只要有id,比如说701,我们可以推测出,这个id存放在user800 collection中,db应该是db50000。这个算法很简单吧。 object: { $ref: "user800", $id: ObjectID("701"),$db: "db50000" } 搞定。 | |
返回顶楼 | |
你是为了解决Master-Slave问题,还是多个数据库群组之前的选择?
| |
返回顶楼 | |
downpour 写道
你是为了解决Master-Slave问题,还是多个数据库群组之前的选择?
为多数据库的横向切分,提供一个思路 | |
返回顶楼 | |
numen_wlm 写道
对DataSourceRouter里面的东西比较感兴趣,不知能否贴点出来看看?
其实没啥看头的,呵呵
| |
返回顶楼 | |
感谢楼主分享,这是这几天看过的最好的文章了,支持下!
| |
返回顶楼 | |
我也做了1个数据库(spring+ibatis)水平切分的功能,原理跟楼主差不多,不过我们会有一些跨库的查询。
建议楼主不要直接根据用户id去关联数据库,这样写的太死,比如以后数据量大,数据库有16个变成32个,需要把以前的用户再平均分配到其他数据库的时候就比较麻烦。 我们是直接在用户表记录1个dbid,记录当前用户在哪个库,这样有1个好处就是用户的数据非常方便进行迁移,迁移到其他数据库只足要该下他的dbid就行。 个人浅见,^_^ |
Spring + iBatis 的多库横向切分简易解决思路
最新推荐文章于 2023-06-20 11:17:29 发布