分库分表中间件技术选型总结

之前工作做了下分库分表的技术选型，对现有的中间件进行了一番总结。

最开始想用mycat的，毕竟名气大，但查阅了文档和结构，发现下面的分库分表面对的3个问题无法解决。

最后选择使用sharding-jdbc，在jdbc层面做库表关联，更底层些。年后该框架作者去了京东，有单独的团队维护。

分库分表面对的3个问题：

    1.事务一致性：比如更新10张表，最后一张失败，怎样保证事务。

    2.字典表问题：一般字典表维护在一个库中，分库查询的话影响效率，每个库都存储一份字典表的话，上表面提到的事务一致性问题又会出现。库之间也会过于冗余。

    3.分页查询：比如查询100到110之间的数据，做法可不是每个库取100~110间的数据，再去前10条，而是每个库查询0~110间的数据，比如10个库，就会返回 10 * 110条数据，再从这里取100~110间的数据。这里的问题就是如果是 500000~500010的话，返回的数据量就太大了。

Atlas：不能实现分布式分表，所有的子表必须在同一台DB的同一个database里且所有的子表必须事先建好，Atlas没有自动建表的功能。Atlas参考链接
Cobar：必须将拆分后的表分别放入不同的库来实现分布式。Cobar参考链接
TDDL：阿里，功能强大，过于复杂，部分开源。需要评估使用情况，防止过剩。
Mycat ：国内开源，从入门到放弃。mycat参考链接
heisenberg：百度开源，相对简单，易于管理。heisenberg参考链接
Oceanus：功能强大，开源，简化开发和配置成功。但产品还不成熟。
vitess：google产品，集群基于ZooKeeper管理，通过RPC方式进行数据处理，可支撑高流量，它还添加了一个连接池，具有基于行的高速缓存，重写SQL查询，更安全。vitess参考链接
OneProxy：中国厂商产品，稳定性待确认。OneProxy参考链接
Sharding-JDBC：当当最新开源，jdbc层面操作。Sharding-JDBC参考链接

选型考虑3点：

    1.产品功能和可扩展性：mycat就是不行。就是名气大，已经到头了。Cobar也是可扩展性的问题放弃的

    2.产品是否成熟，或者说可用，比如国内的一般就不考虑了，稳定性是个问题。百度的heisenberg其实不错，但是代码很久没有维护了，社区也不积极，就放弃了。google的vitess也可以 ，但是海外的产品，也放弃了。

    3.实际情况：我们公司是腾讯系的，阿里的TDDL显然不能用了。

响应的细节就不贴了，参考链接都有。