mysql cluster和cobar的使用场景分别是什么样子的

发布网友发布时间：2022-04-23 20:49

我来回答

共2个回答

懂视网时间：2022-04-30 04:39

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

产品在阿里巴巴稳定运行3年以上。

接管了3000+个MySQL数据库的schema。

集群日处理在线SQL请求50亿次以上。

集群日处理在线数据流量TB级别以上。

Cobar的核心功能：

技术分享

分布式：

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

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

Cobar也支持将不同的表放入不同的库

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

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

HA：

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

Cobar的主备切换有两种触发方式，一种是用户手动触发，一种是Cobar的心跳语句检测到异常后自动触发。那么，当心跳检测到主机异常，切换到备机，如果主机恢复了，需要用户手动切回主机工作，Cobar不会在主机恢复时自动切换回主机，除非备机的心跳也返回异常。

Cobar只检查MySQL主备异常，不关心主备之间的数据同步，因此用户需要在使用Cobar之前在MySQL主备上配置双向同步，详情可以参阅MySQL参考手册。

Cobar的功能约束

不支持跨库情况下的join、分页、排序、子查询操作。

SET语句执行会被忽略，事务和字符集设置除外。

分库情况下，insert语句必须包含拆分字段列名。

分库情况下，update语句不能更新拆分字段的值。

不支持SAVEPOINT操作。

暂时只支持MySQL数据节点。

使用JDBC时，不支持rewriteBatchedStatements=true参数设置(默认为false)。

使用JDBC时，不支持useServerPrepStmts=true参数设置(默认为false)。

使用JDBC时，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法设置参数。

Cobar逻辑层次图

技术分享

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），最后返回响应。

技术分享

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

技术分享

参考文档：https://github.com/alibaba/cobar

转自：http://www.biaodianfu.com/cobar.html

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

标签：

热心网友时间：2022-04-30 01:47

mysql cluster和cobar的我没使用过，仅仅从认识上说下。
这些都算不是主流的技术，所以仅就使用场景来说，其实很有限，因为你需要面对很多约束。比如MySQL cluster可能需要你的所有数据都hold在内存里，我不习惯许多人说“使用场景”这个说法，实际上，这只能说明能用，但现实中，选择一种产品，考虑的因素很多，能用往往并非决定性的因素。
MySQL cluster主要确保的是高可用，这是实际的分布式数据库产品，一种share-nothing的架构，如果数据规模不是超大的话，一般可以满足需要，但理论上，其扩展性是有极限的，因为节点增多，节点之间的数据同步会影响到性能，这是其架构决定的。
cobar属于中间件产品，其后端仍然是MySQL，由于MySQL本质上不是一个分布式数据库产品，所以cobar的应用会有许多局限，比如不支持跨库的join，如果要使用，一定要清楚它的*。它可以简化水平扩展，理论上是可以提供极佳的扩展能力的。
相对而言，cobar这种方式会更更具实践意义，因为传统的分库分表本来就是非常成熟的技术，cobar简化了这个过程，大规模的集群也许能带来开发和扩容的便利。而MySQL Cluster，如果你不是专家，可能会碰到很多问题，现实中，MySQL Cluster可以解决的问题，传统的架构也能解决，所以没有那么迫切要使用这个产品。