分库分表，读写分离数据库中间件选型调研

      之前由于项目和工作上对数据库的压力比较小，没有涉及到数据库的分库分表，读写分离等减轻数据库压力的操作，今天由于新的客户要开通mysql数据库支持的要求（之前的项目是oracle不存在数据量超标等情况）考虑到稳定性，安全性，和数据库响应等方面，考虑做mysql的读写分离，分库分表操作，于是开始选择相应的数据库中间件（之前没有用到）。。。

与是开始各种查阅资料，了解到目前比较主流的一些数据库中间件（只列几个有特色的哈）

首先目前分库分表有两种思想：

1.类似 Sharding-JDBC 及 TDDL 的增强版 JDBC 驱动思想

2.类似 Mycat 增加中间层，然后在中间层进行分库分表思想

相关中间件介绍：

1.Cobar：阿里巴巴B2B开发的关系型分布式系统，管理将近3000个MySQL实例。 后面因cobar没有人维护 了，阿里也开发了tddl替代cobar

2.MyCAT（这也是在中间件中很有代表性的）：社区爱好者在阿里cobar基础上进行二次开发，解决了cobar当时存 在的一些问题，并且加入了许多新的功能在其中。目前MyCAT社区活 跃度很高，目前已经有一些公司在使用MyCAT。总体来说支持度比 较高，也会一直维护下去，但是听说一直在准备2.x版本，git上很久没有更新过了，看了官网，和其中的关于我们，总感觉有点不靠谱。

3.MySQL Route：是现在MySQL 官方Oracle公司发布出来的一个中间件，但是选型的时候这个第一个被pass了（好像是不支持分库分表仅支持读写分离）

4.sharding-jdbc（现在更名为sharding-sphere）：这个中间件前面说了是基于jdbc层面提供额外服务的，优点缺点并存，优点是轻量，毕竟它定位为轻量级Java框架，以jar包形式提供服务，类似于淘宝的tddl，开发量少，它使用客户端直连数据库，性能理论上较高，可理解为增强版的JDBC驱动，据了解这个是由当当网开发的中间件慢慢转化过来的，16年开源，后面慢慢的一直在迭代，并捐献给了apache，现在已经入住京东，有专门的团队负责，好像还进入apache的基金孵化项目了。（目前只支持java）

总的来说还是分成上面说的两类，阐述一下优缺点：

JDBC 驱动版的优点：

1、轻量，范围更加容易界定，只是 JDBC 增强，不包括 HA、事务以及数据库元数据管理

2、开发的工作量较小，无需关注 nio，各个数据库协议等

3、运维无需改动，无需关注中间件本身的 HA

4、性能高，JDBC 直连数据库，无需二次转发

5、可支持各种基于 JDBC 协议的数据库，如：MySQL，Oralce，SQLServer

Proxy 版的优点：

1、可以负责更多的内容，将数据迁移，分布式事务等纳入 Proxy 的范畴

2、更有效的管理数据库的连接

3、整合大数据思路，将 OLTP 和 OLAP 分离处理

因此两种方式互相可以互补，建议使用 Java 的团队，且仅 OLTP 的互联网前端操作。有可能会使用多种数据库的情况，可以选择 JDBC层的中间件；如果需要 OLAP 和 OLTP 混合，加以重量级的操作，如数据迁移，分布式事务等，可以考虑 Proxy 层的中间件。