routing4db的作者是@CodeFurtur,主页详见:
https://code.google.com/p/routing4db/ 阅读了routing4db的源码,当然理解上与作者还是有差距的,如果有错误之处,欢迎指正。
底层实现差异 实现层次 TinyDBCluster选择在Jdbc Driver层实现,因此不依赖各种Spring等框架;routing4db选择在应用层解决,对datasource进行封装,因此,需要依赖Spring框架。
TinyDBCluster对于开发人员来说,可以做到完全透明;在特殊场景下routing4db,则需要开发人员遵守一定要求。
适用场景 TinyDBCluster可以适应于任何应用场景,甚至可以用第三方工具只要指定驱动driver,就可以使用。
routing4db只适应于上层应用,第三方工具无法使用。
第三方框架支持 TinyDBCluster支持所有第三方框架。
routing4db对于Mybatis等基于工厂方式创建DAO的方式,需要进行增强。
路由处理
TinyDBCluster采用SQL解析方式进行路由,routing4db采用正则表达式进行方法路由;当然,相对来说SQL解析方式效率比正则要慢一些的,但是由于TinyDBCluster内部采用了缓冲方式,同样的SQL语句不会解析第二次,因此效率也不会存在问题。
routing4db的正则表达式方法路由,对于开发人员是有要求的,即必须遵从方法名规范。
1 2 3 4 5 6 | <property name="readMethodPatterns"> <list> <value>*get*</value> <value>*find*</value> </list> < /property>
|
错误检测 TinyDBCluster只要是检测到数据库有错误,在进行负载的时候,会把失效的去掉。保证只要有可用的,就不会出现访问错误。
routing4db中没有看到相关处理逻辑。
读写分离差异
数据同步 数据库同步,TinyDBCluster支持框架同步和数据库同步两种模式,当然框架同步是以降低数据库处理能力来达到的,适合于写少读多的场景。
routing4db只支持数据库同步模式。
路由算法 TinyDBCluster的路由规则是如果事务及或写指令则在写库进行,如果是无事务读指令则在读库进行。虽然加重了写库的负担,但是可以保证数据逻辑是永远正确的。
routing4db则是读指令在读库,写指令在写库。如果采用数据库同步的方案中,同步是有延迟的,此时可能有逻辑错误。
路由权重 TinyDBCluster支持设定不同的权限,从而根据机器配置情况调整负载能力。
routing4db只是简单平均分配,机器配置情况相同的情况也没有问题,如果机器配置不同的情况下,会出现别的处理能力有盈余,而有的处理能力则不足的情况。
路由策略 TinyDBCluster和routing4db都是接口,因此都可以进行自定义扩展。
分表方面 两者都支持分表处理,都支持事务一致性。不同之处在于TinyDBCluster内部集成JTOM实现事务一致,routing4db采用Spring实现事务一致。但是最终的目标是一致的。
集群部署方面 routing4db支持的部署方式,TinyDBCluster都支持。
TinyDBCluster支持分区和分表混用的方式。即读写分离及数据表水平扩展方面混合使用。
routing4db中没有看到类似样例,不确定是否支持。
总结 routing4db是国人实现的数据库读写分离及水平分表方面的一个良好实践,TinyDBCluster在实现过程中,对于routing4db支持的部署方式等方面进行了参考,学习到了相当多的内容,另外作者的代实现也表现了相当高的水准,值得大家学习与研究。
TinyDBCluster有一定的后发优势,另外由于在实现层次上的差异,确实提供了比routing4db更多的功能特性,对于开发人员也更友好。