数据库中间件'>数据库中间件这里主要介绍互联网行业内有关数据库的相关中间件。数据库相关平台主要解决以下三个方面的问题: 为海量前台数据提供高性能、大容量、高可用性的访问 为数据变更的消费提供准实时的保障 高效的异地数据同步应用层通过分表分库中间件访问数据库,包括读操作(Select)和写操作(update, insert和delete等,DDL, DCL)。写操作会在数据库上产生变更记录,MySQL的变更记录叫binlog, Oracle的称之为redolog, 增量数据订阅与消费中间件解析这些变更,并以统一的格式保存起来,下层应用根据这些数据进行消费应用。当然,在数据库与数据库本身之间也会有数据库迁移的操作,这种操作可以不需要增量数据订阅与消费中间件的数据,而可以自行处理。 数据库中间件有以下几种: 分布式数据库分表分库 数据增量订阅与消费 数据库同步(全量、增量、跨机房、复制) 跨数据库(数据源)迁移整个产品族图如下: 分布式数据库随着互联网产品在体量和规模上日益膨胀,无论是Oracle还是MySQL,都会第一时间面临来自磁盘,CPU和内存等单机瓶颈,为此,产品方除了需要不断购买成本难以控制的高规格服务器,还要面临不断迭代的在线数据迁移。在这种情况下,无论是海量的结构化数据还是快速成长的业务规模,都迫切需要一种水平扩展的方法将存储成本分摊到成本可控的商用服务器上。同时,也希望通过线性扩容降低全量数据迁移对线上服务带来的影响,分库分表方案便应运而生。 分表分库类的中间件主要有两种形式向应用提供服务: 一种是以JDBC的jar包形式为Java应用提供直接依赖,Java应用通过提供的JDBC包实现透明访问分布式数据库集群中的各个分库分表,典型代表网易的DDB和阿里的TDDL. 另一种是为应用部署独立的服务来满足应用分库分表的需求,在这种方式下通过标准JDBC访问Proxy,而Proxy则根据MySQL标准通信协议对客户端请求解析,还原应用SQL请求,然后通过本地访问数据库集群,最后再将得到的结果根据MySQL标准通信协议编码返回给客户端。典型代表阿里的Cobar, Cobar变种MyCAT, 阿里的DRDS,网易的DDB proxy模式以及DDB的私有云模式。CobarCobar 是提供关系型数据库(MySQL)分布式服务的中间件,它可以让传统的数据库得到良好的线性扩展,并看上去还是一个数据库,对应用保持透明。 Cobar以Proxy的形式位于前台应用和实际数据库之间,对前台的开放的接口是MySQL通信协议。将前台SQL语句变更并按照数据分布规则发到合适的后台数据分库,再合并返回结果,模拟单库下的数据库行为。
Cobar结构HA在用户配置了MySQL心跳的情况下,Cobar可以自动向后端连接的MySQL发生心跳,判断MySQL运行状况,一旦运行出现异常,Cobar可以自动切换到备机工作,但需要强调的是: Cobar的主备切换有两种触发方式,一种是用户手动触发,一种是Cobar的心跳语句检测到异常后自动触发。那么,当心跳检测到主机异常,切换到备机,如果主机恢复了,需要用户手动切回主机工作,Cobar不会在主机恢复时自动切换回主机,除非备机的心跳也返回异常。 Cobar只检查MySQL主备异常,不关心主备之间的数据同步,因此用户需要在使用Cobar之前在MySQL主备上配置双向同步,详情可以参阅MySQL参考手册。Cobar解决的问题分布式:Cobar的分布式主要是通过将表放入不同的库来实现。 Cobar支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分 Cobar也支持将不同的表放入不同的库 多数情况下,用户将以上两种方式混合使用这里需要强调的是,Cobar不支持将一张表,例如test表拆分成test_1, test_2, 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架构HAMyCAT作为一个代理层中间件,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/TDDLalibaba. Distributed Relational Database Service. 阿里分布式数据库DRDS的前身是淘宝分布式数据库层TDDL,大概在2012年的时候,阿里开始尝试将TDDL这套体系输出到阿里云上,也有了一个新的名字:DRDS. TDDLTabao根据自己的业务特点开发了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数据源。
RDRSDRDS/TDDL是阿里巴巴自主研发的分布式数据库服务。DRDS脱胎于阿里巴巴开源的Cobar分布式数据库引擎,吸收了Cobar核心的Cobar-Proxy源码,实现了一套独立的类似MySQL-Proxy协议的解析端,能够对传入的SQL进行解析和处理,对应用程序屏蔽各种复杂的底层DB拓扑结构,获得单机数据库一样的使用体验,同时借鉴了淘宝TDDL丰富的分布式数据库实践经验,实现了对分布式Join支持,SUM/MAX/COUNT/AVG等聚合函数支持以及排序等函数支持,通过异构索引、小表广播等解决分布式数据库使用场景下衍生出的一系列问题,最终形成了完整的分布式数据库方案。 DRDS在整个阿里系统中所处的位置: 对于很多应用而言,单机数据库最终都会碰到单机性能上的天花板,在TPS/QPS/内存容量/磁盘容量等等一系列系统资源上会碰到各类限制。DRDS的主要目标就是帮您解决这方面的各类问题,他主要提供了两个功能,读写分离和数据库切汾喎?'http://www.2cto.com/kf/yidong/wp/' target='_blank' class='keylink'>WPC9zdHJvbmc+OjwvcD4NCrbB0LS31sDro6zE3Lm71MvQ0Mq1z9bSu8you/rG99C0yOujrLbgzKi7+sb3tsHIoaOs1eK21NPatsG24NC0ydm1xNOm08OjrMTcubvS1Lyrtc21xLPJsb694r72z7XNs7XExr++saGjIMr9vt2/4sfQt9bKx9K7uPa94r72z7XNs7TmtKLGv76xtcTX7tbVvKu94r72t72wuKOsyv2+3b/ix9C31rXEusvQxMu8z+vG5Mq1uty88rWlo6y+zcrHt9a2+NbO1q6ho72ryv2+3bfWyaK1vbbgzKi7+sb3o6yyorGj1qTH68fzxNy5u8a9vvm1xLfWt6K1vdXi0Km7+sb3yc+jrL7Nv8nS1NLUvKu1zbXEs8mxvsC0veK+9tK1zvG1xLj3wODQ1MTcxr++saGjtbHIu8fQt9bSssrH09C0+rzbtcSjrNfuw/fP1LXEtPq8277NysejrLfWsrzKvcr9vt2/4rvhttTSu9Cp1K3T0LWlu/rK/b7dtcSzob6wvfjQ0M/e1sajrNLyzqrV4tCpstnX96Os1Nq31rK8yr27t76zz8K1xNHTs9m78tCnwsq3x7Ojtc3Qp6Osvs3L48rHxNy5u8q1z9az9sC0o6zSsrvh0vLOqtDUxNzOyszitvjO3reoyrnTw6GjDQo8cD48aW1nIGFsdD0='' src='http://www.2cto.com/uploadfile/Collfiles/20161010/20161010095420220.png' title='\' /> 其他功能特性 1.分布式MySQL执行引擎 主要目标是实现与单机数据库SQL引擎的完全兼容,实现SQL的智能下推,能够智能分析SQL,解析出那些SQL可以直接下发,那些SQL需要进行优化改造,优化成什么样,以及路由到哪些实例节点上执行,充分发挥数据库实例的全部能力,减少网络之间的数据传输量,最终对不同实例处理后的少量结果进行聚合计算返回给应用调用方。这就是分布式SQL引擎的智能下推功能。 支持市面上几乎所有的语言(具有MySQL访问能力的),兼容90%以上MySQL语法。
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. Heisenberg Baidu. CDS JD. Completed Database Sharding. DDB 猪场. Distributed DataBase. 数据增量订阅与消费基于数据库增量日志解析,提供增量数据订阅&消费,目前主要支持了mysql. CanalCanal架构图: 说明: server代表一个canal运行实例,对应于一个jvm instance对应于一个数据队列 (1个server对应1..n个instance)instance模块: eventParser (数据源接入,模拟slave协议和master进行交互,协议解析) eventSink (Parser和Store链接器,进行数据过滤,加工,分发的工作) eventStore (数据存储) metaManager (增量订阅&消费信息管理器)
数据库同步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)<> 数据库版本升级 数据表迁移 异步二级索引 跨机房同步(比如阿里巴巴国际站就是杭州和美国机房的数据库同步,RTT>200ms) 机房容灾 双向同步 避免回环算法(通用的解决方案,支持大部分关系型数据库) 数据一致性算法(保证双A机房模式下,数据保证最终一直性) 文件同步 站点镜像(进行数据复制的同时,复制关联的图片,比如复制产品数据,同事复制产品图片) 单机房复制示意图说明: SETL S: Select E: Extract T: Transform L: Load 类似于数据仓库的ETL模型,具体可为数据join,数据转化,数据加载。 跨机房复制示意图数据涉及网络传输,S/E/T/L几个阶段会分散在2个或者更多Node节点上,多个Node之间通过zookeeper进行协同工作(一般是Select和Extract在一个机房的Node, Transform/Load落在另一个机房的Node) More:Otter调度模型:batch处理+双节点部署。 Otter数据入库算法 Otter双向回环控制 Otter数据一致性 Otter高可用性 Otter扩展性异地双活数据架构基础设施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)的流量迁移到另一个单元。另一个是数据实时恢复,就是通过一定的冗余设计,一旦一个单元挂掉了,可以在另一个单元做全量恢复。 异地多活在数据方面的挑战是非常大的。双十一期间,交易会激增,所以交易链路做了单元化。交易链路的数据分为三个维度:买家、卖家、商品。买家之间通常没有太多交叉,天然的适应这种隔离,而且卖家对延迟的敏感度非常高,所以按照卖家维度切分,在单元内封闭,而卖家和商品都是在中心写入。 数据方面的两个核心要求: 一致性,要求卖家和商品一致,单元和中心一致,也就是数据同步不能丢数据,不能错数据,还要保证事务。 实时性,需要做到秒级别的延迟。双单元的同步架构有两种: 第二种同步架构是单元封闭的方式。中心和单元各有写入,我们通过冗余是的中心和单元随时可以各自接管。(类似Otter) 这里的关键是: 避免循环复制:通过在DB透传打标事务的方式实现。 限流:峰值的压力,我们单元化本来就选取了流量激增业务,两边都实时同步100%全量数据,峰值对每个系统的压力有增无减。DRC的store和congo都可以根据TPS或者流量限流。限速算法的核心思想分为批量采样,奖惩时间,平滑变速。
异地多活中DRC的核心能力就是在低延迟,一致性和高可用。 JD多中心交易系统JD. 多中心交易系统。
多中心交易本质上是一个更大的分布式系统,交易流程中依赖和产生的数据和服务有不同的特点,必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。 其中,数据一致性是电商网站需要面临的首要问题,越是流量增大的时候越要保证数据更新的即时性和准确性。在多中心之间需要同步卖家数据和商品数据,如果同步的延时太长,买家、卖家都不可接受。比如,卖家改了价格或库存,用户不能过很久才看到。同样,数据正确性也是很大的挑战,卖掉的商品能够及时减少,退货的商品能够及时增加。这都时刻考验着后端系统和数据库平台的健壮性。 除了数据一致性之外,如何保证路由规则的一致性也是关键性的问题。从技术角度来说,要保障单一用户从登录到访问服务、到访问数据库,全链路的路由规则都是完全一致的。如果路由错误,看到的数据不正确,也会影响到最终用户的体验。 架构系统包括一个主中心和多个分中心,主中心与分中心之间通过数据总线交换数据。数据流向中,主数据(商品数据、商家数据、用户数据等)的流向从主中心通过数据总线实时同步到分中心,分中心只读;而交易数据(订单数据)的流向从分中心实时同步到主中心;在故障时,会从分中心转移到主中心。 在这个系统中,有多处体现分流的概念。首先,买家访问京东网站下单时,会被优先分流到附近的交易中心;其次,根据交易系统的特点,接单前(包括购物车、结算页等),多中心交易按用户维度分流,如下图所示。用户登录时,查询用户与区域的映射关系表(类似你是哪个片区的),标识此用户属于哪个分中心,并保存标识到cookie中,然后将用户路由到指定的分中心。用户访问其他系统,如购物车和结算页时,从cookie中读取标识,重定向到相应分中心页面。 通过分流,将用户分配到相应的分中心,一方面响应速度快,用户体验更好,不用跨地域访问数据中心了;另一方面,每个中心服务一定数量的用户,水平扩展性好,也能支撑更大的交易规模了。当然,多数据中心不能盲目干活,还考虑到容灾备份的问题。(支付宝光纤事件) 交易系统包括应用和数据部分,应用部分是无状态的,就是说,这些工作是无差别的,一台服务器出问题,我换一台服务器来处理就是了,较容易实现多机房多活。但是数据不一样,多中心交易本质上是一个更大的分布式系统,必然涉及到数据分区、路由、复制、读写一致性、延迟等分布式领域的常见问题。 另外,交易流程中依赖和产生的数据和服务有不同的特点。比如商品、促销和价格、库存的读服务,我们可以将之称为基础主数据,它们在用户下单流程中是无法分区的,否则无法实现单机房内流量闭环,也就是说,不能因为分区数据的不一致,导致同一用户在单一流程中看到不同的数据(假如你加入购物车时是促销20块,结账是25块,你会不会表情扭曲?)而商品、促销和价格的写服务,是给采销、第三方POP商家应用调用的,这种业务场景的可用性目标,主机房部署和冷备模式即可满足,而且业务人员的操作流程会抵消写复制延迟。 简单来说,数据的问题表现在以下几个方面:一、 如何保证数据的即时性和准确性,多中心之间需要同步卖家数据和商品数据,如果同步的延时太长,买家、卖家都不可接受,由于是异地部署,最好延时能控制在1秒内。比如,卖家改了价格或库存,用户不能过很久才看到。同样,数据正确性也是很大的挑战,因为数据故障跟应用层故障不一样,应用出故障了,可能只影响用户访问;数据写错了无法恢复。2、如何保证路由规则的一致性,要保障这个用户从进来到访问服务,到访问数据库,全链路的路由规则都是完全一致的;如果路由错误,看到的数据不正确。 从同城双机房的分布转变为异地多机房的分布,给数据同步带来了新的挑战,因此如何设计数据总线也是项目能否实现的关键因素。京东的多中心交易系统通过数据总线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)
概述整个数据迁移过程,分为两个部分: 全量迁移 增量迁移过程描述: 增量数据收集(创建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) 对比模式,即为对源库和目标库的数据进行一次全量对比,验证一下迁移结果. 对比模式为一种可选运行,做完全量/增量/自动模式后,可选择性的运行对比模式,来确保本次迁移的正确性. DataXDataX是一个在异构的数据库/文件系统之间高速交换数据的工具,实现了在任意的数据处理系统(RDBMS/Hdfs/Local filesystem)之间的数据交换。 目前成熟的数据导入导出工具比较多,但是一般都只能用于数据导入或者导出,并且只能支持一个或者几个特定类型的数据库。 这样带来的一个问题是,如果我们拥有很多不同类型的数据库/文件系统(Mysql/Oracle/Rac/Hive/Other…),并且经常需要在它们之间导入导出数据,那么我们可能需要开发/维护/学习使用一批这样的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以后每增加一种库类型,我们需要的工具数目将线性增长。(当我们需要将mysql的数据导入oracle的时候,有没有过想从jdbcdump和dbloader上各掰下来一半拼在一起到冲动?)这些工具有些使用文件中转数据,有些使用管道,不同程度的为数据中转带来额外开销,效率差别很非常大。很多工具也无法满足ETL任务中常见的需求,比如日期格式转化,特性字符的转化,编码转换。另外,有些时候,我们希望在一个很短的时间窗口内,将一份数据从一个数据库同时导出到多个不同类型的数据库。DataX正是为了解决这些问题而生。 设计理念为了解决异构数据源同步问题,DataX将复杂的网状的同步链路变成了星型数据链路,DataX作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候,只需要将此数据源对接到DataX,便能跟已有的数据源做到无缝数据同步。
框架设计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的调度决策思路是: |
|