数据库中间件技术摘要学习

解决的问题

数据库相关平台主要解决以下三个方面的问题

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

数据库架构图

上图的讲解

最上层的是分布式数据库分表分库中间件，读写分离，水平扩容 –》代表中间件有（Cobar，Mycat，tddl，drds，ddb）
增量数据订阅和消费，用户对数据库操作，比如DML DDL DCL操作，中间件可以监控这些操作所产生的增量数据。典型代表Canal，根据MySQL的binlog实现。也有针对Oracle(redolog)的增量数据订阅与消费的中间件有 Canal，erosa
数据库同步中间件涉及数据库之间的同步操作，可以实现跨（同）机房同步以及异地容灾备份、分流等功能。可以涉及多种数据库，处理之后的数据也可以以多种形式存储。（Otter, JingoBus, DRC）
数据库与数据库之间会有数据迁移（同步）的动作，同款数据同步原理比较简单，比如MySQL主备同步，只要在数据库层进行相应的配置既可，但是跨数据库同步就比较复杂了，比如Oracle->MySQL. 数据迁移一般包括三个步骤：全量复制，将原数据库的数据全量迁移到新数据库，在这迁移的过程中也会有新的数据产生；增量同步，对新产生的数据进行同步，并持续一段时间以保证数据同步；原库停写，切换新库。将“跨数据库”这个含义扩大一下——“跨数据源”，比如HDFS, HBase, FTP等都可以相互同步。（yugong, DataX）

数据库中间件举例

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

分布式数据库

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

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

Mycat

这里就不对Cobar做介绍了，目前来看Cobar的发起人的离职导致维护也停止了，整个开发不算完备所以直接跳过，介绍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语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成）
- 事务是弱XA含义：分布式事务处理（ Distributed Transaction Processing ， DTP ）指一个程序或程序段，在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）
- MyCAT的原理中最重要的一个动词是“拦截”，它拦截了用户发来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析，路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户
- MyCAT对自身不支持的SQL语句提供了一种解决方案——在要执行的SQL语句前添加额外的一段由注解SQL组织的代码，这样SQL就能正确执行，这段代码称之为“注解”。注解的使用相当于对MyCAT不支持的SQL语句做了一层透明代理转发，直接交给目标的数据节点进行SQL语句执行。
- MyCAT自身有类似其他数据库的管理监控方式，可以通过MySQL命令行，登录管理端口（9066）执行相应的SQL进行管理，也可以通过jdbc的方式进行远程连接管理
高可用（HA）

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的缺点

我能想到的就是他是具有浓厚java基因的产品

数据增量订阅与消费

增量订阅和消费模块应当包括binlog日志抓取，binlog日志解析，事件分发过滤（EventSink），存储（EventStore）等主要模块。

如果需要确保HA可以采用Zookeeper保存各个子模块的状态，让整个增量订阅和消费模块实现无状态化，当然作为consumer(客户端)的状态也可以保存在zk之中。

整体上通过一个Manager System进行集中管理，分配资源。

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控制。

数据库同步

关于数据库同步这里就贴出相应的技术栈，后期会单独开文章讲解，目前接触的就是mycat和canal

名称	otter	异地双活数据架构基础设施DRC	JD多中心交易系统
原理	基于Canal开源产品，获取数据库增量日志数据典型管理系统架构manager(Web管理)+node(工作节点)manager行时推送同步配置到node节点node节点将同步状态反馈到manager上基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作。	所谓异地双活主要关注两件事，一个数据同步，一个数据分发。异地双活重点做了几件事。一个是热插拔，可以做到在业务高峰时增加节点，高峰过了把增加的节点关闭。做到这个的一个关键是流量实时切换，DRC可以在20秒以内把一个单元（region）的流量迁移到另一个单元。另一个是数据实时恢复，就是通过一定的冗余设计，一旦一个单元挂掉了，可以在另一个单元做全量恢复	多中心交易系统通过数据总线JingoBus进行快速数据交换，同步性能是mysql的3倍以上，而且可用性高，架构灵活。其中，全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题，实现了高性能、低延时、健壮的数据同步机制
作用	异构库 mysql->mysql、oracle. (目前开原版只支持mysql增量，目标库可以是mysql或者oracle,取决于canal的功能) 单机房同步（数据库之间RTT(Round-Trip Time)<1ms）数据库版本升级数据表迁移异步二级索引双向同步文件同步	异地多活中DRC的核心能力就是在低延迟，一致性和高可用一致性：基于日志流式抓取、回放库表结构变更、基于事务的冲突检测。低延迟：最大延迟不超过1s, 消息协议优化，三级数据存储，预读优化IO, 多连接复用和传输压缩，高效的并发复制算法。高可用：主备切换，拓扑变化，心跳跟踪，多维度容灾。	Replicator直接连接Relay，消费Relay内存队列中的事务日志。但有些情况下，因为网络抖动、目标库的负载过高等因素，可能导致Replicator相对Relay落后很多。另外，当新的消费端加入同一数据源的订阅者时，新消费端有冷启动的问题。为了避免重新从数据源做全量快照，Snapshot作为Relay的一个特殊消费端，通过一种高吞吐的消费方式，从Relay源源不断的消费在线事务日志，通过对事务日志的有效处理，最终保存了数据源的一份一致快照(Consistent Snapshot)，即包括了数据源库表中每一行的最新状态的快照，同时保留了一段比Relay buffer更旧的事务日志(Log Store)。由此看来，数据总线作为一个数据层的通用CDC组件，对于多中心交易项目以及异步复制场景提供了整体解决方案，奠定了项目的核心内容。
拓展	Otter调度模型：batch处理+双节点部署。 Otter数据入库算法 Otter双向回环控制 Otter数据一致性 Otter高可用性 Otter扩展性	Otter与DRC的区别：- Otter是阿里B2B的产品，DRC是阿里技术保障团队的产品- Otter是针对MySQL的，DRC可以支持多种类型的数据源- DRC从业务上进行了划分，可以实现单元内封闭，Otter的实现不涉及业务，而是在纯数据库层打通的技术- Otter是双写，DRC是中心写、分中心读，或者都部分写，相互同步。- Otter所处的网络环境较DRC差，解决一致性问题也较复杂（基于trusted source的单向环回的补救，基于时间交集的补救），DRC有两种实现方式，具体参考上面。	系统包括一个主中心和多个分中心，主中心与分中心之间通过数据总线交换数据。数据流向中，主数据(商品数据、商家数据、用户数据等)的流向从主中心通过数据总线实时同步到分中心，分中心只读；而交易数据(订单数据)的流向从分中心实时同步到主中心；在故障时，会从分中心转移到主中心。在这个系统中，有多处体现分流的概念。通过分流，将用户分配到相应的分中心，一方面响应速度快，用户体验更好，不用跨地域访问数据中心了；另一方面，每个中心服务一定数量的用户，水平扩展性好，也能支撑更大的交易规模了。当然，多数据中心不能盲目干活，还考虑到容灾备份的问题。（支付宝光纤事件）交易系统包括应用和数据部分，应用部分是无状态的，就是说，这些工作是无差别的，一台服务器出问题，我换一台服务器来处理就是了，较容易实现多机房多活。但是数据不一样，多中心交易本质上是一个更大的分布式系统，必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。另外，交易流程中依赖和产生的数据和服务有不同的特点。比如商品、促销和价格、库存的读服务，我们可以将之称为基础主数据，它们在用户下单流程中是无法分区的，否则无法实现单机房内流量闭环，也就是说，不能因为分区数据的不一致，导致同一用户在单一流程中看到不同的数据,数据的问题表现在以下几个方面：一、如何保证数据的即时性和准确性，多中心之间需要同步卖家数据和商品数据，由于是异地部署，最好延时能控制在1秒内。数据正确性也是很大的挑战,因为数据故障跟应用层故障不一样，应用出故障了，可能只影响用户访问；数据写错了无法恢复。2、如何保证路由规则的一致性，要保障这个用户从进来到访问服务，到访问数据库，全链路的路由规则都是完全一致的；如果路由错误，看到的数据不正确。从同城双机房的分布转变为异地多机房的分布，给数据同步带来了新的挑战，因此如何设计数据总线也是项目能否实现的关键因素。通过数据总线JingoBus进行快速数据交换，同步性能是mysql的3倍以上，而且可用性高，架构灵活。其中，全新的总线设计解决了多中心交易跨机房的数据库复制和多数据源间的数据异构同步等难题，实现了高性能、低延时、健壮的数据同步机制。

参考链接

数据库迁移

yugong

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

全量迁移
增量迁移

过程描述：

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

DataX

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

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

这样带来的一个问题是，如果我们拥有很多不同类型的数据库/文件系统(Mysql/Oracle/Rac/Hive/Other…)，并且经常需要在它们之间导入导出数据，那么我们可能需要开发/维护/学习使用一批这样的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以后每增加一种库类型，我们需要的工具数目将线性增长。(当我们需要将mysql的数据导入oracle的时候，有没有过想从jdbcdump和dbloader上各掰下来一半拼在一起到冲动？)这些工具有些使用文件中转数据，有些使用管道，不同程度的为数据中转带来额外开销，效率差别很非常大。很多工具也无法满足ETL任务中常见的需求，比如日期格式转化，特性字符的转化，编码转换。另外，有些时候，我们希望在一个很短的时间窗口内，将一份数据从一个数据库同时导出到多个不同类型的数据库。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。