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

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

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

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

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

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

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

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

选型考虑3点：

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

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

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