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

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

最开始想用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参考链接