数据库中间件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能有一个初步的认识，有疑问之处，欢迎交流。

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

标题名称：数据库中间件cobar调研笔记
文章来源：http://www.shufengxianlan.com/qtweb/news7/553457.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容