阅读了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更多的功能特性，对于开发人员也更友好。
