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的正则表达式方法路由，对于开发人员是有要求的，即必须遵从方法名规范。

错误检测 TinyDBCluster只要是检测到数据库有错误，在进行负载的时候，会把失效的去掉。保证只要有可用的，就不会出现访问错误。 
routing4db中没有看到相关处理逻辑。

读写分离差异   
数据同步 数据库同步，TinyDBCluster支持框架同步和数据库同步两种模式，当然框架同步是以降低数据库处理能力来达到的，适合于写少读多的场景。 
routing4db只支持数据库同步模式。 
路由算法 TinyDBCluster的路由规则是如果事务及或写指令则在写库进行，如果是无事务读指令则在读库进行。虽然加重了写库的负担，但是可以保证数据逻辑是永远正确的。 
routing4db则是读指令在读库，写指令在写库。如果采用数据库同步的方案中，同步是有延迟的，此时可能有逻辑错误。 
路由权重 TinyDBCluster支持设定不同的权限，从而根据机器配置情况调整负载能力。 
routing4db只是简单平均分配，机器配置情况相同的情况也没有问题，如果机器配置不同的情况下，会出现别的处理能力有盈余，而有的处理能力则不足的情况。

路由策略 TinyDBCluster和routing4db都是接口，因此都可以进行自定义扩展。

分表方面 两者都支持分表处理，都支持事务一致性。不同之处在于  TinyDBCluster内部集成JTOM实现事务一致，routing4db采用Spring实现事务一致。但是最终的目标是一致的。

集群部署方面 routing4db支持的部署方式，TinyDBCluster都支持。

TinyDBCluster支持分区和分表混用的方式。即读写分离及数据表水平扩展方面混合使用。 
routing4db中没有看到类似样例，不确定是否支持。 
总结 routing4db是国人实现的数据库读写分离及水平分表方面的一个良好实践，TinyDBCluster在实现过程中，对于routing4db支持的部署方式等方面进行了参考，学习到了相当多的内容，另外作者的代实现也表现了相当高的水准，值得大家学习与研究。 
TinyDBCluster有一定的后发优势，另外由于在实现层次上的差异，确实提供了比routing4db更多的功能特性，对于开发人员也更友好。