数据库中间件cobar调研笔记

13年底负责数据库中间件设计时的调研笔记，拿出来和大家分享、轻拍。

一、cobar是什么

• 阿里开源的mysql的中间件服务
• 使用mysql协议
• 对上游，cobar就是传统mysql数据库
• 对上游，它屏蔽后端分布式mysql集群

画外音：数据库中间件有基于服务端的，也有基于客户端的，cobar属于前者。

二、cobar应用场景举例

逻辑上：

• 数据库dbtest(虚拟的)
• 表tb1和tb2

物理上：

• tb1表的数据在dbtest1(物理的)的tb1上
• tb2表的一部分数据在dbtest2(物理的)的tb2上，另外一部分在dbtest3(物理的)的tb2上

三、cobar使用方式

• 命令行：连dbtest虚拟库
• JDBC：也是连dbtest虚拟库

查看db：

可看到dbtest1、dbtest2、dbtest3对用户透明。

查看table：

可看到有tb1和tb2两张表。

插入一些数据，对用户而言，后端的分布式mysql是透明的：

• 对tb1，数据实际上存在dbtest1的tb1中
• 对tb2，数据实际上存储在dbtest2和dbtest3的tb2中

画外音：从其官网上看，自12年12月之后，cobar就没有再更新过，官方微博也非常不活跃，不清楚现在它在阿里的使用情况，知道的同学请说一说。

四、cobar不支持什么

• 不支持夸库join，分页，排序，子查询
• set语句会被忽略(事务和字符集设置除外)
• 如果分库，insert必须包含patition key(否则麻烦大了)
• 如果分库，patition key不能被update
• 不支持读写分离
• 不支持存储过程
• 如果使用JDBC，rewriteBatchedStatements，useServerPrepStmts，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()

五、cobar支持什么

1. 分布式数据库：通过分库实现

• 支持一张表放到不同的库
• 支持不同的表放入不同的库

需要注意：不支持将test拆分成test_1，test_2，test_3并放入同一个库中这样的拆分方式。

画外音：后者正是360的atals的做法(atlas只支持单实例单库分表)。

2. HA：通过到mysql的心跳实现

• 主机挂了会自动切换回备机，但主机恢复，需要手动切回
• 只检测主备异常，不关心主备数据同步(需要dba手动配)

画外音：需要注意，cobar是需要用户自己来实现负载均衡的，方式有三种：

• 自己使用软件例如LVS
• 自己使用硬件例如F5
• cobar提供了命令获取集群信息，用户可以根据这些信息做负载均衡;当然，淘宝已经实现了一个具有负载均衡功能的cobar客户端产品-cobar.driver

3. SQL路由

在分库的情况下，cobar会从sql中提取partition key列，来判断SQL被路由到哪一个分库进行执行;如果没有带partition key，则会将SQL分发到所有分库执行。

4. 示例

tb1(id INT)

假设以id切分数据，后端分了N个库：

insert into tb1 values(1); 
=> N个库都会执行插入，因为没有带partition key； 

insert into tb1(id) values(1); 
=> 只会路由到1个库，带了partition key; 

update tb1 set id=2 where id=1; 
=> 不支持，不能修改partition key； 

画外音：SQL带上partition key对cobar来说，非常非常重要，并且partition key不支持修改(修改了库就不对了哟)。

cobar不允许在同一个连接中切换库。

画外音：数据库连接和库是绑定关系。

不建议通过cobar来执行DDL语句。

画外音：所以建库，建索引什么的，还是直连mysql自己搞吧。

5. COBAR自定义语句

(1) 查询cobar节点的状态

cobar允许管理员通过管理命令上线和下线cobar节点。

(2) 查询cobar集群的状态

被定义在一个cobar集群中的cobar节点之间都会发送心跳，所谓的心跳就是上面提到的show cobra_status; 这样的话，就为每一个cobar节点提供了知道同一个集群内的所有cobar信息的机会。当然，被下线，或者心跳超时的cobar节点的信息不会被显示出来。

(3) 查询SQL语句的路由情况

SQL语句前加上explain即可知道SQL语句的路由情况。

6. 事务的支持

cobar对单库保持事务的强一致性。

对分库保持事务的弱一致性。

分库后事务提交包含两个阶段：

• 执行阶段：SQL按照规则被路由到多个分库，此时发生错误，还能回滚
• 提交阶段：提交阶段出错，无法正确回滚

两个阶段之间，执行与提交串行处理，阶段内部各个分库并行处理。

画外音：额，基本就是不支持分布式事务。

六、cobar系统架构

1. 系统模块图

画外音：从模块图来看，cobar的结构还是挺清晰的：

(1) 前端对上游的连接池

(2) 后端对下游mysql的连接池

(3) 对每一个请求，会经过：

• SQL分析
• SQL路由
• SQL执行
• 投递给后端mysql

(4) 对每一个响应，需要做结果合并

2. 数据流图

数据流图和上述模块图对应：

3. 网络模型

采用异步网络模型：

4. 结果合并

会把多个物理库的结果集合并，再返回给上游：

七、cobar路由算法

• partition key是int时：好办，直接取模
• partition key是string时：f(string) = hash(string) % 1024

假设分4个库：

• 哈希结果0-255 -> 库1
• 哈希结果256-511 -> 库2
• 哈希结果512-767 -> 库3
• 哈希结果768-1024 -> 库4

如何扩容：

• 哈希结果0-255 -> 库1

拆分后：

• 哈希结果0-127 -> 库1.1
• 哈希结果128-255 -> 库1.2

数据非均匀分布路由：

• 哈希结果0-511(513范围) -> 库1
• 哈希结果512-767(256范围) -> 库2
• 哈希结果768-895(128范围) -> 库3
• 哈希结果896-1023(128范围) -> 库4

八、cobar对于SQL的转发

1. 带partition key单记录查询

直接根据partition key路由。

2. 带partition key的IN查询

将IN进行拆分，请求发到对应多个分库，然后将结果集合并。

3. 不带partition key的where查询

假设partition key是user字段，在product字段上的where查询，会将请求广播到所有分库，然后将结果集合并。

4. 二维partition key

一张表的多个字段同时作为定位库的拆分字段，仍以上图的visit(product, user, info)为例，可以以product和user两个字段来同时来定位库。

横坐标product属性取hash，纵坐标user属性取hash。

 

SELECT * FROM visit WHERE product=‘ColaCola’ AND user=‘A’ 

对于上述业务需求，同时带有两个列作为查询条件，可以直接定位到库7。

但是，此时如果只有其中的一个字段作为查询条件，反而得查询多个库，再做聚合：

SELECT * FROM visit WHERE product=‘ColaCola’ 

对于上述业务需求，就必须查询库3，7，11，15了。

画外音：不懂为什么要按照双key来做路由，单key路由，对于双key的查询，也没有增加多少数据扫描量啊，加入双key反而使得某些情况下策略复杂了，带来的收益也不高。

5. 小结

对的，对于where，cobar就是这样的处理方式：

• 根据字段的一致性hash分布数据
• 多维拆分
• 根据where中的partition key分发查询
• SQL语句变换，分发至各个分库执行，对结果进行合并

九、cobar的高级特性

1. JOIN有限的处理

如上，两个表都进行了分库，JOIN需求如下：

SELECT * FROM tb1 INNER JOIN tb2 
    ON tb1.MEMBER_ID=tb2.NAME 

结果集理应如下：

方案一：迭代查询

FOR row1 IN select * FROM tb1{ 
    ADD( 
        SELECT* FROM tb2 WHERE 
          tb2.name = row1.member_id 
    )TO RESULT 
} 

画外音：我去，外层循环是对tb1中的所有记录，在tb2来一遍扫描，bt1数据量大的情况下，这哪里受得了?

方案二：夸库索引

对于tb1和tb2存在的潜在JOIN需求，对JOIN列建立夸库索引。

• 直接JOIN查询：建立了夸库索引后，对于JOIN的直接查询，就是idx索引表内的数据的合并就是结果
• JOIN后带WHERE条件：

SELECT * FROM tb1 INNER JOIN tb2 
ON tb1.MEMBER_ID=tb2.NAME 
      WHEREtb1.id=5 

此时需要改写SQL语句，直接在索引表上进行查询：

此时需要改写SQL语句，直接在索引表上进行查询： 
SELECT * FROM idx WHERE id1=5 

此处需要注意：

• 索引表的partition key：WHERE条件所在表的partition key，作为索引表的partition key
• 索引必须包含参与JOIN相关表的主键，JOIN字段，包含WHERE条件的字段
• 索引的更新：需要分布式事务的支持

2. GROUP BY的处理

以上表为例，patition key是ID，要在C1上进行GROUP BY操作：

SELECT SUM(price) FROM tb1 GROUP BY c1; 

改写SQL语句，先在各个分库上GROUP BY一次，并将sum计算出来：

SELECT SUM(price), c1 FROM tb1 GROUP BY c1 ORDER BY c1; 

各分库进行GROUP BY + ORDER BY + sum之后，根据排序后的c1及对应sum结果，归并一遍后即得到最终结果。

3. 小结

对于复杂语句，可以这样处理：

• 对于JOIN，可以迭代查询，或者使用分布式索引
• 对于GROUP BY，需要增加查询列，以及ORDER BY

13年底的调研笔记，文中的“画外音”是我当时的批注，希望能让大家对cobar能有一个初步的认识，有疑问之处，欢迎交流。

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文