数据推送方法和系统的制作方法
【专利摘要】本发明涉及一种数据推送方法和系统。该数据推送方法包括：抽取任务创建处理，以数据库实例为边界将数据从源端数据库转储到数据库增量日志解析服务器中，通过数据库增量日志解析获得增量数据，并且将获得的增量数据暂存于数据库增量日志解析服务器的内存中；消息分发处理，将获得的增量数据按照需要的规则以相应的主题和标记作为消息分发到分布式消息队列服务器中的相应的一个或多个消息队列中，主题代表逻辑的库名，标记代表逻辑的表名，每条作为消息被分发的增量数据都包括相应的主题和标记；以及订阅推送处理，分布式消息队列服务器基于订阅端的各个订阅任务订阅的主题而将所述一个或多个消息队列推送到订阅端。
【专利说明】数据推送方法和系统
【技术领域】
[0001]本发明涉及基于数据库增量日志解析的大规模数据流实时消费技术，更具体地，涉及一种数据推送方法和系统。
【背景技术】
[0002]随着公司业务的发展，对于大规模的数据抽取的需求越发强烈。数据抽取是指从源端数据库抽取需要的数据。实际应用中，源端数据库较多采用的是关系数据库。常见的数据抽取方式包括:(一)全量数据抽取，全量数据抽取类似于数据迁移或数据复制，它将源端中的表或视图的数据原封不动的从数据库中抽取出来；(二)增量数据抽取，增量数据抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。增量数据抽取较全量数据抽取应用更广。如何捕获变化的数据是增量数据抽取的关键。对捕获方法一般有两点要求:准确性，能够将业务系统中的变化数据准确地捕获到；性能，尽量减少对业务系统造成太大的压力，影响现有业务。
[0003]在传统的定时转储(dump)增量数据的方式已不能满足需求的情况下，实时增量数据的获取成为了解决这一问题的趋势。数据推送平台是一套实现异构数据库间实现增/全量的数据推送的完整解决方案。增量推送旨在解决大规模下高效稳定的推送增量数据给订阅客户端以满足业务需求的目的。
[0004]传统的增量数据的抽取方式是定时转储增量数据生成相应的数据文件，但这种方式存在以下问题:需要在源端业务表增加时间戳字段，一定程度上污染了源端业务表；定时执行导致数据存在一定程度的延时；转储出来的数据文件和业务关联过紧，不易被重用；定时任务启动时往往对源端数据库和网络造成较大的瞬时压力。
[0005]而基于数据库增量日志解析的增量数据流很好地解决了上述问题，能够对源端业务表无侵入，增量数据的准实时(只要订阅端消费速度够快)，按需抽取及订阅数据，h散，不易出现瞬时峰值。例如，现有技术中采用的canal开源项目就是基于数据库增量日志解析，并提供了增量订阅和消费功能。canal能够很好的实现数据库增量日志解析工作，基于canal的功能，我们可以通过配置抽取任务从源端抽取增量数据暂存于内存，然后根据业务需求开发定制的订阅客户端。
[0006]图1示意性地图示了根据现有技术的数据推送系统的视图。现有技术的数据推送系统100包括:源端数据库101 ;数据库增量日志解析服务器103，基于数据库增量日志解析，提供增量订阅和消费功能，数据库增量日志解析服务器103例如canal服务器；订阅端105，用于产生订阅任务。
[0007]虽然canal提供了增量数据解析的基本功能，但仍然面临以下几个问题:
[0008](I).数据抽取与数据订阅无法实现一对多
[0009]因为canal增量数据不落地(即，数据暂存于内存)的设计所限，canal无法做到只抽取一次数据而被多客户端订阅。这也就意味着抽取和订阅必须成对出现，过多的抽取任务加大了抽取源端数据库的压力、浪费了大量的网络流量、降低了单台canal服务器的承载能力和吞吐量。
[0010](2).增量数据保存时间不受控
[0011]此问题也和上述设计有关，因为增量数据不落地，且源端数据库的日志保存时间不能由数据推送平台控制，所以数据推送平台也无法对下游的订阅端承诺增量数据保存期限。这也降低了数据推送平台对外提供服务的能力。
[0012](3).订阅端与抽取端依赖过强
[0013]这里的依赖分为两方面。
[0014]系统层面:抽取端与订阅端是基于长连接下的串行处理，订阅端的消费速度直接影响抽取端的抽取速度。
[0015]业务层面:抽取端任务是以数据库实例为边界的，无法对订阅端屏蔽源端分库分表等订阅端本不该关心的信息，也就导致了抽取任务和订阅任务间更强的耦合。
[0016](4).订阅端缺少常用功能支持
[0017]canal本身只专注与数据的抽取与订阅，而对于订阅端一些常用的功能支持较弱，比如:虽然通过canal的订阅端SDK (Software Development Kit:软件开发工具包)可以获取增量的结构体数据，但对于将结构体数据解析、转化成相应DML (Data Manipulat1nLanguage:数据操纵语言)并最终插入目标DB (Database:数据库)这种最常见的应用场景支持不足。另一个开源项目otter(项目的开源链接地址:https://github.com/alibaba/otter)虽然支持上述的部分功能，但仍然无法满足复杂灵活的定制需求。
【发明内容】
[0018]根据本发明的一个方面，提供了一种数据推送方法，包括:抽取任务创建处理，以数据库实例为边界将数据从源端数据库转储到数据库增量日志解析服务器中，通过数据库增量日志解析获得增量数据，并且将获得的增量数据暂存于数据库增量日志解析服务器的内存中；消息分发处理，将获得的增量数据按照需要的规则以相应的主题和标记作为消息分发到分布式消息队列服务器中的相应的一个或多个消息队列中，主题代表逻辑的库名，标记代表逻辑的表名，每条作为消息被分发的增量数据都包括相应的主题和标记；以及订阅推送处理，分布式消息队列服务器基于订阅端的各个订阅任务订阅的主题而将所述一个或多个消息队列推送到订阅端。
[0019]根据本发明的另一方面，提供了一种数据推送系统，包括:源端数据库；数据库增量日志解析服务器；分布式消息队列服务器；和订阅端，其中，以数据库实例为边界将数据从源端数据库转储到数据库增量日志解析服务器中，数据库增量日志解析服务器通过数据库增量日志解析获得增量数据，并且将获得的增量数据暂存于数据库增量日志解析服务器的内存中；数据库增量日志解析服务器将获得的增量数据按照需要的规则以相应的主题和标记作为消息分发到分布式消息队列服务器中的相应的一个或多个消息队列中，主题代表逻辑的库名，标记代表逻辑的表名，每条作为消息被分发的增量数据都包括相应的主题和标记；以及分布式消息队列服务器基于订阅端的各个订阅任务订阅的主题而将所述一个或多个消息队列推送到订阅端。
[0020]本发明通过引入持久化消息队列手段，可以实现只抽取一次数据而被多客户端订阅，也就是说抽取和订阅不必成对出现，从而也极大的降低了网络的流量，使得增量数据被多订阅端消费成为可能，极大的提高了服务器的承载能力及使用效率。此外，订阅端通过使用基于RocketMQ client封装后的专用SDK，可以实现订阅端的定制开发，从而满足复杂灵活的定制需求。
【专利附图】
【附图说明】
[0021]图1示意性地图示了根据现有技术的数据推送系统的视图。
[0022]图2示意性地图示了根据本发明的实施例的数据推送系统的视图。
[0023]图3示意性地图示了根据本发明的实施例的数据推送方法的流程图。
【具体实施方式】
[0024]下面将参照附图详细解释根据本发明的实施例的技术方案。
[0025]术语“转储”(“dump”)含义是指将MySQL里的数据(可含数据结构)导出成文本文件，以便在在其它数据库实例上导入或者作为其它应用或系统的输入数据。
[0026]图2示意性地图示了根据本发明的实施例的数据推送系统的视图。如图2所示，数据推送系统200包括:源端数据库201，数据库增量日志解析服务器203，分布式消息队列服务器205，订阅端207。出于说明的目的，图2中仅图示了三个消息队列1、2、3和分别与之相对应的三个订阅任务1、2、3，但是本领域技术人员理解，本发明不限于此，可以有更多或更少的消息队列和订阅任务。
[0027]源端数据库201不限于某种特定类型数据库，例如可以是MySQL数据库。“MySQL”是一个开放源码的小型关联式数据库管理系统。
[0028]数据库增量日志解析服务器203用于基于数据库增量日志解析，提供增量订阅和消费功能。数据库增量日志解析服务器203例如可以是canal服务器。“canal”是基于MySQL数据库增量日志解析，提供增量数据订阅和消费功能。canal项目的开源链接地址:https://github.com/alibaba/canal。
[0029]分布式消息队列服务器205用于提供分布式、持久化消息队列服务，其具有保证消息的顺序以及消息持久化的特点，从而可以满足增量数据的特点(强顺序)以及持久化(persistence)需求的特点。可根据部署分布式消息队列服务器205磁盘大小情况对外承诺数据的保留天数，只要数据在保留的有效期内订阅端可以从任意位置消费数据。分布式消息队列服务器205例如可以是RocketMQ服务器。“RocketMQ”是一款分布式、队列模型的消息中间件，具有以下特点:支持严格的消息顺序；支持主题(Topic)与队列(Queue)两种模式；亿级消息堆积能力；比较友好的分布式特性；同时支持推(Push)与拉取(Pull)方式消费消息。RocketMQ 项目的开源链接地址:https://github.com/alibaba/RocketMQ。通过上述例如RocketMQ的分布式消息队列中间件的引入，大大提高了系统的扩展性，可以根据业务数据量的大小及时调整增量数据在不同分布式消息队列服务器上的分布情况，以达到快速扩展的目的。术语“中间件”是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。
[0030]订阅端207，用于产生订阅任务。虽然图2示意性地图示了一个订阅端207订阅了三个订阅任务1、2、3，但是本领域技术人员理解，本发明不限于此，订阅端的数目可以是一个或多个，并且每个订阅端的订阅任务可以是一个或多个。如果订阅端207是最常见的数据库推送场景，只需做一些最简单的订阅配置(如订阅的主题及目标DB)即可启动订阅端207而无需再做开发。如果订阅端207需要定制开发，那么可使用基于例如RocketMQclient封装后的专用SDK，指定好订阅主题后即可获得增量数据。多个订阅端可同时订阅相同主题的增量数据，且相互之间没有影响。通过开发通用的模块供订阅端使用，可以达到降低订阅端开发及维护成本的目的。通用模块的的开发使得订阅端在常见场景下的开发成本大大降低，并使得订阅端与抽取端解耦，不必感知抽取端的分库分表信息，使整体方案更易于扩展。通过模块化设计及对抽取订阅任务有效的边界划分，配合现有的自动化部署系统，可方便的对订阅抽取任务进行管理维护，大大降低对线上的运维工作量。
[0031]图3示意性地图示了根据本发明的实施例的数据推送方法的流程图。
[0032]如图3所示，在步骤301中，数据库增量日志解析服务器203创建抽取任务，以数据库实例为边界将数据从源端数据库201转储到数据库增量日志解析服务器203中，数据库增量日志解析服务器203通过数据库增量日志解析获得增量数据，并且将获得的增量数据暂存于数据库增量日志解析服务器203的内存中。
[0033]在步骤303中，数据库增量日志解析服务器203将获得的增量数据按照需要的规则以相应的主题和标记作为消息分发到分布式消息队列服务器205中的消息队列1、2、3中，每条作为消息的增量数据都包含各自的主题和标记以便订阅端207订阅和过滤，所述主题代表逻辑的库名，所述标记代表逻辑的表名。这里所说的需要的规则是指源增量数据的库表信息到队列主题及标记的映射规则，最常见的应用场景是源端进行了分库分表，如库名:product_pop_l、product_pop_2….product_pop_N 会映射到队列的 product_pop 主题，同理，表名sku_N被映射到标记sku。这种规则可根据业务需要自由定义。
[0034]在步骤305中，分布式消息队列服务器205基于订阅端207的各个订阅任务1、2、3订阅的主题而将消息队列1、2、3推送到订阅端207。
[0035]过去的抽取任务并不是以数据库实例为单位的，是以一组业务相关的逻辑库表为单位的，一个数据库实例上会有很多的逻辑库表，所以过去的抽取任务会在一个数据库实例上根据业务库表组的个数开启多个抽取数据的连接。这也就是图1中源端数据库101和数据库增量日志解析服务器103的连接(转储1-3)有3个，而图2中的源端数据库201和数据库增量日志解析服务器203的连接只有I个的原因。与之对比，根据本发明上述实施例的数据推送系统和方法，通过使得增量数据的推送使用持久化消息队列手段，因为抽取任务的创建以数据库实例为边界，相比过去的抽取任务方式，直接降低了源端数据库的压力，从而由如图1示意性地图示3个(实际应用场景中为几十甚至上百的)转储链接减少为如图2所示的I个，而且抽取和订阅不必再成对出现，从而也极大的降低了网络的流量，使得增量数据被多订阅端消费成为可能，极大的提高了服务器的承载能力及使用效率。
[0036]上述实施例仅是本发明的优选实施例，并不用于限制本发明。对本领域技术人员显而易见的是，在不脱离本发明的精神和范围的情况下，可以对本发明的实施例进行各种修改和改变。因此，本发明意在涵盖落入如权利要求所限定的本发明的范围之内的所有这样的修改或变型。
【权利要求】
1.一种数据推送方法，包括: 抽取任务创建处理，以数据库实例为边界将数据从源端数据库转储到数据库增量日志解析服务器中，通过数据库增量日志解析获得增量数据，并且将获得的增量数据暂存于数据库增量日志解析服务器的内存中； 消息分发处理，将获得的增量数据按照需要的规则以相应的主题和标记作为消息分发到分布式消息队列服务器中的相应的一个或多个消息队列中，主题代表逻辑的库名，标记代表逻辑的表名，每条作为消息被分发的增量数据都包括相应的主题和标记；以及 订阅推送处理，分布式消息队列服务器基于订阅端的各个订阅任务订阅的主题而将所述一个或多个消息队列推送到订阅端。
2.根据权利要求1所述的数据推送方法， 其中，所述源端数据库是MySQL数据库，所述数据库增量日志解析服务器是canal服务器，并且所述分布式消息队列服务器是RocketMQ服务器。
3.根据权利要求2所述的数据推送方法， 其中，所述订阅端是通过使用基于RocketMQ client封装后的专用SDK而定制开发。
4.一种数据推送系统，包括: 源端数据库； 数据库增量日志解析服务器； 分布式消息队列服务器；和 订阅端， 其中， 以数据库实例为边界将数据从源端数据库转储到数据库增量日志解析服务器中，数据库增量日志解析服务器通过数据库增量日志解析获得增量数据，并且将获得的增量数据暂存于数据库增量日志解析服务器的内存中； 数据库增量日志解析服务器将获得的增量数据按照需要的规则以相应的主题和标记作为消息分发到分布式消息队列服务器中的相应的一个或多个消息队列中，主题代表逻辑的库名，标记代表逻辑的表名，每条作为消息被分发的增量数据都包括相应的主题和标记；以及 分布式消息队列服务器基于订阅端的各个订阅任务订阅的主题而将所述一个或多个消息队列推送到订阅端。
5.根据权利要求4所述的数据推送系统， 其中，所述源端数据库是MySQL数据库，所述数据库增量日志解析服务器是canal服务器，并且所述分布式消息队列服务器是RocketMQ服务器。
6.根据权利要求5所述的数据推送系统， 其中，所述订阅端是通过使用基于RocketMQ client封装后的专用SDK而定制开发。
【文档编号】G06F17/30GK104408132SQ201410706244
【公开日】2015年3月11日 申请日期:2014年11月28日 优先权日:2014年11月28日
【发明者】秦宝齐, 罗元旺 申请人:北京京东尚科信息技术有限公司, 北京京东世纪贸易有限公司