CN116980475A - 一种基于binlog与双环形缓冲区的数据推送系统 - Google Patents

Abstract

本发明公开了一种基于binlog与双环形缓冲区的数据推送系统，涉及数据推送技术领域。该系统包括通信连接且用于采用canal组件对业务数据库的数据变动进行监控，获取binlog并对其进行解析的日志订阅单元、用于对binlog解析数据进行预处理操作，并将获取预处理数据制作成宽表存储的数据预处理单元、用于对预处理数据进行分拣并二次处理而获取待推送任务及将其存入任务库中等待调度的规则引擎及任务调度单元以及用于对调度的待推送任务进行推送处理的数据推送单元。本发明通过对binlog进行即时监听、高效解析以及配置自定义规则，实现统一高效的数据推送；并且在对接平台和业务数据量增多的情况下满足多种推送需求。

Description

一种基于binlog与双环形缓冲区的数据推送系统

技术领域

本发明属于数据推送技术领域，尤其涉及一种基于binlog与双环形缓冲区的数据推送系统。

背景技术

数据推送系统是一种将数据实时或定期地传输给目标用户或应用程序或其他系统的系统，它可以将数据从一个数据源发送到一个或多个目标位置，以满足特定的业务需求。

现有的数据推送系统，除了基本的业务信息数据，几乎每个对接平台都有不同的要求，而不同的要求需要不同的规则去匹配，难以做到统一化的处理；此外，对接平台过多也会导致数据入口增多，进而导致数据埋点遗漏，丢失推送数据，从而无法做到高效的数据推送。因此针对日益增多的数据对接平台及推送需求，急需一种数据推送系统去统一管理所有推送项目，做到高效地满足各方推送需求。

发明内容

本发明的目的在于提供一种基于binlog与双环形缓冲区的数据推送系统，通过对binlog进行即时监听、高效解析以及配置自定义规则，实现统一高效的数据推送，进而在对接平台和业务数据量增多的情况下满足多种推送需求。

本发明的目的可以通过以下技术方案实现：

本申请实施例提供了一种基于binlog与双环形缓冲区的数据推送系统，包括依次通信连接的日志订阅单元、数据预处理单元、规则引擎及任务调度单元和数据推送单元；

所述日志订阅单元，采用canal组件对业务数据库的数据变动进行监控，获取所述业务数据库中的binlog并对其进行解析，获取binlog解析数据；

所述数据预处理单元，用于对所述binlog解析数据进行预处理操作，获取预处理数据，将所述预处理数据制作成宽表进行存储；

所述规则引擎及任务调度单元，用于对所述预处理数据进行分拣，并对分拣后的数据进行二次处理，获取待推送任务；将所述待推送任务存入任务库中等待任务调度中心进行调度；

所述数据推送单元，用于对所述任务调度中心调度的所述待推送任务进行推送处理；

其中，所述业务数据库的数据变动表示为所述业务数据库执行的写入性操作；

其中，所述数据预处理单元包括第一环形缓冲区；所述第一环形缓冲区用于存放所述binlog解析数据；

其中，所述数据推送单元包括多种推送服务，多种所述推送服务支持对接平台的多种推送协议类型；根据多种所述推送协议类型设立多个第二环形缓冲区；多个所述第二环形缓冲区用于存放所述待推送任务。

优选的，所述日志订阅单元包括所述canal组件和所述业务数据库；所述业务数据库包括主服务器和从服务器。

优选的，所述canal组件获取所述binlog并进行解析，包括如下步骤：

S11，所述canal组件模拟所述从服务器的交互协议，伪装成所述从服务器向所述主服务器发送dump协议；

S12，所述主服务器接收所述dump协议并推送所述binlog至所述canal组件；

S13，所述canal组件对所述binlog进行解析，获取所述binlog解析数据；

其中，所述dump协议表示为所述主服务器中用于备份和恢复数据的协议。

优选的，所述数据预处理单元还包括消息队列和所述宽表；所述预处理操作包括数据解析、数据过滤、数据补全和数据打标。

优选的，所述将所述预处理数据制作成宽表进行存储，包括如下步骤：

S21，将所述binlog解析数据投递到所述消息队列中；

S22，将所述消息队列中的所述binlog解析数据放入所述第一环形缓冲区中；

S23，从所述第一环形缓冲区中获取所述binlog解析数据并进行所述预处理操作，获取所述预处理数据；

S24，将所述预处理数据存入所述宽表中；

其中，所述消息队列表示为应用于不同程序之间传递消息的中间件。

优选的，所述规则引擎及任务调度单元包括依次通信连接的规则引擎组件、协议包库、任务库和所述任务调度中心；

所述规则引擎组件，用于将所述预处理数据按照指定规则进行分拣；所述指定规则通过规则编辑器进行配置；

所述协议包库，用于存储不同对接项目的自定义协议包；还用于根据所述自定义协议包对分拣后的数据进行定制化的二次处理，获得所述待推送任务；

所述任务库，用于存储多种所述待推送任务；

所述任务调度中心，用于自定义配置调度规则，并从所述任务库中调度所述待推送任务；

其中，所述调度规则包括定时、间隔和重试机制；

其中，所述待推送任务包括HTTP任务、FTP任务和DB任务。

优选的，所述推送服务包括HTTP推送服务、FTP推送服务和DB推送服务；其中，每个所述推送服务均具有独属线程池。

优选的，对所述待推送任务进行推送处理，包括如下步骤：

S31，将所述待推送任务放入所述第二环形缓冲区中；

S32，从所述第二环形缓冲区中读取所述待推送任务；

S33，从所述独属线程池中获取相应的所述推送服务进行推送；

S34，若推送成功则记录推送日志；若推送失败则由所述任务调度中心再次进行任务调度；

其中，所述第二环形缓冲区在单生产/单消费的模式下为无锁状态；

其中，所述第二环形缓冲区进行内存的预先申请。

优选的，所述数据推送系统还包括由Web控制台程序组成的管理监控单元；所述管理监控单元分别与所述日志订阅单元、所述数据预处理单元、所述规则引擎及任务调度单元和所述数据推送单元通信连接；所述管理监控单元包括项目管理、规则编排、协议包管理、任务调度、推送监控、系统管理和操作审计。

优选的，所述管理监控单元用于监控业务数据量，并根据所述业务数据量管理各单元进行水平扩展。

本发明的有益效果为：

(1)通过对binlog进行即时监听、高效解析以及配置自定义规则，实现统一高效的数据推送，进而在对接平台和业务数据量增多的情况下满足多种推送需求。

(2)本发明在日志订阅单元中利用Canal组件对业务数据库中的binlog进行实时监听，使得在对业务系统代码零入侵的情况下，能够高效捕获数据变动，避免因数据入口过多导致的数据埋点遗漏，以及丢失推送数据，进而以零侵入的方式高效即时的获取数据变动。

(3)本发明的数据预处理单元针对大型系统中binlog日志量巨大，需要进行高效的binlog解析处理的问题，利用环形缓冲区实现对binlog的高效解析，降低了数据预处理的服务内存和CPU的消耗。

(4)本发明的规则引擎及任务调度单元采用基于JSR223的规则引擎，通过配置自定义协议包，实现自定义的规则流转与协议定制；此外，针对数据需要按不同的规则推送给不同的平台这一问题，采用统一化的管理，支持自定义的规则流转和协议处理，避免每一个平台都需要重复对接，提高了业务系统运行效率的同时，也节省了大量的开发成本。

(5)本发明的数据推送单元通过多种推送服务满足了对接平台的不同协议支持，再通过设立多个环形缓冲区以及为每个推送服务设立自己独立的线程池，来提高任务处理速度；通过高效利用服务器内存及处理器性能来降低推送服务内存和CPU的消耗，从而实现数据推送的高效性。

(6)在本发明的数据推送单元中，因为环形缓冲区中一个数据元素被读取出后其余数据元素不需要移动其存储位置，而且环形缓冲区在单生产/单消费的模式下是无锁的；因此相比传统链表而言，环形缓冲区具有更高的性能；并且环形缓冲区的内存是预先申请并且能够进行自我管理，可以避免内存碎片的产生，进而使得申请和释放的效率更快。

(7)本发明通过管理监控单元对各单元的数据量和处理能力进行实时监控，保障了各模块的水平扩展能力，使得各模块可以更好的应对大数据量和高并发的需求，进而降低服务器的性能消耗和开发成本。

附图说明

为了更好地理解和实施，下面结合附图详细说明本申请的技术方案。

图1为本申请实施例提供的一种基于binlog与双环形缓冲区的数据推送系统的结构示意图；

图2为本申请实施例提供的日志订阅单元的结构示意图；

图3为本申请实施例提供的canal组件获取binlog并进行解析的步骤流程图；

图4为本申请实施例提供的数据预处理单元的结构示意图；

图5为本申请实施例提供的将预处理数据制作成宽表存储的步骤流程图；

图6为本申请实施例提供的规则引擎及任务调度单元的结构示意图；

图7为本申请实施例提供的数据推送单元的结构示意图；

图8为本申请实施例提供的对待推送任务进行推送处理的步骤流程图；

图9为本申请实施例提供的管理监控单元的结构示意图。

具体实施方式

为更进一步阐述本发明为实现预定发明目的所采取的技术手段及功效，这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的方法和系统的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

以下结合附图及较佳实施例，对依据本发明的具体实施方式、特征及其功效做详细说明。

本申请基于binlog与双环形缓冲区的技术实现数据的高效推送，以下将对本申请所采用的技术进行简要说明。

关于binlog(binary log，二进制日志)，它是MySQL数据库中一种用于记录数据库变更的日志文件格式。它包含了数据库执行的所有修改操作，例如插入、更新和删除数据等；binlog可以用于数据恢复、备份、主从(主服务器和从服务器)同步以及数据分析等场景。

本实施例中binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中；binlog是MySQL数据库的逻辑日志，并且由Server(服务)层进行记录，使用任何存储引擎的MySQL数据库都会记录binlog日志。

其中，逻辑日志：可以表示为记录的就是sql语句。

物理日志：因为MySQL数据最终是保存在数据页中的，物理日志记录的就是数据的变更。

binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。

关于环形缓冲区(ring buffer)，又称为环形队列(circular queue)，是一种用于表示一个固定尺寸、头尾相连的缓冲区的数据结构，适合缓存数据流。环形缓冲区具有以下使用特点：

(1)当一个数据元素被读取出后，其余数据元素不需要移动其存储位置；

(2)适用于事先明确了缓冲区的最大容量的情形，缓冲区的容量(长度)一般固定，可以用一个静态数组来充当缓冲区，无需重复申请内存；

(3)如果缓冲区的大小需要经常调整，就不适合用环形缓冲区，因为在扩展缓冲区大小时，需要搬移其中的数据，这种场合使用链表更加合适；

(4)因为缓冲区成头尾相连的环形，写入操作可能会覆盖未及时读取的数据，有的场景允许这种情况发生，有的场景又严格限制这种情况发生，而本实施例采用并适用该环形缓冲区。

关于canal，其是一个开源的、基于MySQL数据库事件订阅和数据同步解决方案，是基于MySQL数据库增量日志解析，提供增量数据订阅和消费的工具(本实施例中称为canal组件)，主要用于实时捕获和传输数据库中的数据变更事件，它可以用于MySQL(MyStructured Query Language，关系型数据库管理系统)、Oracle(甲骨文公司)、PostgreSQL(开源的关系型数据库管理系统)等主流数据库。

canal的工作原理如下：

(1)canal模拟MySQL slave(从属服务器)的交互协议，伪装自己为MySQL slave，向MySQL master(主服务器)发送dump协议；

(2)MySQL master收到dump协议，开始推送binlog给伪装成MySQL slave的canal；

(3)canal对binlog进行解析。

其中关于dump协议，它是MySQL数据库中用于备份和恢复数据的一种协议。dump协议定义了一种格式，可以将数据库中的表结构和数据以文本形式进行导出(备份)，或从导出的文本中恢复(恢复)到数据库中，通过dump协议，可以生成包含数据库架构和数据的纯文本SQL脚本。

请参阅图1，本申请实施例提供一种基于binlog与双环形缓冲区的数据推送系统，包括依次通信连接的日志订阅单元、数据预处理单元、规则引擎及任务调度单元和数据推送单元；

所述日志订阅单元，采用canal组件对业务数据库的数据变动进行监控，获取业务数据库中的binlog并对其进行解析，获取binlog解析数据；

所述数据预处理单元，用于对binlog解析数据进行预处理操作，获取预处理数据，将预处理数据制作成宽表进行存储；

所述规则引擎及任务调度单元，用于对预处理数据进行分拣，并对分拣后的数据进行二次处理，获取待推送任务；将待推送任务存入任务库中等待任务调度中心进行调度；

所述数据推送单元，用于对任务调度中心调度的待推送任务进行推送处理；

其中，所述业务数据库的数据变动表示为业务数据库执行的写入性操作；

其中，所述数据预处理单元包括第一环形缓冲区；所述第一环形缓冲区用于存放binlog解析数据；

其中，所述数据推送单元包括多种推送服务，多种推送服务支持对接平台的多种推送协议类型；根据多种推送协议类型设立多个第二环形缓冲区；多个第二环形缓冲区用于存放待推送任务。

在本申请提供的一种实施例中，所述数据推送系统还包括管理监控单元，所述管理监控单元分别与日志订阅单元、数据预处理单元、规则引擎及任务调度单元和数据推送单元通信连接；该管理监控单元用于对上述日志订阅单元、数据预处理单元、规则引擎及任务调度单元和数据推送单元进行管理和监控。

具体地，本申请首先采用canal组件对业务数据库的数据变动进行监控，获取到业务数据库中的binlog并对其进行解析，得到binlog解析数据；紧接着对该binlog解析数据进行预处理操作，获取预处理数据，并将预处理数据制作成宽表进行存储；紧接着对存储在宽表中的预处理数据进行分拣，并对分拣后的数据进行二次处理，获取待推送任务，再将待推送任务存入任务库中等待任务调度中心进行调度；最后对任务调度中心调度的待推送任务进行推送处理。本申请通过对binlog进行即时监听、高效解析以及配置自定义规则，实现统一高效的数据推送，进而在对接平台和业务数据量增多的情况下满足多种推送需求。

其中，上述宽表是指在关系型数据库(如MySQL)中，将多个相关联的表通过联接(Join)操作合并成一个具有更大数量的列的表格；在本实施例中，每个表在数据库中都代表了一个实体或一种数据类型，而宽表则将这些相关的表格合并为一个更宽、更扁平的表格，以便在单个查询中更方便地检索和处理数据：例如：在用户表中存储了用户的姓名、性别、手机号等信息，在与用户表有关联的资料表中则存储了住址、爱好、工作单位等关联信息，将资料表和用户表合并在宽表中，则宽表中除了存储用户表中的姓名、性别、手机号等信息，也会将与其关联的住址、爱好、工作单位等关联信息，一并存储到宽表中。

下面将对上述各个单元做详细说明。

关于日志订阅单元，如图2所示，在本申请提供的一种实施例中，所述日志订阅单元包括canal组件和业务数据库；业务数据库包括主服务器和从服务器。

进一步地，如图3所示，所述canal组件获取binlog并进行解析，包括如下步骤：

S11，canal组件模拟从服务器的交互协议，伪装成从服务器向主服务器发送dump协议；

S12，主服务器接收dump协议并推送binlog至canal组件；

S13，canal组件对binlog进行解析，获取binlog解析数据；

其中，dump协议表示为主服务器中用于备份和恢复数据的协议。

具体地，该日志订阅单元主要进行MySQL业务数据库中数据变动的监控，因为是直接通过canal组件伪装成从服务器对数据库的主服务器发送dump协议而进行的监控，所以对业务系统代码零侵入，而且可以避免因数据入口过多导致的数据埋点遗漏，以及丢失推送数据的问题。

在图3中，主服务器(MySQL Master)内通过Data Changers(也称为数据变更器)将数据库中发生的数据变更情况进行记录，并以二进制形式保存在binlog(二进制日志)中，Data Changers可以将数据库的插入、更新和删除操作记录下来，帮助实现数据的复制和恢复。

在本申请所采用的MySQL的主从复制架构中，主服务器(MySQL Master)将数据变更操作记录在binlog文件中，从服务器(MySQL Slave)则通过解析binlog文件，将这些变更操作应用到自己的数据库中，使得主服务器保持同步。而本申请用canal组件伪装成从服务器对主服务器进行dump请求，从而实现了在对业务系统代码零侵入(无需修改任何业务系统代码)的情况下实时获取到数据的变动。

本申请在日志订阅单元中利用Canal组件对业务数据库中的binlog进行实时监听，使得在对业务系统代码零入侵的情况下，能够高效捕获数据变动，避免因数据入口过多导致的数据埋点遗漏，以及丢失推送数据，进而以零侵入的方式高效即时地获取数据变动。

关于数据预处理单元，如图4所示，在本申请提供的一种实施例中，数据预处理单元除了包括第一环形缓冲区外，还包括消息队列和宽表；所述预处理操作包括数据解析、数据过滤、数据补全和数据打标。

进一步地，如图5所示，将预处理数据制作成宽表进行存储，包括如下步骤：

S21，将binlog解析数据投递到消息队列中；

S22，将消息队列中的binlog解析数据放入第一环形缓冲区中；

S23，从第一环形缓冲区中获取binlog解析数据并进行预处理操作，获取预处理数据；

S24，将预处理数据存入宽表中；

其中，消息队列表示为应用于不同程序之间传递消息的中间件。

具体地，因为与本系统接入的各个接入平台需要的数据字段不尽相同，因此本实施例中需要对binlog解析出的数据进行数据解析、数据过滤、数据补全和数据打标(对数据打上标记)等一系列预处理操作，从而去除binlog解析数据中的一些无效信息，进而补全其中的关联信息，最后将其制作成宽表进行存储。例如：用户表的信息发生了变动，宽表中除了存储用户表中的姓名、性别、手机号等信息外，还会查询其关联的住址、爱好、工作单位等资料表的关联信息，将其一并存储到宽表中。

而关于将预处理数据制作成宽表的具体内容则为：canal组件解析的binlog对象(binlog解析数据)，投递到消息队列中，从而实现binlog的快速消费；为了提高消费速度、高效利用服务器内存及处理器性能，本申请从消息队列消费的binlog中解析数据，并将解析出的数据放入第一环形缓冲区(First Ring Buffer)中，而后数据处理服务从第一环形缓冲区中获取数据进行解析、过滤、补全等预处理操作，最后数据经过处理后将完整的数据信息存入宽表中。在本实施例中该宽表的数据字段可满足90％对接方(平台/系统)的要求。

本申请在数据预处理单元中使用第一环形缓冲区，因为第一环形缓冲区中一个数据元素被读取出后，其余数据元素不需要移动其存储位置，而且第一环形缓冲区在单生产/单消费的模式下，它是无锁的，相比传统链表性能更高；并且第一环形缓冲区中的内存是预先申请的，不需要重复申请，并且该内存可以实现自我管理，因此能够避免产生内存碎片，从而使得在申请和释放的过程中效率更快。

而关于上述消息队列，它是一种在分布式系统中用于异步通信的中间件技术，它允许不同的应用程序或服务通过发送和接收消息来实现解耦与异步处理。在本实施例的Canal组件的配置中，设置目标端为消息队列，配置对应的消息队列的连接信息，如主题(Topic)、集群地址等；当Canal组件解析到binlog中的数据变更事件时，会将这些发生变更的事件转换为消息对象，并通过消息队列的接口发送到指定的主题中。接入平台可以通过订阅该主题进而从消息队列中获取并处理这些binlog数据变更事件。

需要说明的是，在本实施例中消息队列可以采用Kafka和RocketMQ这两种常用于构建高可伸缩性、高吞吐量的数据处理和消息传递系统的分布式消息队列系统。而Kafka是由Apache软件基金会开发的一种分布式事件流平台；RocketMQ是阿里巴巴开源的一种分布式消息队列系统，具有高可靠性、高性能和可伸缩性。

本申请的数据预处理单元针对大型系统中binlog日志量巨大，需要进行高效的binlog解析处理的问题，利用环形缓冲区实现对binlog的高效解析，降低了数据预处理的服务内存和CPU的消耗。

关于规则引擎及任务调度单元，如图6所示，在本申请提供的一种实施例中，规则引擎及任务调度单元包括依次通信连接的规则引擎组件、协议包库、任务库和所述任务调度中心；

所述规则引擎组件，用于将预处理数据按照指定规则进行分拣；指定规则通过规则编辑器进行配置；

所述协议包库，用于存储不同对接项目的自定义协议包；还用于根据自定义协议包对分拣后的数据进行定制化的二次处理，获得待推送任务；

所述任务库，用于存储多种待推送任务；

所述任务调度中心，用于自定义配置调度规则，并从任务库中调度待推送任务；

其中，调度规则包括但不限于定时、间隔和重试机制等；

其中，待推送任务包括但不限于HTTP任务、FTP任务和DB任务等。

具体地，本申请需要把宽表里的数据推送给众多第三方平台中的一个或多个，因此需要有一套规则引擎，针对数据信息和打上标记的信息，对预处理的数据进行“分拣”，分拣后的数据会进行二次处理，并将经过二次处理后得到的数据存入任务库中，进而等待任务调度中心进行调度推送。

关于规则引擎组件，其遵循JSR223标准，可以将数据按指定规则进行分拣，该指定规则通过规则编辑器进行配置。需要说明的是，JSR223(Java Specification Request223，Java规范请求)定义了Java程序与脚本语言之间的互操作性机制，使得Java应用程序可以通过标准的接口与不同的脚本语言进行交互和执行；JSR223的目标是提供一种通用的、标准的方式，使得Java程序可以与多种脚本语言进行互动。

关于协议包库，其包括若干自定义的协议包，如图6中所示的A平台协议包、B平台协议包和C平台协议包以及其他平台协议包。因为不同的对接平台方对数据的要求会有不相同，比如有些对接平台需要数据按其要求进行加密、压缩、验签、增加额外字段等。因此该协议包库的功能为：可以按照不同的对接项目上传并存储自定义协议包。该协议包库针对一些需要对数据进行特殊处理的对接平台。

关于任务库，其主要用于存储多种待推送任务。经过协议包库找那个对协议包的定制化处理，数据被加工成为可直接推送的待推送任务，该待推送任务包括但不限于对接地址、端口、账号、密码、协议、数据等数据推送需要的元素；该待推送任务被放入任务库中等待任务调度中心执行任务调度。

在本实施例中，上述任务库包括但不限于HTTP任务、FTP任务和DB任务等。

关于任务调度中心，其可以自定义的配置调度规则，如定时、间隔和重试机制等；还用于从任务库中拉取待推送任务进行推送。

需要说明的是，本申请中提到的“对接平台”、“对接项目”、“接入平台”以及“第三方平台”等均表示本申请所述的数据推送系统所对接的其他系统/平台，比如公安系统、合作伙伴系统等。

本申请的规则引擎及任务调度单元采用基于JSR223的规则引擎，通过配置自定义协议包，实现自定义的规则流转与协议定制；此外，针对数据需要按不同的规则推送给不同的平台这一问题，采用统一化的管理，支持自定义的规则流转和协议处理，避免每一个平台都需要重复对接，提高了业务系统运行效率的同时，也节省了大量的开发成本。

关于数据推送单元，如图7所示，在本申请提供的一种实施例中，所述推送服务包括HTTP推送服务、FTP推送服务和DB推送服务；其中，每个推送服务均具有独属线程池。

进一步地，如图8所示，对待推送任务进行推送处理，包括如下步骤：

S31，将待推送任务放入第二环形缓冲区中；

S32，从第二环形缓冲区中读取待推送任务；

S33，从独属线程池中获取相应的推送服务进行推送；

S34，若推送成功则记录推送日志；若推送失败则由任务调度中心再次进行任务调度；

其中，第二环形缓冲区在单生产/单消费的模式下为无锁状态；

其中，第二环形缓冲区进行内存的预先申请。

具体地，任务调度中心从任务库中拉取到待推送任务，将其交由数据推送单元进行处理。任务推送单元包括HTTP、FTP、DB等各种推送服务，可以满足对接平台的不同协议支持。

本申请的数据推送单元与上述数据预处理单元一样，也采用了环形缓冲区来存放推送任务，在本实施例中将其定义为第二环形缓冲区。为了提高任务处理速度、高效利用服务器内存及处理器性能，本申请的数据推送单元会将任务调度中心推送的任务(待推送任务)先放入第二环形缓冲区中。需要说明的是，本实施例按照推送协议类型，设立多个第二环形缓冲区，例如：HTTP推送服务的只会处理HTTP推送协议的任务。

本实施例中每个推送服务均有自己独立的线程池，从第二环形缓冲区读取任务并从线程池中获取服务进行推送。同样的，因为第二环形缓冲区中一个数据元素被读取出后，其余数据元素不需要移动其存储位置，而且第二环形缓冲区在单生产/单消费的模式下是无锁的，相比传统链表性能更高；此外，第二环形缓冲区的内存也是预先申请并且可以进行自我管理的，因此可以避免产生内存碎片，进而使得申请和释放的效率更快。

数据推送单元在完成数据的推送后会记录推送日志；如果数据推送失败则会由任务调度中心择机再次进行推送。

本申请的数据推送单元通过多种推送服务满足了对接平台的不同协议支持，再通过设立多个环形缓冲区以及为每个推送服务设立自己独立的线程池，来提高任务处理速度；通过高效利用服务器内存及处理器性能来降低推送服务内存和CPU的消耗，从而实现数据推送的高效性。

在本申请提供的一种实施例中，所述数据推送系统由Web控制台程序组成；如图9所示，所述管理监控单元包括但不限于项目管理、规则编排、协议包管理、任务调度、推送监控、系统管理和操作审计等。

进一步地，管理监控单元还用于监控业务数据量，并根据业务数据量管理各单元进行水平扩展。

具体地，管理监控单元主要面向项目管理人员以及对接开发人员等。

上述各个单元均具备独立的水平扩展能力，用以应对大数据量和高并发的需求。例如在业务数据量变更频繁的情况下，binlog并发较高，此时可以单独伸缩日志订阅单元部署的数量，如：将日志订阅单元部署为两个或两个以上，其他单元与其类似。而对于HTTP服务，可以通过增加部署数据推送单元的HTTP推送服务来提高并发处理效率。其他如FTP服务以及DB服务与HTTP服务类似，均可通过增加部署的推送服务数量来提高并发处理效率，在此不做赘述。

本申请通过管理监控单元对各单元的数据量和处理能力进行实时监控，保障了各模块的水平扩展能力，使得各模块可以更好地应对大数据量和高并发的需求，进而降低服务器的性能消耗和开发成本。

更进一步地，将本申请与现有方案进行对比分析，分析结果如下：

在代码侵入性方面，本申请对业务系统代码零侵入，无需修改任何业务系统代码；而现有方案需要对业务系统代码进行入侵埋点，记录数据变动；

在数据即时性方面，本申请可以实时获取数据的变动；而现有方案定时拉取数据的实时性较差；

在数据完整性方面，本申请即使在数据变动入口繁多的情况下，也不会导致获取数据变动信息丢失；而现有方案则会因为数据处理入口越多，越容易遗漏数据日志记录；

在业务系统性能方面，本申请因为不会直接修改业务系统及查询业务系统数据库，因此对业务系统为零影响；而现有方案中数据获取与业务系统同源，会影响业务系统的运行效率；

在接入成本方面，本申请中大部分接入平台的数据推送能够通过管理控制台的配置实现，无需反复编码；而现有方案中则会因为内容相似但又不尽相同，一个对接项目会进行一次对接开发，从而造成系统开发成本巨大。

综上所述，针对对接系统或用户数量的增加导致数据接入口增多，进而导致数据埋点遗漏及推送数据丢失的情况，本申请利用Canal实现MySQL binlog的监听，通过在对业务系统代码零入侵的情况下实现高效的数据变动捕获；针对大型系统MySQL中binlog日志量巨大，需要进行高效的binlog解析处理的问题，本申请利用环形缓冲区实现对MySQL中binlog的高效解析，降低数据预处理服务的内存和CPU的消耗；针对数据需要按不同的规则推送给不同的平台，需要做到统一化的管理并支持自定义的规则流转及自定义协议处理等问题，本申请基于JSR223的规则引擎，配置自定义协议包，实现自定义的规则流转与协议定制，避免了每一个平台都需要重复对接，提高了推送效率；针对数据量大、对接平台多的情况，本申请通过再次使用环形缓冲区实现高效的数据推送，实现了高效的数据推送；并且本申请能够支持各单元在水平方向上的扩展，使该系统能够应对大数据、高并发的需求，从而降低了服务器性能消耗，节约了开发成本。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元完成，即将系统的内部结构划分成不同的功能单元，以完成以上描述的全部或者部分功能。实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。上述系统中单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件，或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭示如上，然而并非用以限定本发明，任何本领域技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容做出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何简介修改、等同变化与修饰，均仍属于本发明技术方案的范围内。

Claims (10)

1.一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：包括依次通信连接的日志订阅单元、数据预处理单元、规则引擎及任务调度单元和数据推送单元；

所述日志订阅单元，采用canal组件对业务数据库的数据变动进行监控，获取所述业务数据库中的binlog并对其进行解析，获取binlog解析数据；

所述数据预处理单元，用于对所述binlog解析数据进行预处理操作，获取预处理数据，将所述预处理数据制作成宽表进行存储；

所述规则引擎及任务调度单元，用于对所述预处理数据进行分拣，并对分拣后的数据进行二次处理，获取待推送任务；将所述待推送任务存入任务库中等待任务调度中心进行调度；

所述数据推送单元，用于对所述任务调度中心调度的所述待推送任务进行推送处理；

其中，所述业务数据库的数据变动表示为所述业务数据库执行的写入性操作；

其中，所述数据预处理单元包括第一环形缓冲区；所述第一环形缓冲区用于存放所述binlog解析数据；

其中，所述数据推送单元包括多种推送服务，多种所述推送服务支持对接平台的多种推送协议类型；根据多种所述推送协议类型设立多个第二环形缓冲区；多个所述第二环形缓冲区用于存放所述待推送任务。

2.根据权利要求1所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述日志订阅单元包括所述canal组件和所述业务数据库；所述业务数据库包括主服务器和从服务器。

3.根据权利要求2所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述canal组件获取所述binlog并进行解析，包括如下步骤：

S11，所述canal组件模拟所述从服务器的交互协议，伪装成所述从服务器向所述主服务器发送dump协议；

S12，所述主服务器接收所述dump协议并推送所述binlog至所述canal组件；

S13，所述canal组件对所述binlog进行解析，获取所述binlog解析数据；

其中，所述dump协议表示为所述主服务器中用于备份和恢复数据的协议。

4.根据权利要求1所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述数据预处理单元还包括消息队列和所述宽表；所述预处理操作包括数据解析、数据过滤、数据补全和数据打标。

5.根据权利要求4所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述将所述预处理数据制作成宽表进行存储，包括如下步骤：

S21，将所述binlog解析数据投递到所述消息队列中；

S22，将所述消息队列中的所述binlog解析数据放入所述第一环形缓冲区中；

S23，从所述第一环形缓冲区中获取所述binlog解析数据并进行所述预处理操作，获取所述预处理数据；

S24，将所述预处理数据存入所述宽表中；

其中，所述消息队列表示为应用于不同程序之间传递消息的中间件。

6.根据权利要求1所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述规则引擎及任务调度单元包括依次通信连接的规则引擎组件、协议包库、任务库和所述任务调度中心；

所述规则引擎组件，用于将所述预处理数据按照指定规则进行分拣；所述指定规则通过规则编辑器进行配置；

所述协议包库，用于存储不同对接项目的自定义协议包；还用于根据所述自定义协议包对分拣后的数据进行定制化的二次处理，获得所述待推送任务；

所述任务库，用于存储多种所述待推送任务；

所述任务调度中心，用于自定义配置调度规则，并从所述任务库中调度所述待推送任务；

其中，所述调度规则包括定时、间隔和重试机制；

其中，所述待推送任务包括HTTP任务、FTP任务和DB任务。

7.根据权利要求1所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述推送服务包括HTTP推送服务、FTP推送服务和DB推送服务；其中，每个所述推送服务均具有独属线程池。

8.根据权利要求7所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：对所述待推送任务进行推送处理，包括如下步骤：

S31，将所述待推送任务放入所述第二环形缓冲区中；

S32，从所述第二环形缓冲区中读取所述待推送任务；

S33，从所述独属线程池中获取相应的所述推送服务进行推送；

S34，若推送成功则记录推送日志；若推送失败则由所述任务调度中心再次进行任务调度；

其中，所述第二环形缓冲区在单生产/单消费的模式下为无锁状态；

其中，所述第二环形缓冲区进行内存的预先申请。

9.根据权利要求1所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述数据推送系统还包括由Web控制台程序组成的管理监控单元；所述管理监控单元分别与所述日志订阅单元、所述数据预处理单元、所述规则引擎及任务调度单元和所述数据推送单元通信连接；所述管理监控单元包括项目管理、规则编排、协议包管理、任务调度、推送监控、系统管理和操作审计。

10.根据权利要求9所述的一种基于binlog与双环形缓冲区的数据推送系统，其特征在于：所述管理监控单元用于监控业务数据量，并根据所述业务数据量管理各单元进行水平扩展。