Cobar--基于MySQL的分布式数据库服务中间件

　　Cobar为阿里巴巴研发的关系型数据的分布式处理系统，是提供关系型数据库(MySQL)分布式服务的中间件，该产品成功地替代了原先基于Oracle的数据存储方案，它可以让传统的数据库得到良好的线性扩展，并且看上去还是一个数据库,对应用可以保持透明。

• 　　产品在阿里巴巴稳定运行3年以上。
• 　　接管了3000+个MySQL数据库的schema。
• 　　集群日处理在线SQL请求50亿次以上。
• 　　集群日处理在线数据流量TB级别以上。

　　一、Cobar的核心功能

    如图1所示：

　　1.分布式：

　　Cobar的分布式主要是通过将表放入不同的库来实现：

• 　　Cobar支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分
• 　　Cobar也支持将不同的表放入不同的库

　　多数情况下，用户会将上面的两种方式混合使用

　　需要强调的是，Cobar不支持将一张表，比如test表拆分成test_1, test_2, test_3…..放在同一个库中，必须将拆分后的表分别放入不同的库来实现分布式。

　　2.HA：

　　在用户配置了MySQL心跳的情况下，Cobar可以自动向后端连接的MySQL发送心跳，并且判断MySQL运行状况，一旦运行出现异常，Cobar能够自动切换到备机工作。要强调的是：

• 　　Cobar的主备切换有两种触发方式，一种是用户手动触发，一种是Cobar的心跳语句检测到异常后自动触发。那么，当心跳检测到主机异常，切换到备机，如果主机恢复了，需要用户手动切回主机工作，Cobar不会在主机恢复时自动切换回主机，除非备机的心跳也返回异常。
• 　　Cobar只检查MySQL主备异常，不关心主备之间的数据同步，因此用户需要在使用Cobar之前在MySQL主备上配置双向同步，详情可以参阅MySQL参考手册。

　　二、Cobar的功能约束

1. 　　不支持跨库情况下的join、分页、排序、子查询操作。
2. 　　SET语句执行会被忽略，事务和字符集设置除外。
3. 　　分库情况下，insert语句必须包含拆分字段列名。
4. 　　分库情况下，update语句不能更新拆分字段的值。
5. 　　不支持SAVEPOINT操作。
6. 　　暂时只支持MySQL数据节点。
7. 　　使用JDBC时，不支持rewriteBatchedStatements=true参数设置(默认为false)。
8. 　　使用JDBC时，不支持useServerPrepStmts=true参数设置(默认为false)。
9. 　　使用JDBC时，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法设置参数。

　　三、Cobar逻辑层次图

　　如图2所示：

• 　　dataSource：数据源，表示一个具体的数据库连接，与物理存在的数据库schema一一对应。
• 　　dataNode：数据节点，由主、备数据源，数据源的HA以及连接池共同组成，可以将一个dataNode理解为一个分库。
• 　　table：表，包括拆分表(如tb1，tb2)和非拆分表。
• 　　tableRule：路由规则，用于判断SQL语句被路由到具体哪些datanode执行。
• 　　schema：cobar可以定义包含拆分表的schema(如schema1)，也可以定义无拆分表的schema(如schema2)。

　　Cobar支持的数据库结构(schema)的层次关系具有较强的灵活性，用户可以将表自由放置不同的datanode，也可将不同的datasource放置在同一MySQL实例上。在实际应用中，需要通过配置文件(schema.xml)来定义我们需要的数据库服务器与表的分布策略。

　　四、Cobar的实现原理

　　Cobar的前、后端模块都实现了MySQL协议;当接受到SQL请求时，会依次进行解释(SQL Parser)与路由(SQL Router)工作，然后使用SQL Executor去后端模块获取数据集(后端模块还负责心跳检测功能);如果数据集来自多个数据源，Cobar就需要把数据集进行组合(Result Merge)，最后返回响应。如图3所示

　　Cobar采用了主流的Reactor设计模式来处理请求，并且使用NIO进行底层的数据交换，这大大提升了系统的负载能力。其中，NIOAcceptor用于处理前端请求，NIOConnector则用于管理后端的连接，NIOProcessor用于管理多线程事件处理，NIOReactor则用于完成底层的事件驱动机制，就是看起来与Mina和Netty的网络模型比较相似。如图4所示