数据库相关中间件介绍

时间 2019-12-02

原文原文链接

这里主要介绍互联网行业内有关数据库的相关中间件。数据库相关平台主要解决如下三个方面的问题：前端

为海量前台数据提供高性能、大容量、高可用性的访问node
为数据变动的消费提供准实时的保障mysql
高效的异地数据同步git

应用层经过分表分库中间件访问数据库，包括读操做（Select）和写操做（update, insert和delete等，DDL, DCL）。写操做会在数据库上产生变动记录，MySQL的变动记录叫binlog, Oracle的称之为redolog, 增量数据订阅与消费中间件解析这些变动，并以统一的格式保存起来，下层应用根据这些数据进行消费应用。固然，在数据库与数据库自己之间也会有数据库迁移的操做，这种操做能够不须要增量数据订阅与消费中间件的数据，而能够自行处理。github

数据库中间件有如下几种：web

分布式数据库分表分库算法
数据增量订阅与消费sql
数据库同步（全量、增量、跨机房、复制）数据库
跨数据库（数据源）迁移

整个产品族图以下：

最上层的是分布式数据库分表分库中间件，负责和上层应用打交道，对应用可表现为一个独立的数据库，而屏蔽底层复杂的系统细节。分布式数据库中间件除了基本的分表分库功能，还能够丰富一下，好比讲读写分离或者水平扩容功能集成在一块儿，或者好比读写分离自己也能够做为一个独立的中间件。（Cobar, MyCAT, TDDL, DRDS, DDB）
增量数据订阅和消费，用户对数据库操做，好比DML, DCL, DDL等，这些操做会产生增量数据，下层应用能够经过监测这些增量数据进行相应的处理。典型表明Canal，根据MySQL的binlog实现。也有针对Oracle(redolog)的增量数据订阅与消费的中间件。（Canal, Erosa）
数据库同步中间件涉及数据库之间的同步操做，能够实现跨（同）机房同步以及异地容灾备份、分流等功能。能够涉及多种数据库，处理以后的数据也能够以多种形式存储。（Otter, JingoBus, DRC）
数据库与数据库之间会有数据迁移（同步）的动做，同款数据同步原理比较简单，好比MySQL主备同步，只要在数据库层进行相应的配置既可，可是跨数据库同步就比较复杂了，好比Oracle->MySQL. 数据迁移通常包括三个步骤：全量复制，将原数据库的数据全量迁移到新数据库，在这迁移的过程当中也会有新的数据产生；增量同步，对新产生的数据进行同步，并持续一段时间以保证数据同步；原库停写，切换新库。将“跨数据库”这个含义扩大一下——“跨数据源”，好比HDFS, HBase, FTP等均可以相互同步。（yugong, DataX）

分布式数据库

随着互联网产品在体量和规模上日益膨胀，不管是Oracle仍是MySQL，都会第一时间面临来自磁盘，CPU和内存等单机瓶颈，为此，产品方除了须要不断购买成本难以控制的高规格服务器，还要面临不断迭代的在线数据迁移。在这种状况下，不管是海量的结构化数据仍是快速成长的业务规模，都迫切须要一种水平扩展的方法将存储成本分摊到成本可控的商用服务器上。同时，也但愿经过线性扩容下降全量数据迁移对线上服务带来的影响，分库分表方案便应运而生。

分表分库类的中间件主要有两种形式向应用提供服务：

一种是以JDBC的jar包形式为Java应用提供直接依赖，Java应用经过提供的JDBC包实现透明访问分布式数据库集群中的各个分库分表，典型表明网易的DDB和阿里的TDDL.
另外一种是为应用部署独立的服务来知足应用分库分表的需求，在这种方式下经过标准JDBC访问Proxy，而Proxy则根据MySQL标准通讯协议对客户端请求解析，还原应用SQL请求，而后经过本地访问数据库集群，最后再将获得的结果根据MySQL标准通讯协议编码返回给客户端。典型表明阿里的Cobar, Cobar变种MyCAT, 阿里的DRDS，网易的DDB proxy模式以及DDB的私有云模式。

Cobar

Cobar 是提供关系型数据库（MySQL）分布式服务的中间件，它可让传统的数据库获得良好的线性扩展，并看上去仍是一个数据库，对应用保持透明。

Cobar以Proxy的形式位于前台应用和实际数据库之间，对前台的开放的接口是MySQL通讯协议。将前台SQL语句变动并按照数据分布规则发到合适的后台数据分库，再合并返回结果，模拟单库下的数据库行为。

Cobar属于阿里B2B事业群，始于2008年，在阿里服役3年多，接管3000+个MySQL数据库的schema,集群日处理在线SQL请求50亿次以上。因为Cobar发起人的离职，Cobar中止维护。后续的相似中间件，好比MyCAT创建于Cobar之上，包括如今阿里服役的RDRS其中也复用了Cobar-Proxy的相关代码。

Cobar结构

与应用之间经过MySQL protocol进行交互，是一个proxy的结构，对外暴露jdbc:mysql://CobarIP:port/schema。对应用透明。
无需引入新的jar包，从访问迁移到数据库访问Cobar能够复用原有的基于JDBC的DAO。
Cobar先后端都实现了MySQL协议，当接受到SQL请求时，会一次进行解释（SQL Parser）和路由（SQL Router）工做，而后使用SQL Executor去后端模块获取数据集（后端模块还负责心跳检查功能）；若是数据集来自多个数据源，Cobar则须要把数据集进行组合（Result Merge），最后返回响应。
数据库链接复用。Cobar使用链接词与后台真是数据库进行交互。（实际应用中，根据应用的不一样，使用proxy结构后数据库链接数可以节约2-10倍不等。）
Cobar事务，Cobar在单库的状况下保持事务的强一致性，分库的状况下保持事务的弱一致性，分库事务采用2PC协议，包括执行阶段和提交阶段。

Cobar的前端是NIO的，然后端跟MySQL交互是阻塞模式，其NIO代码只给出了框架，尚未来得及实现。据称未开源版的Cobar实现了后端的NIO。Cobar会出现假死，假死之后Cobar会频繁进行主从切换（若是配置了的话），自动切换自己也存在隐患。能够计算：Cobar的TPS=5,000,000,000/(30002460*60)=20。

与Cobar相关的还有一共Cobar-Client.

Cobar经过SQL语句转发的方式实现数据访问。用户发来的SQL语句，Cobar解析其内容，判断该语句所涉及的数据分布在哪一个分库上，再将语句转发给此分库执行。当SQL语句中涉及的拆分字段有多值，如 IN, 或where条件中没有出现拆分字段时，该语句将会转发至后台全部分库执行，再将执行结果以MySQL协议包的形式送回应用端。

通讯模块，负责从连续的网络数据流中识别出一个个MySQL协议包，再解析协议包识别出SQL语句输出给Parser模块，同时，把Result Merge模块输入的执行结果，编码成MySQL的协议包。它以NIO方式实现，有很高的执行效率。以后进行优化，引入了一个ByteBuffer池，将NIO的Buffer统一管理起来，减小了NIO数据交互时的垃圾回收。

Cobar前端使用的是优化后的NIO通讯模块，为了让该模块在后端使用，Cobar去除了JDBC。与后端数据库交互，Cobar直接面向协议，目前实现了基于MySQL协议的后端交互。

水平拆分后，后台有多个数据源，对他们的管理分为两个层次：DataNode和replica(HA Pool)。DataNode管理拆分，一个DataNode存放一个分片的数据，彼此无数据交集。每一个分片的数据存多份以保证高可用，每一份叫作一个replica，由HA层管理。每个replica表示一个具体的数据源，它是一个链接池，池内管理每个具体的JDBC链接。路由运算只关注到DataNode层，之下的层次对其不可见。每一份replica之间的数据复制和同步由MySQL自己的replication协议完成，同一时刻只有一个replica提供服务（称为Master，其他replica称为Slave）.Cobar会与之保持心跳，一旦发现它不可用，会切换至另外一个replica，解决Oracle单点的第二个问题。

为了节省数据库的机器数量，能够采用下图中的方式部署：

HA

在用户配置了MySQL心跳的状况下，Cobar能够自动向后端链接的MySQL发生心跳，判断MySQL运行情况，一旦运行出现异常，Cobar能够自动切换到备机工做，但须要强调的是：

Cobar的主备切换有两种触发方式，一种是用户手动触发，一种是Cobar的心跳语句检测到异常后自动触发。那么，小心跳检测到主机异常，切换到备机，若是主机恢复了，须要用户手动切回主机工做，Cobar不会在主机恢复时自动切换回主机，除非备机的心跳也返回异常。
Cobar只检查MySQL主备异常，不关心主备之间的数据同步，所以用户须要在使用Cobar以前在MySQL主备上配置双向同步，详情能够参阅MySQL参考手册。

Cobar解决的问题

分布式：Cobar的分布式主要是经过将表放入不一样的库来实现。

Cobar支持将一张表水平拆分红多份分别放入不一样的库来实现表的水平拆分
Cobar也支持将不一样的表放入不一样的库
多数状况下，用户将以上两种方式混合使用

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

Cobar的约束

不支持跨库状况下的join、分页、排序、子查询操做
SET语句执行会被忽略，事务和字符集设置除外
分库状况下，insert语句必须包括拆分字段列名
分库状况下，update语句不能更新拆分字段的值
不支持SAVEPOINT操做
暂时只支持MySQL数据节点
使用JDBC时，不支持rewriteBatchedStatements=true参数设置（默认为false）
使用JDBC时，不支持useServerPrepStmts=true参数设置（默认为false)
使用JDBC时，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法设置参数

MyCAT

从定义和分类看，它是一个开源的分布式数据库系统，是一个实现了MySQL协议的Server，前端用户能够把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端能够用MySQL Native Protocol与多个MySQL服务器通讯，也能够用JDBC协议与大多数主流数据库服务器通讯，其核心功能是分表分库，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其余数据库里。

MyCAT发展到目前的版本，已经不是一个单纯的MySQL代理了，它的后端能够支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，将来还会支持更多类型的存储。

MyCAT是一个强大的数据库中间件，不只仅能够用做读写分离，以及分表分库、容灾管理，并且能够用于多租户应用开发、云平台基础设施，让你的架构具有很强的适应性和灵活性，借助于即将发布的MyCAT只能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你能够自动或手工调整后端存储，将不一样的表隐射到不一样存储引擎上，而整个应用的代码一行也不用改变。

MyCAT是在Cobar基础上发展的版本，两个显著提升：

后端由BIO改成NIO，并发量有大幅提升；
增长了对Order By, Group By, Limit等聚合功能（虽然Cobar也能够支持Order By, Group By, Limit语法，可是结果没有进行聚合，只是简单返回给前端，聚合功能仍是须要业务系统本身完成）

MyCAT架构

事务是弱XA
MyCAT的原理中最重要的一个动词是“拦截”，它拦截了用户发来的SQL语句，首先对SQL语句作了一些特定的分析：如分片分析，路由分析、读写分离分析、缓存分析等，而后将此SQL发日后端的真实数据库，并将返回的结果作适当的处理，最终再返回给用户。
MyCAT对自身不支持的SQL语句提供了一种解决方案——在要执行的SQL语句前添加额外的一段由注解SQL组织的代码，这样SQL就能正确执行，这段代码称之为“注解”。注解的使用至关于对MyCAT不支持的SQL语句作了一层透明代理转发，直接交给目标的数据节点进行SQL语句执行。
MyCAT自身有相似其余数据库的管理监控方式，能够经过MySQL命令行，登陆管理端口（9066）执行相应的SQL进行管理，也能够经过jdbc的方式进行远程链接管理。

HA

MyCAT做为一个代理层中间件，MyCAT系统的高可用设计到MyCAT自己的高可用以及后端MySQL的高可用. 在多数状况下，建议采用MySQL主从复制高可用性配置并交付给MyCAT来完成后端MySQL节点的主从自动切换。

MySQL侧的HA

MySQL节点开启主从复制的配置方案，并将主节点配置为MyCAT的dataHost里的writeNode，从节点配置为readNode，同时MyCAT内部按期对一个dataHost里的全部writeHost与readHost节点发起心跳检测。
正常状况下，MyCAT将第一个writeHost做为写节点，全部的DML SQL会发送此节点。
若MyCAT开启了读写分离，则查询节点会根据读写分离的策略发往readHost(+writeHost)执行。
若是第一个writeHost宕机，MyCAT会在默认的三次心跳检测失败后，自动切换到下一个可用的writeHost执行DML SQL语句
当原来配置的MySQL写节点宕机恢复后，做为从节点，跟随新的主节点，从新配置主从同步。

MyCAT自身的HA

官方建议是采用基于硬件的负载聚亨或者软件方式的HAproxy等。
若是还担忧HAproxy的稳定性和但节点问题，则能够用keepalived的VIP的浮动功能，加以强化。

MyCAT功能和特性

支持SQL 92标准
支持Mysql集群，能够做为Proxy使用
支持JDBC链接多数据库
支持NoSQL数据库
支持galera sfor mysql集群，percona-cluster或者mariadb cluster，提供高可用性分片集群
自动故障切换，高可用性
支持读写分离，支持MySQL双主多从，以及一主多从的模式
支持全局表，数据自动分片到多个节点，用于高效表关联查询
支持一致性Hash分片，有效解决分片扩容难题
多平台支持，部署和试试简单
支持Catelet开发，相似数据库存储过程，用于跨分片复杂SQL的人工智能编码实现
支持NIO与AIO两种网络通讯机制，windows下建议AIO,Linux下目前建议NIO
支持MySQL存储过程调用
以插件的方式支持SQL拦截和改写
支持自增加逐渐、支持Oracle的Sequence机制
支持Mysql, MongoDB，Oracle, SQL Server, Hive, DB2, PostgreSQL等。

MyCAT目前的项目

MyCAT-Server:MyCAT核心服务
MyCAT-Spider:MyCAT爬虫技术
MyCAT-ConfigCenter:MyCAT配置中心
MyCAT-BigSQL:MyCAT大数据处理（暂未更细）
MyCAT-Web:MyCAT监控及web（新版开发中）
MyCAT-Balance:MyCAT负载均衡（暂未更细）

DRDS/TDDL

alibaba. Distributed Relational Database Service.

阿里分布式数据库DRDS的前身是淘宝分布式数据库层TDDL，大概在2012年的时候，阿里开始尝试将TDDL这套体系输出到阿里云上，也有了一个新的名字：DRDS.

TDDL

Tabao根据本身的业务特色开发了TDDL(Tabao Distributed Data Layer, 外号：头都大了)。主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，它是一个基于集中式配置的jdbc datasourcce实现，具备主备，读写分离，动态数据库配置等功能。

TDDL并不是独立的中间件，只能算做中间层，是以Jar包方式提供给应用调用。属于JDBC Shard的思想。

TDDL处于业务层和JDBC层中间。

TDDL其实主要能够划分为3层架构，分别是Matrix层，Group层和Atom层。Matrix层用于实现分库分表逻辑，底层多个Group实例。而Group和Atom共同组成了动态数据源，Group层实现了数据库的Master/Slave模式的写分离逻辑，底层持有多个Atom实例。最后Atom层（持有数据源）实现数据库ip, port, password, connectionProperties等信息的动态推送，以及持有院子的数据源分离的JBoss数据源。

TDDL社区处于停滞状态，网上可查资源也较少。

RDRS

DRDS/TDDL是阿里巴巴自主研发的分布式数据库服务。DRDS脱胎于阿里巴巴开源的Cobar分布式数据库引擎，吸取了Cobar核心的Cobar-Proxy源码，实现了一套独立的相似MySQL-Proxy协议的解析端，可以对传入的SQL进行解析和处理，对应用程序屏蔽各类复杂的底层DB拓扑结构，得到单机数据库同样的使用体验，同时借鉴了淘宝TDDL丰富的分布式数据库实践经验，实现了对分布式Join支持，SUM/MAX/COUNT/AVG等聚合函数支持以及排序等函数支持，经过异构索引、小表广播等解决分布式数据库使用场景下衍生出的一系列问题，最终造成了完整的分布式数据库方案。

DRDS在整个阿里系统中所处的位置：

对于不少应用而言，单机数据库最终都会碰到单机性能上的天花板，在TPS/QPS/内存容量/磁盘容量等等一系列系统资源上会碰到各种限制。DRDS的主要目标就是帮您解决这方面的各种问题，他主要提供了两个功能，读写分离和数据库切分:

读写分离，可以运行实现一台机器写入，多台机器读取，这对于读多写少的应用，可以以极低的成本解决系统的瓶颈。
数据库切分是一个解决系统存储瓶颈的最终极解决方案，数据库切分的核心思想其实很简单，就是分而治之。将数据分散到多台机器，并保证请求可以平均的分发到这些机器上，就能够以极低的成原本解决业务的各种性能瓶颈。固然切分也是有代价的，最明显的代价就是，分布式数据库会对一些原有单机数据的场景进行限制，由于这些操做，在分布式环境下的延迟或效率很是低效，就算是可以实现出来，也会由于性能问题而没法使用。

其余功能特性

1.分布式MySQL执行引擎

主要目标是实现与单机数据库SQL引擎的彻底兼容，实现SQL的智能下推，可以智能分析SQL，解析出那些SQL能够直接下发，那些SQL须要进行优化改造，优化成什么样，以及路由到哪些实例节点上执行，充分发挥数据库实例的所有能力，减小网络之间的数据传输量，最终对不一样实例处理后的少许结果进行聚合计算返回给应用调用方。这就是分布式SQL引擎的智能下推功能。分布式引擎的职责包含SQL解析，优化，执行和合并四个流程。

支持市面上几乎全部的语言（具备MySQL访问能力的），兼容90%以上MySQL语法。

案例分析：好比一个简单的AVG操做，对于一些比较初级的分布式数据库模型而言，常见作法是把AVG直接下发到全部存储节点，这样形成的结果就是语法兼容，语义不兼容，最终拿到的是错误结果。而DRDS的智能下推引擎，对SQL的语法作充分的语义兼容性适配，针对AVG操做，只能由引擎将逻辑AVG SQL解析优化为SUM和COUNT的SQL而后进行下推，由底层的数据库实例节点完成SUM和COUNT计算，充分利用底层节点的计算能力，在引擎层将各个存储节点的SUM和COUNT结果聚合计算，最终计算出AVG。

2.在线平滑扩容

在线数据扩容的重点在于“在线”两字，也就是用户不须要中止业务进行割接操做，直接就能够添加新的RDS节点到集群中，实现无缝的自由扩展。RDRS则将整个扩容过程分为几个阶段，包括全量迁移，增量同步，切换数据库等几个步骤。数据会提早进行搬迁，并进行增量并行同步一段时间，所以，咱们能够在很是短的时间内（秒级别）完成数据库的最终扩容切换工做，对业务没有影响。

3.小表广播

在一些大的业务表进行了切分后，总会存在一些表的数据量不大，更新量也不大的原始信息表。这些表每每会与咱们的切分后大表进行join操做，这种操做物理上就会形成分布式join查询，效率从总体上会比较地下。针对这种分布式join的场景，开发了OETL专用工具来进行小表广播，将原信息表的全部数据（包括增量更新）所有自动的广播到大表的机器上，这样，就可让原来的分布式查询变成单机本地查询了。

4.全局惟一ID

DRDS sequence功能的目标只是为了保证数据的全局惟一，虽然基本上是按时间序列获取的，但并不全局有序。

5.异构索引

解决分布式场景下数据拆分维度和数据查询使用维度不一致致使的低效问题。

当数据表被拆分为多个分库分表时，数据在分库分表的分布规则就固定了。可是一般数据的业务使用场景很是复杂，若是数据的查询维度和数据拆分分布的规则一直，单条SQL会在一个分库分表上执行；若是数据的查询使用维度和数据拆分分布的规格不一致，单条SQL可能在多个分库分表上执行，出现跨库查询，跨库查询会增长IO成本，查询效率必然降低。

解决这个问题的思路仍是分布式数据库的一向原则，让SQL执行在单库上完成，实际采用的方式就是用“空间换效率”的方案，也就是将同一份数据表，冗余存储多份，按照不一样的业务使用场景进行拆分，保持拆分维度和使用维度统一，而多份数据之间会实时数据复制以解决数据一致性问题，这就是“异构索引”方案。固然异构索引表不能无限制滥用，过多的异构索引表会影响同步效率，对源数据表形成同步压力。

其余同款中间件

Altas, Vitess, Heisenberg, CDS, DDB， OneProxy等等。

Atlas

Qihoo 360.Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目，它是在mysql-proxy 0.8.2版本上对其进行优化，增长了一些新的功能特性。Atlas是一个位于应用程序与MySQL之间，它实现了MySQL的客户端和服务端协议，做为服务端与应用程序通信，同时做为客户端与MySQL通信。它对应用程序屏蔽了DB的细节。Altas不能实现分布式分表，全部的字表必须在同一台DB的同一个DataBase里且全部的字表必须实现建好，Altas没有自动建表的功能。

Heisenberg

Baidu.其优势：分库分表与应用脱离，分库表如同使用单库表同样，减小db链接数压力，热重启配置，可水平扩容，遵照MySQL原生协议，读写分离，无语言限制，mysqlclient, c, Java均可以使用Heisenberg服务器经过管理命令能够查看，如链接数，线程池，结点等，并能够调整采用velocity的分库分表脚本进行自定义分库表，至关的灵活。（开源版已中止维护）

CDS

JD. Completed Database Sharding.CDS是一款基于客户端开发的分库分表中间件产品，实现了JDBC标准API，支持分库分表，读写分离和数据运维等诸多共，提供高性能，高并发和高可靠的海量数据路由存取服务，业务系统可近乎零成本进行介入，目前支持MySQL, Oracle和SQL Server.(架构上和Cobar，MyCAT类似，直接采用jdbc对接，没有实现相似MySQL协议，没有NIO,AIO，SQL Parser模块采用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)

DDB

猪场. Distributed DataBase.DDB经历了三次服务模式的重大更迭：Driver模式->Proxy模式->云模式。

Driver模式：基于JDBC驱动访问，提供一个db.jar, 和TDDL相似，位于应用层和JDBC之间.
Proxy模式：在DDB中搭建了一组代理服务器来提供标准的MySQL服务，在代理服务器内部实现分库分表的逻辑。应用经过标准数据库驱动访问DDB Proxy, Proxy内部经过MySQL解码器将请求还原为SQL, 并由DDB Driver执行获得结果。
私有云模式：基于网易私有云开发的一套平台化管理工具Cloudadmin, 将DDB原先Master的功能打散，一部分分库相关功能集成到proxy中，如分库管理、表管理、用户管理等，一部分中心化功能集成到Cloudadmin中，如报警监控，此外，Cloudadmin中提供了一键部署、自动和手动备份，版本管理等平台化功能。

数据增量订阅与消费

基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了mysql.有关数据增量订阅与消费的中间件回顾一下：

增量订阅和消费模块应当包括binlog日志抓取，binlog日志解析，事件分发过滤（EventSink），存储（EventStore）等主要模块。
若是须要确保HA能够采用Zookeeper保存各个子模块的状态，让整个增量订阅和消费模块实现无状态化，固然做为consumer(客户端)的状态也能够保存在zk之中。
总体上经过一个Manager System进行集中管理，分配资源。

Canal

Canal架构图：

说明：

server表明一个canal运行实例，对应于一个jvm
instance对应于一个数据队列（1个server对应1..n个instance)

instance模块：

eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
eventSink (Parser和Store连接器，进行数据过滤，加工，分发的工做)
eventStore (数据存储)
metaManager (增量订阅&消费信息管理器)

说明：一台机器下部署一个canal，一个canal能够运行多个instance(经过配置destinations等), 通常状况下一个client链接一个instance（每一个instance能够配置standby功能）, 能够多个client链接同一个instance，可是同一时刻只能有一个client消费instance的数据，这个经过zookeeper控制。

数据库同步

Otter

背景：alibaba B2B由于业务的特性，卖家主要集中在国内，买家主要集中在国外，因此衍生出了杭州和美国异地机房的需求，同时为了提高用户体验，整个机房的架构为双A，两边都可写，由此诞生了otter这样一个产品。

otter初版本可追溯到04~05年，这次外部开源的版本为第4版，开发时间从2011年7月份一直持续到如今，目前阿里巴巴B2B内部的本地/异地机房的同步需求基本全上了otter4。

基于数据库增量日志解析，准实时同步到本地机房或异地机房的mysql/oracle数据库，一个分布式数据库同步系统。

工做原理

原理描述：

基于Canal开源产品，获取数据库增量日志数据。
典型管理系统架构，manager(Web管理)+node(工做节点)
- manager运行时推送同步配置到node节点
- node节点将同步状态反馈到manager上
基于zookeeper，解决分布式状态调度的，容许多node节点之间协同工做。

Otter的做用

异构库
- mysql->mysql、oracle. (目前开原版只支持mysql增量，目标库能够是mysql或者oracle,取决于canal的功能)
单机房同步（数据库之间RTT(Round-Trip Time)<1ms）
- 数据库版本升级
- 数据表迁移
- 异步二级索引
跨机房同步（好比阿里巴巴国际站就是杭州和美国机房的数据库同步，RTT>200ms）
- 机房容灾
双向同步
- 避免回环算法（通用的解决方案，支持大部分关系型数据库）
- 数据一致性算法（保证双A机房模式下，数据保证最终一直性）
文件同步
- 站点镜像（进行数据复制的同时，复制关联的图片，好比复制产品数据，同事复制产品图片）

单机房复制示意图

说明：- 数据On-Fly, 尽量不落地，更快的进行数据同步。（开启node load balance算法, 若是Node节点S+ETL落在不一样的Node上，数据会有个网络传输过程）- node节点能够有failover/loadBalancer.

SETL

S: Select为解决数据来源的差别性，好比接入canal获取增量数据，也能够接入其余系统获取其余数据等。

E: Extract

T: Transform

L: Load

相似于数据仓库的ETL模型，具体可为数据join，数据转化，数据加载。

跨机房复制示意图

数据涉及网络传输，S/E/T/L几个阶段会分散在2个或者更多Node节点上，多个Node之间经过zookeeper进行协同工做（通常是Select和Extract在一个机房的Node, Transform/Load落在另外一个机房的Node）node节点能够有failover/loadBalancer。(每一个机房的Node节点，均可以是集群，一台或者多台机器)

异地双活数据架构基础设施DRC

所谓DRC，就是Data Replication Center的缩写，数据复制中心。这种复制是同步的，支持异构的，高可用的（有严格容灾系统，实时性好），支持订阅分发的。项目期初是为了淘宝异地容灾而成立的，用于数据库之间主备同步，后来采用这套技术方案衍生出了DRC-TAIR, DRC-DUMP等项目。

所谓异地双活主要关注两件事，一个数据同步，一个数据分发。

到底怎样的应用会须要异地的双活？比较常见的场景有三个：

两个地域或多个地域都有大量用户的场景，好比在中国的用户但愿他们用杭州的RDS服务，在美国的用户用美国的RDS服务，这就须要数据在异地同步。不少游戏，金融，传媒，电商业务都有这种需求。知足这个需求的难点在于跨地域的网络，好比网络延时长，丢包多，并且数据在公网传输会有数据泄露风险。
数据来源较多，须要介入各类异构数据的场景。好比一个应用须要从ODPS, RDS, OTS， OceanBase, PostgreSQL这几个服务介入数据，他们的数据结构和接口都不一样，这种接入的成本会比较高。所以另外一个可用的方法是数据写入的时候就一份多谢为不一样数据结构
下游订阅不少的状况，好比一份数据，备份系统、通知系统、大数据分析系统、索引系统等等都要来取，若是用上面一份数据多写的方案是能够应对的，但这里还有其余难点，就是数据一致性、可扩展性、跨网同步稳定性、以及同步的实时性。

DRC支持读取集团MySQL, RDS, OceanBase, HBase, Oracle等多种不一样的数据源的实时增量数据，支持写入数据库、MetaQ, ODPS等多种存储媒介.

之前在一个城市作双机房主备，两个机房是数据对等的，写入是随机分布，而后经过主备HA进行数据同步。这样机房对等的思路会致使业务增加、数据增加只能经过两个机房不停堆机器来解决。另外一方面，若是整个城市断电，那么双活就成了双死。下一个思路是作跨城市，早期经常使用的作法是一个城市写，另外一个城市冷备，就是晚上作同步，但这就意味着白天若是发生了什么事儿，这一天的数据就比较危险。另外一个思路是两个城市多写，数据落两边，这样的问题是应用调用次数频繁的话，若是调用异地数据多来那么一两次，整个应用的延时就很长。这个思路再进一步发展，就是作单元内封闭以减小异地调用，这就涉及到业务上的改造。

顺着这个思路，阿里的异地双活重点作了几件事。一个是热插拔，能够作到在业务高峰时增长节点，高峰过了把增长的节点关闭。作到这个的一个关键是流量实时切换，DRC能够在20秒之内把一个单元（region）的流量迁移到另外一个单元。另外一个是数据实时恢复，就是经过必定的冗余设计，一旦一个单元挂掉了，能够在另外一个单元作全量恢复。

异地多活在数据方面的挑战是很是大的。双十一期间，交易会激增，因此交易链路作了单元化。交易链路的数据分为三个维度：买家、卖家、商品。买家之间一般没有太多交叉，自然的适应这种隔离，并且卖家对延迟的敏感度很是高，因此按照卖家维度切分，在单元内封闭，而卖家和商品都是在中心写入。

数据方面的两个核心要求：

一致性，要求卖家和商品一致，单元和中心一致，也就是数据同步不能丢数据，不能错数据，还要保证事务。
实时性，须要作到秒级别的延迟。

双单元的同步架构有两种：一种是读写分离的方式，中心写，单元读。单元须要的数据若是没有从中心及时同步过来，或者同步错了，那有问题这段时间的交易会所有收到影响。这里的核心是，保证秒级延迟，同时保证一致性。（JD的多中心交易系统就采用了这种方式）

第二种同步架构是单元封闭的方式。中心和单元各有写入，咱们经过冗余是的中心和单元随时能够各自接管。（相似Otter）

这里的关键是：

避免循环复制：经过在DB透传打标事务的方式实现。
限流：峰值的压力，咱们单元化原本就选取了流量激增业务，两边都实时同步100%全量数据，峰值对每一个系统的压力有增无减。DRC的store和congo均可以根据TPS或者流量限流。限速算法的核心思想分为批量采样，奖惩时间，平滑变速。

Otter与DRC的区别：- Otter是阿里B2B的产品，DRC是阿里技术保障团队的产品- Otter是针对MySQL的，DRC能够支持多种类型的数据源- DRC从业务上进行了划分，能够实现单元内封闭，Otter的实现不涉及业务，而是在纯数据库层打通的技术- Otter是双写，DRC是中心写、分中心读，或者都部分写，相互同步。- Otter所处的网络环境较DRC差，解决一致性问题也较复杂（基于trusted source的单向环回的补救，基于时间交集的补救），DRC有两种实现方式，具体参考上面。

异地多活中DRC的核心能力就是在低延迟，一致性和高可用。

一致性：基于日志流式抓取、回放库表结构变动、基于事务的冲突检测。
低延迟：最大延迟不超过1s, 消息协议优化，三级数据存储，预读优化IO, 多链接复用和传输压缩，高效的并发复制算法。
高可用：主备切换，拓扑变化，心跳跟踪，多维度容灾。

JD多中心交易系统

JD. 多中心交易系统。

JD数据复制中间件考察和借鉴了开源社区的实现，例如Databus、Canal/Otter、OpenReplicator等，解析部分使用了Canal的DBSync。

多中心交易本质上是一个更大的分布式系统，交易流程中依赖和产生的数据和服务有不一样的特色，必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。

其中，数据一致性是电商网站须要面临的首要问题，越是流量增大的时候越要保证数据更新的即时性和准确性。在多中心之间须要同步卖家数据和商品数据，若是同步的延时太长，买家、卖家都不可接受。好比，卖家改了价格或库存，用户不能过好久才看到。一样，数据正确性也是很大的挑战，卖掉的商品可以及时减小，退货的商品可以及时增长。这都时刻考验着后端系统和数据库平台的健壮性。

除了数据一致性以外，如何保证路由规则的一致性也是关键性的问题。从技术角度来讲，要保障单一用户从登陆到访问服务、到访问数据库，全链路的路由规则都是彻底一致的。若是路由错误，看到的数据不正确，也会影响到最终用户的体验。

架构

系统包括一个主中心和多个分中心，主中心与分中心之间经过数据总线交换数据。数据流向中，主数据(商品数据、商家数据、用户数据等)的流向从主中心经过数据总线实时同步到分中心，分中心只读；而交易数据(订单数据)的流向从分中心实时同步到主中心；在故障时，会从分中心转移到主中心。

在这个系统中，有多处体现分流的概念。首先，买家访问京东网站下单时，会被优先分流到附近的交易中心；其次，根据交易系统的特色，接单前（包括购物车、结算页等），多中心交易按用户维度分流，以下图所示。用户登陆时，查询用户与区域的映射关系表（相似你是哪一个片区的），标识此用户属于哪一个分中心，并保存标识到cookie中，而后将用户路由到指定的分中心。用户访问其余系统，如购物车和结算页时，从cookie中读取标识，重定向到相应分中心页面。

经过分流，将用户分配到相应的分中心，一方面响应速度快，用户体验更好，不用跨地域访问数据中心了；另外一方面，每一个中心服务必定数量的用户，水平扩展性好，也能支撑更大的交易规模了。固然，多数据中心不能盲目干活，还考虑到容灾备份的问题。（支付宝光纤事件）

交易系统包括应用和数据部分，应用部分是无状态的，就是说，这些工做是无差异的，一台服务器出问题，我换一台服务器来处理就是了，较容易实现多机房多活。可是数据不同，多中心交易本质上是一个更大的分布式系统，必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。

另外，交易流程中依赖和产生的数据和服务有不一样的特色。好比商品、促销和价格、库存的读服务，咱们能够将之称为基础主数据，它们在用户下单流程中是没法分区的，不然没法实现单机房内流量闭环，也就是说，不能由于分区数据的不一致，致使同一用户在单一流程中看到不一样的数据（假如你加入购物车时是促销20块，结帐是25块，你会不会表情扭曲？）而商品、促销和价格的写服务,是给采销、第三方POP商家应用调用的，这种业务场景的可用性目标，主机房部署和冷备模式便可知足，并且业务人员的操做流程会抵消写复制延迟。

简单来讲，数据的问题表如今如下几个方面：1、如何保证数据的即时性和准确性，多中心之间须要同步卖家数据和商品数据，若是同步的延时太长,买家、卖家都不可接受，因为是异地部署，最好延时能控制在1秒内。好比，卖家改了价格或库存，用户不能过好久才看到。一样，数据正确性也是很大的挑战,由于数据故障跟应用层故障不同，应用出故障了，可能只影响用户访问；数据写错了没法恢复。二、如何保证路由规则的一致性，要保障这个用户从进来到访问服务，到访问数据库，全链路的路由规则都是彻底一致的；若是路由错误，看到的数据不正确。

从同城双机房的分布转变为异地多机房的分布，给数据同步带来了新的挑战，所以如何设计数据总线也是项目可否实现的关键因素。京东的多中心交易系统经过数据总线JingoBus进行快速数据交换，同步性能是mysql的3倍以上，并且可用性高，架构灵活。其中，全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题，实现了高性能、低延时、健壮的数据同步机制。

如图所示，数据总线主要分Relay、Snapshot和Replicator三部分构成，其中Relay历来源数据库抽取事务日志，并对Replicator提供日志订阅服务，角色上至关于Mysql Slave IO Thread。Snapshot从Relay订阅全部事务日志，写入持久存储做为快照，同时向Replicator提供批量日志订阅服务，角色上至关于Mysql Slave Relay Log。Replicator：事务日志的消费端，从Relay或Snapshot拉取事务日志将事务日志按配置的一致性应用到目标数据库，角色上至关于Mysql Slave SQL Thread。(参考下面MySQL主备复制原理图)

正常状况下，Replicator直接链接Relay，消费Relay内存队列中的事务日志。但有些状况下，由于网络抖动、目标库的负载太高等因素，可能致使Replicator相对Relay落后不少。另外，当新的消费端加入同一数据源的订阅者时，新消费端有冷启动的问题。为了不从新从数据源作全量快照，Snapshot做为Relay的一个特殊消费端，经过一种高吞吐的消费方式，从Relay源源不断的消费在线事务日志，经过对事务日志的有效处理，最终保存了数据源的一份一致快照(Consistent Snapshot)，即包括了数据源库表中每一行的最新状态的快照，同时保留了一段比Relay buffer更旧的事务日志(Log Store)。由此看来，数据总线做为一个数据层的通用CDC组件，对于多中心交易项目以及异步复制场景提供了总体解决方案，奠基了项目的核心内容。

跨数据库（数据源）迁移

yugong

去Oracle数据迁移同步工具。定位：数据库迁移（目前主要支持Oracle->mysql/DRDS）

08年左右，阿里巴巴开始尝试MySQL的相关研究，并开发了基于MySQL分库分表技术的相关产品，Cobar/TDDL(目前为阿里云DRDS产品)，解决了单机Oracle没法知足的扩展性问题，当时也掀起一股去IOE项目的浪潮，愚公这项目所以而诞生，其要解决的目标就是帮助用户完成从Oracle数据迁移到MySQL上，完成去IOE的第一步.

概述

整个数据迁移过程，分为两个部分：

全量迁移
增量迁移

过程描述：

增量数据收集（建立Oracle表的增量物化视图）
进行全量复制
进行增量复制（可并行进行数据校验）
原库停写，切换到新库

Oracle全量基于JDBC拉取数据，增量基于物化视图来实现。

架构

说明：

一个JVM Container 对应多个instance，每一个instance对应于一张表的迁移任务
instance分为三部分
- extractor (从数据源库上提取数据，可分为全量/增量实现)
- translator （将源库上的数据按照目标库的需求进行自定义转化）
- applier（将数据更新到目标库，可分为全量/增量/对比的实现）

自定义数据转换

若是要迁移的Oracle和mysql的表结构不一样，好比表名，字段名有差别，字段类型不兼容，须要使用自定义数据转换。若是彻底相同则能够跳过。

整个数据流为：DB->Extractor->DataTranslator->Applier->DB, 本程序预留DataTranslator接口（仅支持Java），容许外部用户自定义数据处理逻辑。好比：

表名不一样
字段名不一样
字段类型不一样
字段个数不一样
运行过程join其余表的数据作计算等

运行模式介绍

1.MARK模式（MARK）

开启增量日志模式，若是是Oracle就是建立物化视图（materialized view）。

2.CLEAR模式（CLEAR）

清理增量日志的概率，若是是Oracle就是删除物化视图

3.全量模式（FULL)

全量模式，顾名思议即为对源表进行一次全量操做，遍历源表全部的数据后，插入目标表.

全量有两种处理方式：

分页处理：若是源表存在主键，只有一个主键字段，而且主键字段类型为Number类型，默认会选择该分页处理模式. 优势：支持断点续作，对源库压力相对较小。缺点：迁移速度慢
once处理：经过select * from访问整个源表的某一个mvcc版本的数据，经过cursor.next遍历整个结果集. 优势：迁移速度快，为分页处理的5倍左右。缺点：源库压力大，若是源库并发修改量大，会致使数据库MVCC版本过多，出现栈错误. 还有就是不支持断点续作.

4.增量模式（INC）

全量模式，顾名思议即为对源表增量变化的数据插入目标表，增量模式依赖记录日志功能.

目前增量模式的记录日志功能，是经过oracle的物化视图功能。

5.自动模式(ALL)

自动模式，是对全量+增量模式的一种组合，自动化运行，减小操做成本.

自动模式的内部实现步骤：

开启记录日志功能. (建立物化视图)
运行全量同步模式. (全量完成后，自动进入下一步)
运行增量同步模式. (增量模式，没有完成的概念，因此也就不会自动退出，须要业务判断是否能够退出，能够看一下切换流程)

6.对比模式(CHECK)

对比模式，即为对源库和目标库的数据进行一次全量对比，验证一下迁移结果. 对比模式为一种可选运行，作彻底量/增量/自动模式后，可选择性的运行对比模式，来确保本次迁移的正确性.

DataX

DataX是一个在异构的数据库/文件系统之间高速交换数据的工具，实现了在任意的数据处理系统(RDBMS/Hdfs/Local filesystem）之间的数据交换。

目前成熟的数据导入导出工具比较多，可是通常都只能用于数据导入或者导出，而且只能支持一个或者几个特定类型的数据库。

这样带来的一个问题是，若是咱们拥有不少不一样类型的数据库/文件系统(Mysql/Oracle/Rac/Hive/Other…)，而且常常须要在它们之间导入导出数据，那么咱们可能须要开发/维护/学习使用一批这样的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。并且之后每增长一种库类型，咱们须要的工具数目将线性增加。(当咱们须要将mysql的数据导入oracle的时候，有没有过想从jdbcdump和dbloader上各掰下来一半拼在一块儿到冲动？)这些工具备些使用文件中转数据，有些使用管道，不一样程度的为数据中转带来额外开销，效率差异很很是大。不少工具也没法知足ETL任务中常见的需求，好比日期格式转化，特性字符的转化，编码转换。另外，有些时候，咱们但愿在一个很短的时间窗口内，将一份数据从一个数据库同时导出到多个不一样类型的数据库。DataX正是为了解决这些问题而生。

左图：新增第n+1个数据源，是否是须要开发n个数据同步工具？
右图：只须要针对新增的数据源开发一套Reader/Writer插件，便可实现任意数据的互导。

设计理念

为了解决异构数据源同步问题，DataX将复杂的网状的同步链路变成了星型数据链路，DataX做为中间传输载体负责链接各类数据源。当须要接入一个新的数据源的时候，只须要将此数据源对接到DataX，便能跟已有的数据源作到无缝数据同步。

DataX在阿里巴巴集团内被普遍使用，承担了全部大数据的离线同步业务，并已持续稳定运行了6年之久。目前天天完成同步8w多道做业，每日传输数据量超过300TB。

框架设计

DataX自己做为离线数据同步框架，采用Framework+plugin架构构建。将数据源读取和写入抽象称为Reader/Writer插件，归入到整个同步框架中。

Reader： Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework.
Writer：Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端
Framework：Framework用于链接reader和writer,做为二者的数据传输通道，并处理缓存，流控，并发，数据转换等核心技术问题。

DataX框架内部经过双缓冲队列、线程池封装等技术，集中处理了高速数据交换遇到的问题，提供简单的接口与插件交互，插件分为Reader和Writer两类，基于框架提供的插件接口，能够十分便捷的开发出须要的插件。好比想要从oracle导出数据到mysql，那么须要作的就是开发出OracleReader和MysqlWriter插件，装配到框架上便可。而且这样的插件通常状况下在其余数据交换场合是能够通用的。

核心架构

DataX3.0 开源版本支持单机多线程模式完成同步做业运行，这里按一个DataX做业生命周期的时序图，从总体架构设计很是简要说明DataX各个模块相互关系。

核心模块介绍：

DataX完成单个数据同步的做业，咱们称之为Job，DataX接受到一个Job以后，将启动一个进程来完成整个做业同步过程。DataX Job模块是单个做业的中枢管理节点，承担了数据清理、子任务切分(将单一做业计算转化为多个子Task)、TaskGroup管理等功能。
DataXJob启动后，会根据不一样的源端切分策略，将Job切分红多个小的Task(子任务)，以便于并发执行。Task即是DataX做业的最小单元，每个Task都会负责一部分数据的同步工做。
切分多个Task以后，DataX Job会调用Scheduler模块，根据配置的并发数据量，将拆分红的Task从新组合，组装成TaskGroup(任务组)。每个TaskGroup负责以必定的并发运行完毕分配好的全部Task，默认单个任务组的并发数量为5。
每个Task都由TaskGroup负责启动，Task启动后，会固定启动Reader—>Channel—>Writer的线程来完成任务同步工做。
DataX做业运行起来以后， Job监控并等待多个TaskGroup模块任务完成，等待全部TaskGroup任务完成后Job成功退出。不然，异常退出，进程退出值非0。

DataX调度流程：

举例来讲，用户提交了一个DataX做业，而且配置了20个并发，目的是将一个100张分表的mysql数据同步到odps里面。 DataX的调度决策思路是：\1. DataXJob根据分库分表切分红了100个Task。\2. 根据20个并发，DataX计算共须要分配4个TaskGroup。\3. 4个TaskGroup平分切分好的100个Task，每个TaskGroup负责以5个并发共计运行25个Task。

博客已转移至 http://blog.yemou.net/

数据库相关中间件介绍