数据库中间件cobar调研笔记

关注

转载最新推荐文章于 2026-05-21 10:11:31 发布 512 阅读 AI 写同款· GEO 优化 ›

MySQL分片高可用集群的Cobar部署与MySQL Cobar是一个开源的MySQL分片代理工具，它提供了一个中间层来处理分片和路由请求。Cobar是一个开源的MySQL分片代理工具，它提供了一个中间层来处理分片和路由请求。在Cobar的配置文件（cobar.xml）中，你需要指定每个分片的连接信息，例如主机名、端口号、用户名和密码。在Cobar的配置文件（cobar.xml）中，你需要指定每个分片的连接信息，例如主机名、端口号、用户名和密码。Cobar提供了一个中间层来处理分片和路由请求MySQL分片高可用集群的Cobar部署与MySQL。阅读详情

转自:https://mp.weixin.qq.com/s/nfTKSTpCvNcvNFAdl2J7mQ 58沈剑架构师之路

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：

查看table：

插入一些数据，对用户而言，后端的分布式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支持什么

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

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

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

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

HA：通过到mysql的心跳实现

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

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

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

SQL路由

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

示例

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自己搞吧。

COBAR自定义语句

查询cobar节点的状态

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

查询cobar集群的状态

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

查询SQL语句的路由情况

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

事务的支持

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

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

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

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

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

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

六，cobar系统架构

系统模块图

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

前端对上游的连接池
后端对下游mysql的连接池
对每一个请求，会经过：

SQL分析

SQL路由

SQL执行

投递给后端mysql
对每一个响应，需要做结果合并

数据流图

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

网络模型

采用异步网络模型：

结果合并

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

八，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的转发

带partition key单记录查询

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

不带partition key的where查询

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

二维partition key

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

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

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

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

SELECT * FROM visit WHERE product=‘ColaCola’

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

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

小结

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

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

十，cobar的高级特性

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语句，直接在索引表上进行查询：

SELECT * FROM idx WHERE id1=5

此处需要注意：

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

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结果，归并一遍后即得到最终结果。

小结

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

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

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

收录于

架构设计

标签

#数据库 #中间件 #cobar

STM32+ST7789屏实战：手把手教你打造物理按键控制的3级菜单GUI（附完整代码）本文详细介绍了如何使用STM32和ST7789屏构建物理按键控制的3级菜单GUI系统。从硬件架构设计、SPI驱动配置到菜单状态机实现，提供了完整的代码示例和优化技巧，帮助开发者快速掌握嵌入式GUI开发的核心技术。阅读详情