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

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的网络模型比较相似。

 

时间: 2024-09-19 10:06:23

Cobar基于MySQL的分布式数据库服务中间件的相关文章

基于mysql的分布式服务治理

问题描述 基于mysql的分布式服务治理 公司之前的分布式协调服务用的是zookeeper,现在准备用mysql替换zookeeper,做一个轻量的服务框架,就是把注册的服务和节点信息持久化在数据库中,需要的时候再从数据库中查询出来.基本的新增和查询功能都好实现,问题是如何监控已注册服务的状态变化?求有经验的大神指教 解决方案 我觉得这种需求zk比db更擅长. 如果非要用db的话,可以单独启动一个服务,去做监控的事情.

阿里巴巴分布式数据库服务DRDS研发历程

淘宝TDDL研发历史和背景 淘宝DRDS/TDDL是阿里巴巴自主研发的分布式数据库服务.DRDS脱胎于阿里巴巴开源的Cobar分布式数据库引擎,吸收了Cobar核心的Cobar-Proxy源码,实现了一套独立的类似MySQL-Proxy协议的解析端,能够对传入的SQL进行解析和处理,对应用程序屏蔽各种复杂的底层DB拓扑结构,获得单机数据库一样的使用体验,同时借鉴了淘宝TDDL丰富的分布式数据库实践经验,实现了对分布式Join支持,SUM.MAX.COUNT.AVG等聚合函数支持以及排序等函数支持

基于消息的分布式架构

美国计算机科学家,LaTex的作者Leslie Lamport说:"分布式系统就是这样 一个系统,系统中一个你甚至都不知道的计算机出了故障,却可能导致你自己的 计算机不可用."一语道破了开发分布式系统的玄机,那就是它的复杂与不可控 .所以Martin Fowler强调:分布式调用的第一原则就是不要分布式.这句话看似 颇具哲理,然而就企业应用系统而言,只要整个系统在不停地演化,并有多个子 系统共同存在时,这条原则就会被迫打破.盖因为在当今的企业应用系统中,很 难寻找到完全不需要分布式调用

阿里中间件(Aliware)双十一专题——“分布式事务中间件GTS(TXC)”

一. 前言 什么是事务?大家最熟悉的莫过于数据库事务,一大堆SQL操作一个DB,要么同时成功.要么同时失败.(GTS支持ACID,特此公告,不再解释) 什么是分布式事务?一大堆SQL操作N个DB,或者一大堆服务操作1个或多个DB,要么同时成功.要么同时失败. 怎么保证事务?有一个解决办法是"两阶段提交",一阶段大家先把该做的做了但是不提交,二阶段再一起提交或都不提交. 单机事务到分布式事务的变化?在分布式环境下,所有的状态同步都需要走网络,成本变得非常高.因此做好分布式事务容易,难点在

云时代的分布式数据库:阿里分布式数据库服务DRDS

摘要:伴随着系统性能.成本及扩展性的新时代需要,以HBase.MongoDB为代表的NoSQL数据库和以阿里DRDS.VoltDB.ScaleBase为代表的分布式NewSQL数据库如雨后春笋般不断涌现出来.本文详细介绍了阿里分布式数据库服务DRDS. 随着互联网时代的到来,计算机要管理的数据量呈指数级别地飞速上涨,而我们却完全无法对用户数做出准确预估.我们的系统所需要支持的用户数,很可能在短短的一个月内突然爆发式地增长几千倍,数据也很可能快速地从原来的几百GB飞速上涨到了几百个TB.如果在这爆

云时代的分布式数据库:阿里分布式数据库服务 DRDS

随着互联网时代的到来,计算机要管理的数据量呈指数级别地飞速上涨,而我们却完全无法对用户数做出准确预估.我们的系统所需要支持的用户数,很可能在短短 的一个月内突然爆发式地增长几千倍,数据也很可能快速地从原来的几百GB飞速上涨到了几百个TB.如果在这爆发的关键时刻,系统不稳定或无法访问,那么对 于业务将会是毁灭性的打击. 伴随着这种对于系统性能.成本以及扩展性的新需要,以HBase.MongoDB为代表的NoSQL数据库和以阿里DRDS.VoltDB.ScaleBase为代表的分布式NewSQL数据

阿里分布式数据库服务实践

沈询: 阿里巴巴资深技术专家,08年加入阿里巴巴,一直从事阿里分布式数据层方面的研发工作,参与了公司大部分的去IOE工作,具备较多实操经验.目前主要负责淘宝分布式数据层(TDDL),阿里分布式数据库服务(DRDS),阿里分布式消息服务(Notify,MetaQ)的开发和架构设计工作. 经过近一年的运营,阿里巴巴的分布式数据库(DRDS)已经协助电商,电信,银行,政府等多种类型的系统进行过业务分布式改造,在系统实施的过程中,我们碰到和解决了哪些问题? 他们是怎么解决的?背后的思考是什么?未来在何方

如何基于MySQL及Redis搭建统一的kv存储服务 | 秦波

一.MySQL+Redis常用部署方式 1.1  拓扑 1.2  特点 业务层通过双写同时写MySQL及Redis.读通常在Redis,若读取不到,则从MySQL读取,然后将数据同步到Redis,Redis通常设置expire或者默认LRU进行数据淘汰. 这种使用方式会有如下问题: 1)MySQL及Redis存在数据不一致风险,尤其是长时间运行的系统 2)业务层需要处理MySQL sql schema与Redis kv数据结构上的逻辑差异 3)无统一运维 4)无法方便扩容/缩容 二.KV化的存储

用分布式事务中间件来保障金融级交易系统的一致性

背景介绍 本篇是北京云栖大会Tech Insight Workshop金融云主题<使用SOFA来快速构建金融级分布式交易系统>中的一个组成部分. 通过前面的篇章,我们已经借助SOFA Boot框架构建了基于微服务架构的分布式交易系统框架,以及借助数据访问代理将系统的订单库由单库单表模式改造为分库分表,便于支撑平台日益增长的数据量. 在本章节中会介绍如何通过引入蚂蚁中间件的分布式事务产品来保证金融级交易系统的一致性问题,并且会分别介绍分布式事务的两种模式:TCC模式和自动模式的使用方式. DEM