CN111581227A - 事件推送方法、装置、计算机设备及存储介质 - Google Patents

事件推送方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
CN111581227A
CN111581227A CN202010484888.6A CN202010484888A CN111581227A CN 111581227 A CN111581227 A CN 111581227A CN 202010484888 A CN202010484888 A CN 202010484888A CN 111581227 A CN111581227 A CN 111581227A
Authority
CN
China
Prior art keywords
data
target
event
update
record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010484888.6A
Other languages
English (en)
Inventor
吴双桥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010484888.6A priority Critical patent/CN111581227A/zh
Publication of CN111581227A publication Critical patent/CN111581227A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2379Updates performed during online database operations; commit processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/55Push-based network services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/548Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请是关于一种事件推送方法、装置、计算机设备及存储介质。该方法包括:获取数据库的数据更新日志;读取所述数据更新日志中的目标记录;生成所述目标记录对应的目标事件信息;将所述目标事件信息推送至事件处理组件对应的事件队列。本方案中,事件信息不需要处理数据更新请求的组件来执行,从而实现将数据更新请求的处理与事件信息的推送步骤解耦,在云计算场景中,利用数据库的日志功能来避免事件信息推送步骤对数据更新请求的处理过程所造成的延时,从而降低了数据更新业务的处理延时。

Description

事件推送方法、装置、计算机设备及存储介质
技术领域
本申请实施例涉及云计算技术领域,特别涉及一种事件推送方法、装置、计算机设备及存储介质。
背景技术
在云计算场景中,一项业务的处理可能同时涉及在数据库中进行数据更新和事件推送这两项操作。
比如,在相关技术中,云计算场景中的一个完整的业务处理逻辑由请求处理组件、数据库以及事件处理组件协作完成。例如,请求处理组件按照接收时间的顺序依次处理数据更新请求,对于每一条数据更新请求,请求处理组件指示数据库进行数据更新,同时,请求处理组件生成该数据更新请求对应的事件信息,并将事件信息推送至事件队列;为了避免出现误处理或者数据不一致的情况,请求处理组件通常在确认事件信息成功发送至事件队列后,将数据更新结果保存至数据库(即数据更新的commit操作),并进行下一条数据更新请求的处理。
然而,相关技术所示的方案,请求处理组件需要在成功发送事件信息后,才执行数据更新的commit操作,导致数据更新请求处理流程的延时过高,影响业务处理的效率。
发明内容
本申请实施例提供了一种事件推送方法、装置、计算机设备及存储介质,可以提高云计算场景下的业务处理效率,该技术方案如下:
一方面,提供了一种事件推送方法,所述方法包括:
获取数据库的数据更新日志,所述数据更新日志中包含至少一条更新记录,所述更新记录用于指示所述数据库中的一条数据的一次更新操作;
读取所述数据更新日志中的目标记录,所述目标记录是所述至少一条更新记录中的任意一条;
生成所述目标记录对应的目标事件信息;
将所述目标事件信息推送至事件处理组件对应的事件队列,所述事件处理组件用于执行所述事件队列中的事件信息对应的处理操作。
另一方面,提供了一种事件推送装置,所述装置包括:
日志获取模块,用于获取数据库的数据更新日志,所述数据更新日志中包含至少一条更新记录,所述更新记录用于指示所述数据库中的一条数据的一次更新操作;
记录读取模块,用于读取所述数据更新日志中的目标记录,所述目标记录是所述至少一条更新记录中的任意一条;
事件信息生成模块,用于生成所述目标记录对应的目标事件信息;
事件信息推送模块,用于将所述目标事件信息推送至事件处理组件对应的事件队列,所述事件处理组件用于执行所述事件队列中的事件信息对应的处理操作。
在一种可能的实现方式中,所述目标记录中包含更新前的目标数据和更新后的目标数据,所述目标数据是所述数据库中对应所述目标记录的数据;
所述事件信息生成模块,用于将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息;所述指定格式是所述时间处理组件可解析的数据格式。
在一种可能的实现方式中,所述装置还包括:
标识获取模块,用于在所述事件信息生成模块将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,获取所述数据库的标识;
第一格式查询模块,用于查询与所述数据库的标识相对应的所述指定格式。
在一种可能的实现方式中,所述装置还包括:
格式获取模块,用于在所述事件信息生成模块将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,获取所述目标数据的数据格式;
第二格式查询模块,用于查询与所述目标数据的数据格式相对应的所述指定格式。
在一种可能的实现方式中,所述装置还包括:
数据类型获取模块,用于在所述事件信息生成模块将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,获取所述目标记录中各个字段的数据类型;
第三格式查询模块,用于查询与所述各个字段的数据类型分别对应的数据子格式;
格式组合模块,用于基于所述各个字段的数据类型分别对应的数据子格式,组合得到所述指定格式。
在一种可能的实现方式中,所述记录读取模块,用于按照所述至少一条更新记录的生成时间从早到晚的顺序,将所述至少一条更新记录依次读取为所述目标记录。
在一种可能的实现方式中,所述事件信息推送模块,还用于响应于推送所述目标事件信息失败,重新将所述目标事件信息推送至所述事件队列。
在一种可能的实现方式中,所述记录读取模块,还用于响应于推送所述目标事件信息成功,从所述数据更新日志中读取新的目标记录。
在一种可能的实现方式中,所述更新记录是所述数据库响应于请求处理组件处理数据更新请求时生成的记录;所述装置还包括:
请求处理控制模块,用于在日志获取模块获取数据库的数据更新日志之前,响应于所述数据库成功执行任意一条所述更新记录对应的数据更新操作,控制所述请求处理组件处理下一条数据更新请求。
在一种可能的实现方式中,所述请求处理控制模块,用于响应于所述数据库成功执行任意一条所述目标记录对应的数据更新操作,通过所述数据库向所述请求处理组件发送更新完成通知,所述更新完成通知用于指示所述请求处理组件处理下一条数据更新请求。
在一种可能的实现方式中,所述数据更新日志为二进制日志,所述二进制日志的日志模式为基于行的复制模式,所述二进制日志的镜像参数指示所述二进制日志用于记录数据的前镜像和后镜像。
另一方面,提供了一种事件推送系统,所述系统包括:请求处理组件、数据库以及事件推送组件;
所述请求处理组件,用于在处理第一数据更新请求时,对所述数据库中的目标数据进行一次数据更新操作;
所述数据库,用于在对所述数据更新操作执行成功后,将所述数据更新操作对应的更新记录写入数据更新日志,并向所述请求处理组件发送更新完成通知,所述更新完成通知用于指示所述请求处理组件处理第二数据更新请求,所述第二数据更新请求是所述第一数据更新请求的下一条请求;
所述事件推送组件,用于按照生成时间从早到晚的顺序,读取所述数据更新日志中的目标记录,生成所述目标记录对应的目标事件信息,并将所述目标事件信息推送至事件处理组件对应的事件队列,所述事件处理组件用于执行所述事件队列中的事件信息对应的处理操作。
另一方面,提供了一种计算机设备,所述计算机设备包含处理器和存储器,所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的事件推送方法。
另一方面,提供了一种计算机可读存储介质,所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上所述的事件推送方法。
本申请提供的技术方案可以包括以下有益效果:
对于数据库中的任意一条数据发生更新时产生的更新记录,可以基于该更新记录生成对应的事件信息并添加到事件队列,也就是说,事件信息不需要处理数据更新请求的组件来执行,从而实现将数据更新请求的处理与事件信息的推送步骤解耦,避免了事件信息推送步骤对数据更新请求的处理过程所造成的延时,从而降低了数据更新业务的处理延时。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。
图1是本申请各个实施例涉及的一种业务处理系统的系统构成图;
图2是根据一示例性实施例示出的一种事件推送方法的流程图;
图3是图2所示实施例涉及的一种基于事件驱动的系统框架图;
图4是根据一示例性实施例示出的一种事件推送方法的流程图;
图5是图4所示实施例涉及的更新记录示意图;
图6是图4所示实施例涉及的一种事件信息推送的框架图;
图7是根据一示例性实施例示出的事件推送装置的结构方框图;
图8是根据一示例性实施例示出的一种计算机设备的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
本申请实施例提出了一种事件推送方案,该方案能够事件推送。为了便于理解,下面对本申请涉及的名词进行解释。
1)云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用,将来每个物品都有可能存在自己的识别标志,都需要传输到后台系统进行逻辑处理,不同程度级别的数据将会分开处理,各类行业数据皆需要强大的系统后盾支撑,只能通过云计算来实现。
2)云计算
云计算(Cloud computing)指互联网技术(Internet Technology,IT)基础设施的交付和使用模式,指通过网络以按需、易扩展的方式获得所需资源;广义云计算指服务的交付和使用模式,指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关,也可是其他服务。云计算是网格计算(Grid Computing)、分布式计算(Distributed Computing)、并行计算(Parallel Computing)、效用计算(UtilityComputing)、网络存储(Network StorageTechnologies)、虚拟化(Virtualization)、负载均衡(Load Balance)等传统计算机和网络技术发展融合的产物。
随着互联网、实时数据流、连接设备多样化的发展,以及搜索服务、社会网络、移动商务和开放协作等需求的推动,云计算迅速发展起来。不同于以往的并行分布式计算,云计算的产生从理念上将推动整个互联网模式、企业管理模式发生革命性的变革。
3)云存储(cloud storage)
云存储是在云计算概念上延伸和发展出来的一个新的概念,分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能,将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作,共同对外提供数据存储和业务访问功能的一个存储系统。
目前,存储系统的存储方法为:创建逻辑卷,在创建逻辑卷时,就为每个逻辑卷分配物理存储空间,该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据,也就是将数据存储在文件系统上,文件系统将数据分成许多部分,每一部分是一个对象,对象不仅包含数据而且还包含数据标识(ID,IDentity)等额外的信息,文件系统将每个对象分别写入该逻辑卷的物理存储空间,且文件系统会记录每个对象的存储位置信息,从而当客户端请求访问数据时,文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。
存储系统为逻辑卷分配物理存储空间的过程,具体为:按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(RAID,Redundant Array of Independent Disk)的组别,预先将物理存储空间划分成分条,一个逻辑卷可以理解为一个分条,从而为逻辑卷分配了物理存储空间。
4)数据库
数据库(Database),简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
数据库管理系统(英语:Database Management System,简称DBMS)是为管理数据库而设计的电脑软件系统,一般具有存储、截取、安全保障、备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分类,例如关系式、XML(Extensible MarkupLanguage,即可扩展标记语言);或依据所支持的计算机类型来作分类,例如服务器群集、移动电话;或依据所用查询语言来作分类,例如SQL(结构化查询语言,Structured QueryLanguage)、XQuery;或依据性能冲量重点来作分类,例如最大规模、最高运行速度;亦或其他的分类方式。不论使用哪种分类方式,一些DBMS能够跨类别,例如,同时支持多种查询语言。
请参考图1,其示出了本申请各个实施例涉及的一种业务处理系统的系统构成图。如图1所示,该系统包括服务器120、数据库140以及若干个终端160。
服务器120是一台服务器,或者由若干台服务器,或者是一个虚拟化平台,或者是一个云计算服务中心。
服务器120可以是为云计算场景中的各类业务提供后台支持的服务器。服务器120可以由一个或多个功能组件组成。
可选的,在一种可能的实现方式中,如图1所示,服务器120可以包括请求处理组件120a、事件推送组件120b以及事件处理组件120c。
其中,上述请求处理组件120a、事件推送组件120b以及时间处理组件120c可以通过服务器中的硬件执行不同的软件程序,比如,执行不同的应用程序(Application)来实现。
请求处理组件120a用于与终端160中安装的客户端程序进行信息交互,以获取终端160发起的数据更新请求;并根据接收到的数据更新请求对数据库140中的数据进行更新。
事件推送组件120b用于根据数据库140的数据更新结果,生成相应的事件信息,并将事件信息提供给事件处理组件120c。
事件处理组件120c用于根据事件推送组件120b提供的事件信息,执行相应的事件处理操作,比如,根据接收到的事件信息发送相应的通知等等。
上述数据库140可以是Redis数据库,或者,也可以是其它类型数据库。其中,数据库140用于存储各类数据,比如,各个用户的用户信息、各类业务的业务数据等等。
终端160与服务器120之间通过通信网络相连。可选的,该通信网络是有线网络或无线网络。
可选的,该系统还可以包括管理设备(图1未示出),该管理设备与服务器120之间通过通信网络相连。可选的,通信网络是有线网络或无线网络。
可选的,上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网、但也可以是任何网络,包括但不限于局域网(Local Area Network,LAN)、城域网(Metropolitan Area Network,MAN)、广域网(Wide Area Network,WAN)、移动、有线或者无线网络、专用网络或者虚拟专用网络的任何组合)。在一些实施例中,使用包括超文本标记语言(Hyper Text Mark-up Language,HTML)、可扩展标记语言(Extensible MarkupLanguage,XML)等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层(Secure Socket Layer,SSL)、传输层安全(Transport Layer Security,TLS)、虚拟专用网络(Virtual Private Network,VPN)、网际协议安全(Internet ProtocolSecurity,IPsec)等常规加密技术来加密所有或者一些链路。在另一些实施例中,还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。
在应用层的逻辑中,经常会遇到这样一种场景,程序逻辑处理来自用户的一个请求,比如商品下单、支付请求等,在处理完这个请求的逻辑后,需要将处理的结果持久化到数据库(也就是通常说的,将数据写到数据库中);同时,如果请求处理成功的话,还要将处理的结果作为一个事件信息发送到事件队列,因为其他程序逻辑可能也会关心数据的变化。这也是分布式系统中一个经典的应用场景,即基于事件驱动的系统。
这类场景在云上架构微服务化、容器化之后更加普遍,原因是微服务化后功能模块会拆得更小,每个服务(或者说应用程序),处理某一特定的功能,比如有专门处理用户请求的应用程序,有专门处理监控告警的应用程序,有专门处理统计数据报表的应用程序,有专门处理权限控制的应用程序等等。
比如,在一个可能的示例中,应用程序A(比如上述图1所示系统中的请求处理组件120a运行的应用程序)收到一个订单请求,购买一个商品a,数量为2,那么在处理完一系列的逻辑之后,需要将订单数据库(比如上述数据库140)中,已经售卖处理的商品a数量加2,存量库存数量减2;同时,需要将当前商品a剩余库存数量x作为一个事件信息发送到事件队列,由应用程序B(比如上述图1所示系统中的事件处理组件120c运行的应用程序)处理。应用程序B的逻辑是接收消息,判断当前的库存是否低于该商品事先配置好的阈值,如果低于阈值则发送一封邮件,提醒采购人员需要进行采购。
随着互联网应用的不断发展,互联网应用的用户也在飞速增长,目前很多互联网业务具有极高的并发数,而此类业务通常对低延时、数据高可用、高可靠、以及数据一致性的要求较高,比如,此类互联网业务通常应用在电商以及金融支付等领域,因此,在基于事件驱动的系统中,如何在保证数据的高可用性、高可靠性、以及一致性的情况下,尽可能的降低业务处理的延时,对于互联网应用具有极大的意义。
本申请后续实施例提出一种事件推送方案,可以在基于事件推送的系统中,更好的兼顾低延时、数据高可用、高可靠、以及数据一致性。
图2是根据一示例性实施例示出的一种事件推送方法的流程图,该事件推送方法可以用于计算机设备,比如上述图1所示系统的服务器中。以该方法由图1所示服务器中的事件推送组件120b执行为例,如图2所示,该事件推送方法可以包括如下步骤:
步骤21,获取数据库的数据更新日志,数据更新日志中包含至少一条更新记录,更新记录用于指示数据库中的一条数据的一次更新操作。
在本申请实施例中,数据库中存储有若干条数据,并且,数据库还维护有数据更新日志。当数据库中的某一条数据每次发生改变,即发生数据更新时,数据库将在数据更新日志中增加一条更新记录,用于记录本次数据更新。
在一种可能的实现方式中,数据库中的数据更新由请求处理组件在执行数据更新请求时触发执行,比如,请求处理组件接收到一个数据处理请求后,向服务器中对应的数据发起数据更改,数据更改完成后,数据库将该条数据本次更改的信息添加为数据更新日志中的一条数据记录。
步骤22,读取数据更新日志中的目标记录,目标记录是至少一条更新记录中的任意一条。
在本申请实施例中,当数据更新日志中存在未处理过的更新记录时,服务器中的事件推送组件从数据更新日志中读取一条更新记录作为目标记录。
比如,时间推送组件监控数据更新日志的变化请求,当数据更新日志中出现新的更新记录时,事件推送组件即从数据更新日志中读取新增的更新记录,作为后续处理的目标记录。
步骤23,生成目标记录对应的目标事件信息。
由于数据更新日志的格式,与事件信息的格式通常存在很大的区别,事件处理组件通常不能直接对数据更新日志进行解析,因此,在本申请实施例中,事件推送组件可以通过格式变换的方式,将目标记录转化为目标事件信息。
步骤24,将目标事件信息推送至事件处理组件对应的事件队列,事件处理组件用于执行事件队列中的事件信息对应的处理操作。
事件推送组件每生成一条事件信息之后,即可以将生成的事件信息推送至事件队列,由事件处理组件从事件队列中提取事件信息并执行相应的处理操作。
比如,请参考图3,其示出了本申请实施例涉及的一种基于事件驱动的系统框架图。如图3所示,请求处理组件在处理一条数据更新请求时,向数据库发起数据更新(S31);数据库执行数据更新数据操作(S32),并将数据更新操作对应的更新记录写入数据更新日志(S33);事件推送组件从数据更新日志中读取目标记录(S34),并根据目标记录生成事件信息(S35),将生成的事件信息推送至事件队列(S36)。由上述过程图3所示的各个步骤可见,上述方案通过数据更新日志来生成事件信息,将事件信息的生成步骤与请求处理组件处理数据更新请求的步骤解耦,也就是说,请求处理组件处理数据更新请求时,不需要等待对应的事件信息成功发送至事件队列,即可以直接处理下一条数据更新请求。
综上所述,本申请实施例所示的方案,对于数据库中的任意一条数据发生更新时产生的更新记录,可以基于该更新记录生成对应的事件信息并添加到事件队列,也就是说,事件信息不需要处理数据更新请求的组件来执行,从而实现将数据更新请求的处理与事件信息的推送步骤解耦,避免了事件信息推送步骤对数据更新请求的处理过程所造成的延时,从而降低了数据更新业务的处理延时。
图4是根据一示例性实施例示出的一种事件推送方法的流程图,该事件推送方法可以用于计算机设备,比如上述图1所示系统的服务器中。以该方法由图1所示服务器中的各个组件执行为例,如图4所示,该事件推送方法可以包括如下步骤:
步骤401,请求处理组件在处理数据更新请求时,对数据库中的数据发起一次数据更新。
在一种可能的实现方式中,请求处理组件可以接收终端中安装的客户端程序发送的数据更新请求,并对接收到的数据更新请求逐一进行处理。
可选的,上述的数据更新请求是需要或者可以对数据库中对应的数据进行更改的请求,比如,数据更新请求可以是任意由用户发起的业务处理请求,例如,订单下单的业务请求、转账交易的业务请求等等。
可选的,请求处理组件在处理第一数据更新请求时,向数据库发送数据更新指令,该数据更新指令指示数据库对相应的数据进行更新。相应的,数据库接收到数据更新指令后,即对该指令对应的数据执行数据更新操作。
例如,以请求处理组件具有转账交易处理功能为例,一笔转账业务产生两条数据更新请求,分别是将转出账户的余额减去转账金额的请求,以及,将转入账户的余额增加转账金额的请求;对于这两条数据更新请求,请求处理组件依次向数据库发起数据更新,以使得数据库依次更新数据库中存储的,该转出账户和转入账户的余额的数值。
步骤402,数据库在对该数据更新操作执行成功后,将该数据更新操作对应的更新记录写入数据更新日志。
也就是说,该更新记录是该数据库响应于请求处理组件处理数据更新请求时生成的记录。
在本申请实施例中,数据库每执行一次数据更新操作之后,数据库在数据更新日志中写入一条更新记录,以记录本次数据更新情况。
在一种可能的实现方式中,数据更新日志为二进制日志,二进制日志的日志模式为基于行的复制模式,二进制日志的镜像参数指示二进制日志用于记录数据的前镜像和后镜像。
在本申请实施例中,以上述数据库是关系型数据库管理系统数据库,比如MySQL为例,数据库开启二进制日志,即Binlog功能,并且将Binlog的格式设置为ROW(行),并且将binlog_row_image参数设置为FULL,这样二进制日志会记录的数据库中一行数据修改前和修改后的值。
比如,请参考图5,其示出了本申请实施例涉及的更新记录示意图,如图5所示,在一次数据更新操作中,数据库51中的一条数据51a,修改前的数值是100为例,修改后的数值为80;则本次数据更新操作对应在数据更新日志52中的更新记录52a为:(100,80)。
步骤403,响应于数据库成功执行任意一条该更新记录对应的数据更新操作,控制该请求处理组件处理下一条数据更新请求。
可选的,响应于该数据库成功执行任意一条该目标记录对应的数据更新操作,服务器通过该数据库向该请求处理组件发送更新完成通知,该更新完成通知用于指示该请求处理组件处理下一条数据更新请求。
在一种可能的实现方式中,数据库在执行数据更新操作后,即可以执行提交(commit)操作,以将数据更新数据结果持久化到数据库中。然后,数据库即可以通知请求处理组件处理下一条数据更新请求。
从请求处理组件的角度来说,请求处理组件在依次处理数据更新请求的过程中,根据当前的数据更新请求向数据库发起数据更新操作,接收到数据库返回的该数据更新操作执行成功的通知后,即可以直接向数据库发起下一数据更新请求对应的数据更新操作,不需要等待本次数据更新对应的事件信息成功发送至事件队列,从而缩短数据更新请求的处理时延。
步骤404,事件推送组件获取数据库的数据更新日志。
在一种可能的实现方式中,事件推送组件可以按照预设的周期读取数据库的数据更新日志。
在一种可能的实现方式中,数据库的数据更新日志可以存储在由数据库和事件推送组件所共享的内存空间中,数据库通过访问该共享的内存空间,在数据更新日志中写入新的更新记录,相应的,事件推送组件通过访问该共享的内存空间,读取数据更新日志中新写入的更新记录。
步骤405,事件推送组件读取数据更新日志中的目标记录,目标记录中包含更新前的目标数据和更新后的目标数据,目标数据是数据库中对应目标记录的数据。
其中,目标记录是上述至少一条更新记录中的任意一条。
在一种可能的实现方式中,事件推送组件按照至少一条更新记录的生成时间从早到晚的顺序,将至少一条更新记录依次读取为目标记录。
在本申请实施例中,事件推送组件可以定期查询或者实时监控数据库的数据更新日志中是否存在尚未被读取过的更新记录,如果存在,则从尚未被读取过的更新记录中,生成时间最早的更新记录开始,依次读取为目标记录,以执行后续的事件信息推送流程。
在一种可能的实现方式中,事件推送组件在执行后续步骤406之前,先检测该目标记录对应的数据是否开启了事件通知功能,响应于该目标记录对应的数据开启了事件通知功能,执行后续步骤406。
在本申请实施例中,数据库中某些数据更新后,可能并不需要生成相应的事件信息,比如,以数据库中的数据是各个用户的银行卡余额,事件处理组件的功能是执行银行卡余额变动提醒为例,某用户A开启了银行卡余额提醒功能,即该用户A的数据开启了事件通知功能,而用户B未开启银行卡余额提醒功能,即该用户B的数据未开启事件通知功能,因此,当用户A和用户B的银行卡余额都发生了变动时,如果对用户A和用户B的数据更新都生成相应的事件信息,则后续事件处理组件也会忽略掉用户B的数据更新对应的事件信息,也就是说,对用户B的数据更新都生成相应的事件信息的步骤,属于不必要的步骤。因此,通过本申请实施例所示的方案,事件推送组件在读取了用户B的数据更新对应的更新记录之后,检测到用户B未开启银行卡余额提醒功能,则忽略该更新记录;相应的,事件推送组件在读取了用户A的数据更新对应的更新记录之后,检测到用户A开启了银行卡余额提醒功能,则执行后续步骤406。
步骤406,事件推送组件将更新前的目标数据以及更新后的目标数据,转换为指定格式的数据,得到目标事件信息。
其中,上述指定格式是事件处理组件可解析的数据格式。
为了提高数据库的利用率,减少数据存储的占用空间,数据库中通常对数据的格式做预先设定,比如,在数据库的一个数据列表中,每一行数据中每个数据位都对应各自的物理含义,比如,假设一行数据包含3个数据位,这3个数据位分别表示商品名称a、销售量10以及库存量100,则这一行数据只包含(‘a’,10,100)这三个字段上的数值,而不会指明这3个字段上的数值的含义,相应的,数据更新日志中的更新记录也只包含这一行数据修改前以及修改后的各个字段上的值,对于数据库之外的事件处理组件来说,其并不能直接解析出该更新记录的实际含义,因此,需要事件推送组件将更新记录的格式转换为事件处理组件可解析的数据格式。
在一示例性的方案中,事件推送组件将更新前的目标数据以及更新后的目标数据,转换为指定格式的数据,得到目标事件信息之前,还可以获取数据库的标识;查询与数据库的标识相对应的指定格式。
在本申请实施例的一种可能实现方式中,数据库中的各条数据的格式是统一的,相应的,该数据库的数据更新日志中的各条更新记录的格式也是统一的,服务器中可以预先在第一配置信息中配置该数据库对应的更新记录在格式转化时的目标格式(即上述指定格式),该第一配置信息可以包含数据库的标识与指定格式之间的对应关系,对于不同的数据库来说,由于更新记录的格式不同,相应的指定格式也不同,也就是说,在上述第一配置信息中,不同的数据库的标识,对应不同的指定格式。
相应的,事件推送组件对该数据库的数据更新日志中的各条更新记录进行格式转化,得到事件信息之前,可以通过数据库的标识,在第一配置信息中查询相应的指定格式。
在一种可能实现方式中,上述事件推送组件可以从目标记录中提取上述数据库的标识。也就是说,在数据库的数据更新日志中,每一条更新记录中可以携带数据库的标识。
比如,假设数据库DB1中存储的各行数据的格式统一,该数据库DB1中的一行数据包含3个数据位,这3个数据位分别表示商品名称a、销售量10以及库存量100。
在一种可能的实现方式中,在某次数据更新后,这3个数据位的值修改为商品名称a、销售量12以及库存量98,则本次数据更新对应的更新记录为:
(DB1,“a”,10,100),(DB1,“a”,12,98);
其中,修改前后的数据中,“DB1”即为数据库的标识。
在另一种可能的实现方式中,为了节约存储空间,更新记录中的数据库的标识,独立于更新前后的数据,比如,本次数据更新对应的更新记录为:
(DB1),(“a”,10,100),(“a”,12,98)。
在一示例性的方案中,事件推送组件将更新前的目标数据以及更新后的目标数据,转换为指定格式的数据,得到目标事件信息之前,还获取目标数据的数据格式;查询与目标数据的数据格式相对应的指定格式。
在本申请实施例的一种可能实现方式中,数据库中的各条数据的格式是不统一的。比如,上述数据库中包含两种或者两种以上不同格式的数据。例如,不同格式的数据按照不同的数据列表进行处理,单个列表中的各行数据的格式统一,而不同列表中的数据的格式不同。
相应的,该数据库的数据更新日志中的各条更新记录的格式也是不统一的,服务器中可以预先在第二配置信息中配置数据库中不同格式的数据对应的更新记录在格式转化时的目标格式(即上述指定格式),该第二配置信息可以包含数据格式与指定格式之间的对应关系,对于不同的数据格式对应的数据来说,由于更新记录的格式不同,相应的指定格式也不同,也就是说,在上述第二配置信息中,不同的数据格式,对应不同的指定格式。
相应的,事件推送组件对该数据库的数据更新日志中的各条更新记录进行格式转化,得到事件信息之前,可以通过数据库的标识,在第二配置信息中查询与当前更新记录对应的数据格式相应的指定格式。
在一种可能实现方式中,上述事件推送组件可以从目标记录中提取上述数据格式。也就是说,在数据库的数据更新日志中,每一条更新记录中可以携带对应的数据的数据格式。
在一种可能实现方式中,当数据库中的一个列表中的各行数据的格式统一时,上述数据格式可以通过相应的数据所在的列表的标识(比如列表的编号)来标识,也可以通过相应的数据所在的数据库的标识以及所在的列表的标识共同表示。
比如,假设数据库DB1中存储的各行数据的格式不统一,其中,数据库DB1的列表C1中的一行数据包含3个数据位,这3个数据位分别表示商品名称a、销售量10以及库存量100。
在一种可能的实现方式中,在某次数据更新后,这3个数据位的值修改为商品名称a、销售量12以及库存量98,则本次数据更新对应的更新记录为:
(DB1,C1,“a”,10,100),(DB1,C1,“a”,12,98);
其中,修改前后的数据中,“DB1”即为数据库的标识,“C1”即为列表的标识。
在另一种可能的实现方式中,为了节约存储空间,更新记录中的数据库的标识和列表的标识,独立于更新前后的数据,比如,本次数据更新对应的更新记录为:
(DB1,C1),(“a”,10,100),(“a”,12,98)。
在一示例性的方案中,事件推送组件将更新前的目标数据以及更新后的目标数据,转换为指定格式的数据,得到目标事件信息之前,还获取目标记录中各个字段的数据类型;查询与各个字段的数据类型分别对应的数据子格式;基于各个字段的数据类型分别对应的数据子格式,组合得到指定格式。
在本申请实施例的一种可能实现方式中,由于数据的格式取决于数据中各个字段的组合,有限的字段的数据类型,可以组合出更多种类的数据格式,比如,以一共有3种数据类型的字段为例,理论上可以组合出7种数据格式。因此,当数据库中的各条数据的格式的数量较多,而字段的数据类型有限时,服务器中直接维护各种数据类型的字段对应的数据子格式,读取到目标记录时,事件推送组件可以根据目标记录中的各个字段的数据类型,查询各个字段对应的数据子格式,然后将查询到的数据子格式进行组合,即可以得到相应的指定格式。
在一种可能实现方式中,上述事件推送组件可以从目标记录中提取上述目标记录中的各个字段的数据类型。也就是说,在数据库的数据更新日志中,每一条更新记录中可以携带对应的字段的数据类型。
比如,假设数据库中的一行数据包含3个数据位,这3个数据位分别表示商品名称a、销售量10以及库存量100,对应的数据类型分别以T1、T2和T3来表示。
则在一种可能的实现方式中,在某次数据更新后,这3个数据位的值修改为商品名称a、销售量12以及库存量98,则本次数据更新对应的更新记录为:
(T1:“a”,T2:10,T3:100),(T1:“a”,T2:12,T3:98)。
步骤407,事件推送组件将目标事件信息推送至事件处理组件对应的事件队列。
事件推送组件响应于推送目标事件信息失败,事件处理组件重新将目标事件信息推送至事件队列。
事件推送组件响应于推送目标事件信息成功,事件处理组件从数据更新日志中读取新的目标记录。
在一示例性的方案中,事件推送组件每生成一条事件信息之后,即将该事件信息推送至事件队列,如果推送成功,则读取下一条更新记录以生成新的事件信息,如果推送失败,则重新推送该事件信息。
步骤408,事件处理组件执行事件队列中的事件信息对应的处理操作。
在本申请实施例中,事件处理组件可以监控事件队列,当事件队列中出现事件信息时,可以从事件队列中提取事件信息,并执行事件信息对应的操作,比如,向用户发出数据更新的提醒等等。
在一种可能的实现方式中,事件队列是一个先入先出队列,使得事件处理组件按照事件的生成时间的顺序,依次处理各个事件信息,从而保证事件信息的处理顺序。
比如,请参考图6,其示出了本申请实施例涉及的一种事件信息推送的框架图。以数据库是一个商品库存库为例,其结构如下:
CREATE TABLE`order`(
`id`int(11)DEFAULT NULL AUTO_INCREMENT,
`goods_name`char(32)DEFAULT NULL DEFAULT 0,
`goods_number`char(11)NOT NULL DEFAULT 0,
`goods_left`int(11)DEFAULT NULL DEFAULT 0,
PRIMARY KEY(`id`),
KEY`gn`(`goods_name`)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
其中goods_name字段表示商品的名称,goods_number字段表示商品总共售卖的个数,goods_left表示这个商品剩余库存。假设初始的时候,数据库里面只有一条记录为(1,‘a’,10,100),即a产品当前总共卖出了10个,库存还有100个。如图6所示,基于该数据库的事件信息推送的的流程步骤如下:
步骤S61:应用程序1执行订单请求处理。
应用程序1(即请求处理组件)处理完订单请求(a卖出2个)后,将最新的数据(1,‘a’,12,98)写入到数据库(S61a);之后,该订单请求的处理完成响应立刻被数据库返回(S61b);应用程序1继续处理新的订单请求,继续循环执行步骤S61。
步骤S62:事件推送组件执行事件信息生成及推送。
事件推送组件(比如Binlog Processer组件)监听数据库的二进制日志的变化(S62a),得到最新的变化,等价于[(1,‘a’,10,100),(1,‘a’,12,98)]的更新记录,这里包含:修改前和修改后的数据。
事件推送组件根据得到的更新记录,确定格式转换的指定格式(S62b)。
事件推送组件根据数据库二进制日志协议的格式,解析原始的Binlog二进制日志,对其进行格式转换(S62c),将其转变为上层应用程序(比如事件处理组件)可以理解的数据,即转换成上述指定格式,以指定格式是json格式为例,转化后的事件信息可以如下:
Figure BDA0002518782950000181
事件推送组件将解析后的数据,发送到事件队列(S63d),如果执行成功,跳转到步骤2持续监听处理新的数据变化;
如果单次事件发送失败,事件推送组件继续执行S63d重试。
步骤S63:应用程序2/3(即事件处理组件)执行事件处理。
应用程序2/3从事件队列里面拉取数据,获取到最新的事件信息(S63a);
应用程序2/3处理获取到的事件信息(S63b),处理完成后继续跳转到S63a拉取最新的数据。
以上图6所示的流程构造了一个在微服务环境下完整的事件通知和消息处理方案。结合图6可以看出,在三个大步骤中,步骤S61、S62以及S63相互之间是有时序关系的,严格依次执行,是数据流动的方向。另外,三个大步骤中的各个子步骤,分别是一个无限循环,在处理完单条数据之后,继续处理下一条,而小步骤之间是严格依次执行的,但是大步骤是在几个不同组件中,异步的独立运行的。
结合图6,本申请所示的方案可以实现以下效果:
A)低延时:
由于应用程序1在写入数据之后,不用做额外的发送消息(甚至失败重试)的操作,少一次或多次(失败重试的情况)网络请求。
B)高可用、高可靠:
图6中,将数据的在持久化和消息发送的分别表示,重新整合为一种数据持久化的表示,只要数据成功写入数据库就不会丢失;在步骤S62中进行事件信息的发送时,会异步的重试发送事件信息,直到事件信息发送成功为止。另外,如果应用程序或者数据库突然down机,写入的消息也不会丢失,因为已经记录进了二进制日志。
C)保证事件信息的顺序性:
在图6中,虽然应用层和数据库都可以支持成千上万、上百万的并发操作,但是记录到数据库二进制日志的消息始终都是按照时间顺序的,而且是准确的,这是数据库的二进制日志的原理和容灾特性所保证的。
D)架构的合理性:
在图6中,将数据写入和消息发送两种动作解耦,保证了应用程序逻辑的简单性,同时一部分应用程序/组件的更新、升级、down机,都不会影响另外一部分的可用性。从数据流的角度来看,数据流动有着单一线性的流动和处理方式,架构依赖上更为简洁。
综上所述,本申请实施例所示的方案,对于数据库中的任意一条数据发生更新时产生的更新记录,可以基于该更新记录生成对应的事件信息并添加到事件队列,也就是说,事件信息不需要处理数据更新请求的组件来执行,从而实现将数据更新请求的处理与事件信息的推送步骤解耦,避免了事件信息推送步骤对数据更新请求的处理过程所造成的延时,从而降低了数据更新业务的处理延时。
此外,本申请所示的方案,通过将数据持久化和消息通知,一种数据的两种表达处理逻辑,重新整合为一条单一的数据处理流,将数据持久化和消息通知解耦,不仅提高了应用层的响应速度,同时也借助数据库本身的能力,解决了本质上为分布式事务的业务处理逻辑,保证了数据、消息处理的严格顺序性、高可用和高可靠特性。尤其是对电商、金融支付等对处理延时、可用性、可靠性保证要求都很高的领域,有很强的实践意义。
图7是根据一示例性实施例示出的一种事件推送装置的结构方框图。该事件推送装置可以执行图2或图4所示实施例中的全部或者部分步骤。该事件推送装置可以包括:
日志获取模块701,用于获取数据库的数据更新日志,所述数据更新日志中包含至少一条更新记录,所述更新记录用于指示所述数据库中的一条数据的一次更新操作;
记录读取模块702,用于读取所述数据更新日志中的目标记录,所述目标记录是所述至少一条更新记录中的任意一条;
事件信息生成模块703,用于生成所述目标记录对应的目标事件信息;
事件信息推送模块704,用于将所述目标事件信息推送至事件处理组件对应的事件队列,所述事件处理组件用于执行所述事件队列中的事件信息对应的处理操作。
在一种可能的实现方式中,所述目标记录中包含更新前的目标数据和更新后的目标数据,所述目标数据是所述数据库中对应所述目标记录的数据;
所述事件信息生成模块703,用于将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息;所述指定格式是所述时间处理组件可解析的数据格式。
在一种可能的实现方式中,所述装置还包括:
标识获取模块,用于在所述事件信息生成模块703将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,获取所述数据库的标识;
第一格式查询模块,用于查询与所述数据库的标识相对应的所述指定格式。
在一种可能的实现方式中,所述装置还包括:
格式获取模块,用于在所述事件信息生成模块703将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,获取所述目标数据的数据格式;
第二格式查询模块,用于查询与所述目标数据的数据格式相对应的所述指定格式。
在一种可能的实现方式中,所述装置还包括:
数据类型获取模块,用于在所述事件信息生成模块703将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,获取所述目标记录中各个字段的数据类型;
第三格式查询模块,用于查询与所述各个字段的数据类型分别对应的数据子格式;
格式组合模块,用于基于所述各个字段的数据类型分别对应的数据子格式,组合得到所述指定格式。
在一种可能的实现方式中,所述记录读取模块702,用于按照所述至少一条更新记录的生成时间从早到晚的顺序,将所述至少一条更新记录依次读取为所述目标记录。
在一种可能的实现方式中,所述事件信息推送模块704,还用于响应于推送所述目标事件信息失败,重新将所述目标事件信息推送至所述事件队列。
在一种可能的实现方式中,所述记录读取模块702,还用于响应于推送所述目标事件信息成功,从所述数据更新日志中读取新的目标记录。
在一种可能的实现方式中,所述更新记录是所述数据库响应于请求处理组件处理数据更新请求时生成的记录;所述装置还包括:
请求处理控制模块,用于在日志获取模块701获取数据库的数据更新日志之前,响应于所述数据库成功执行任意一条所述更新记录对应的数据更新操作,控制所述请求处理组件处理下一条数据更新请求。
在一种可能的实现方式中,所述请求处理控制模块,用于响应于所述数据库成功执行任意一条所述目标记录对应的数据更新操作,通过所述数据库向所述请求处理组件发送更新完成通知,所述更新完成通知用于指示所述请求处理组件处理下一条数据更新请求。
在一种可能的实现方式中,所述数据更新日志为二进制日志,所述二进制日志的日志模式为基于行的复制模式,所述二进制日志的镜像参数指示所述二进制日志用于记录数据的前镜像和后镜像。
综上所述,本申请实施例所示的方案,对于数据库中的任意一条数据发生更新时产生的更新记录,可以基于该更新记录生成对应的事件信息并添加到事件队列,也就是说,事件信息不需要处理数据更新请求的组件来执行,从而实现将数据更新请求的处理与事件信息的推送步骤解耦,避免了事件信息推送步骤对数据更新请求的处理过程所造成的延时,从而降低了数据更新业务的处理延时。
此外,本申请所示的方案,通过将数据持久化和消息通知,一种数据的两种表达处理逻辑,重新整合为一条单一的数据处理流,将数据持久化和消息通知解耦,不仅提高了应用层的响应速度,同时也借助数据库本身的能力,解决了本质上为分布式事务的业务处理逻辑,保证了数据、消息处理的严格顺序性、高可用和高可靠特性。
本申请一示例性实施例还提供一种事件推送系统,系统包括:请求处理组件、数据库以及事件推送组件。在一种可能的实现方式中,上述请求处理组件以及事件推送组件分别通过云服务器中的硬件/虚拟硬件运行相应的应用程序来实现。
其中,请求处理组件,用于在处理第一数据更新请求时,对数据库中的目标数据进行一次数据更新操作。
数据库,用于在对数据更新操作执行成功后,将数据更新操作对应的更新记录写入数据更新日志,并向请求处理组件发送更新完成通知,更新完成通知用于指示请求处理组件处理第二数据更新请求,第二数据更新请求是第一数据更新请求的下一条请求。
事件推送组件,用于按照生成时间从早到晚的顺序,读取数据更新日志中的目标记录,生成目标记录对应的目标事件信息,并将目标事件信息推送至事件处理组件对应的事件队列,事件处理组件用于执行事件队列中的事件信息对应的处理操作。
图8是根据一示例性实施例示出的一种计算机设备的结构示意图。该计算机设备可以实现为网络侧的服务器。该服务器可以为图1所示的服务器120。所述计算机设备800包括中央处理单元801、包括随机存取存储器(Random Access Memory,RAM)802和只读存储器(Read-Only Memory,ROM)803的系统存储器804,以及连接系统存储器804和中央处理单元801的系统总线805。所述计算机设备800还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统806,和用于存储操作系统813、应用程序814和其他程序模块815的大容量存储设备807。
所述大容量存储设备807通过连接到系统总线805的大容量存储控制器(未示出)连接到中央处理单元801。所述大容量存储设备807及其相关联的计算机可读介质为计算机设备800提供非易失性存储。也就是说,所述大容量存储设备807可以包括诸如硬盘或者光盘只读存储器(Compact Disc Read-Only Memory,CD-ROM)驱动器之类的计算机可读介质(未示出)。
不失一般性,所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、闪存或其他固态存储其技术,CD-ROM、或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然,本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器804和大容量存储设备807可以统称为存储器。
计算机设备800可以通过连接在所述系统总线805上的网络接口单元811连接到互联网或者其它网络设备。
所述存储器还包括一个或者一个以上的程序,所述一个或者一个以上程序存储于存储器中,中央处理器801通过执行该一个或一个以上程序来实现图2或图4所示的方法的全部或者部分步骤。
在示例性实施例中,还提供了一种包括指令的非临时性计算机可读存储介质,例如包括计算机程序(指令)的存储器,上述程序(指令)可由计算机设备的处理器执行以完成本申请各个实施例所示的方法的全部或者部分步骤。例如,所述非临时性计算机可读存储介质可以是只读存储器、随机存取存储器、光盘只读存储器、磁带、软盘和光数据存储设备等。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (15)

1.一种事件推送方法,其特征在于,所述方法包括:
获取数据库的数据更新日志,所述数据更新日志中包含至少一条更新记录,所述更新记录用于指示所述数据库中的一条数据的一次更新操作;
读取所述数据更新日志中的目标记录,所述目标记录是所述至少一条更新记录中的任意一条;
生成所述目标记录对应的目标事件信息;
将所述目标事件信息推送至事件处理组件对应的事件队列,所述事件处理组件用于执行所述事件队列中的事件信息对应的处理操作。
2.根据权利要求1所述的方法,其特征在于,所述目标记录中包含更新前的目标数据和更新后的目标数据,所述目标数据是所述数据库中对应所述目标记录的数据;
所述生成所述目标记录对应的目标事件信息,包括:
将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息;所述指定格式是所述时间处理组件可解析的数据格式。
3.根据权利要求2所述的方法,其特征在于,所述将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,还包括:
获取所述数据库的标识;
查询与所述数据库的标识相对应的所述指定格式。
4.根据权利要求2所述的方法,其特征在于,所述将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,还包括:
获取所述目标数据的数据格式;
查询与所述目标数据的数据格式相对应的所述指定格式。
5.根据权利要求2所述的方法,其特征在于,所述将所述更新前的目标数据以及所述更新后的目标数据,转换为指定格式的数据,得到所述目标事件信息之前,还包括:
获取所述目标记录中各个字段的数据类型;
查询与所述各个字段的数据类型分别对应的数据子格式;
基于所述各个字段的数据类型分别对应的数据子格式,组合得到所述指定格式。
6.根据权利要求1所述的方法,其特征在于,所述读取所述数据更新日志中的目标记录,包括:
按照所述至少一条更新记录的生成时间从早到晚的顺序,将所述至少一条更新记录依次读取为所述目标记录。
7.根据权利要求1所述的方法,其特征在于,所述方法还包括:
响应于推送所述目标事件信息失败,重新将所述目标事件信息推送至所述事件队列。
8.根据权利要求1所述的方法,其特征在于,所述方法还包括:
响应于推送所述目标事件信息成功,从所述数据更新日志中读取新的目标记录。
9.根据权利要求1所述的方法,其特征在于,所述更新记录是所述数据库响应于请求处理组件处理数据更新请求时生成的记录;
所述获取数据库的数据更新日志之前,还包括:
响应于所述数据库成功执行任意一条所述更新记录对应的数据更新操作,控制所述请求处理组件处理下一条数据更新请求。
10.根据权利要求9所述的方法,其特征在于,所述响应于所述数据库成功过执行任意一条所述更新记录对应的数据更新操作,控制所述请求处理组件处理下一条数据更新请求,包括:
响应于所述数据库成功执行任意一条所述目标记录对应的数据更新操作,通过所述数据库向所述请求处理组件发送更新完成通知,所述更新完成通知用于指示所述请求处理组件处理下一条数据更新请求。
11.根据权利要求1至10任一所述的方法,其特征在于,
所述数据更新日志为二进制日志,所述二进制日志的日志模式为基于行的复制模式,所述二进制日志的镜像参数指示所述二进制日志用于记录数据的前镜像和后镜像。
12.一种事件推送系统,其特征在于,所述系统包括:请求处理组件、数据库以及事件推送组件;
所述请求处理组件,用于在处理第一数据更新请求时,对所述数据库中的目标数据进行一次数据更新操作;
所述数据库,用于在对所述数据更新操作执行成功后,将所述数据更新操作对应的更新记录写入数据更新日志,并向所述请求处理组件发送更新完成通知,所述更新完成通知用于指示所述请求处理组件处理第二数据更新请求,所述第二数据更新请求是所述第一数据更新请求的下一条请求;
所述事件推送组件,用于按照生成时间从早到晚的顺序,读取所述数据更新日志中的目标记录,生成所述目标记录对应的目标事件信息,并将所述目标事件信息推送至事件处理组件对应的事件队列,所述事件处理组件用于执行所述事件队列中的事件信息对应的处理操作。
13.一种事件推送装置,其特征在于,所述装置包括:
日志获取模块,用于获取数据库的数据更新日志,所述数据更新日志中包含至少一条更新记录,所述更新记录用于指示所述数据库中的一条数据的一次更新操作;
记录读取模块,用于读取所述数据更新日志中的目标记录,所述目标记录是所述至少一条更新记录中的任意一条;
事件信息生成模块,用于生成所述目标记录对应的目标事件信息;
事件信息推送模块,用于将所述目标事件信息推送至事件处理组件对应的事件队列,所述事件处理组件用于执行所述事件队列中的事件信息对应的处理操作。
14.一种计算机设备,其特征在于,所述计算机设备包含处理器和存储器,所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至11任一所述的事件推送方法。
15.一种计算机可读存储介质,其特征在于,所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至11任一所述的事件推送方法。
CN202010484888.6A 2020-06-01 2020-06-01 事件推送方法、装置、计算机设备及存储介质 Pending CN111581227A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010484888.6A CN111581227A (zh) 2020-06-01 2020-06-01 事件推送方法、装置、计算机设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010484888.6A CN111581227A (zh) 2020-06-01 2020-06-01 事件推送方法、装置、计算机设备及存储介质

Publications (1)

Publication Number Publication Date
CN111581227A true CN111581227A (zh) 2020-08-25

Family

ID=72123808

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010484888.6A Pending CN111581227A (zh) 2020-06-01 2020-06-01 事件推送方法、装置、计算机设备及存储介质

Country Status (1)

Country Link
CN (1) CN111581227A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112732454A (zh) * 2020-12-30 2021-04-30 北京懿医云科技有限公司 一种医事服务预约方法、装置、存储介质及设备
CN114363092A (zh) * 2022-03-17 2022-04-15 万商云集(成都)科技股份有限公司 一种用于云容器引擎微服务部署的网关及方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112732454A (zh) * 2020-12-30 2021-04-30 北京懿医云科技有限公司 一种医事服务预约方法、装置、存储介质及设备
CN114363092A (zh) * 2022-03-17 2022-04-15 万商云集(成都)科技股份有限公司 一种用于云容器引擎微服务部署的网关及方法
CN114363092B (zh) * 2022-03-17 2022-05-17 万商云集(成都)科技股份有限公司 一种用于云容器引擎微服务部署的网关及方法

Similar Documents

Publication Publication Date Title
Chandra BASE analysis of NoSQL database
US11625381B2 (en) Recreating an OLTP table and reapplying database transactions for real-time analytics
Kraska Finding the needle in the big data systems haystack
US20180075125A1 (en) Data partitioning and parallelism in a distributed event processing system
CN107958010B (zh) 用于在线数据迁移的方法及系统
JP5421269B2 (ja) Oltpデータをレポートするための、重複がないetlレスシステム及びその方法
CN102262680B (zh) 一种基于海量数据存取需求的分布式数据库代理系统
US11681651B1 (en) Lineage data for data records
CN108874567B (zh) 一种服务处理方法及系统
CN111339073A (zh) 实时数据处理方法、装置、电子设备及可读存储介质
CN110032594B (zh) 可定制化的多源数据库的数据抽取方法、装置及存储介质
CN113760922A (zh) 一种业务数据处理系统、方法、服务器和存储介质
RU2711348C1 (ru) Способ и система для обработки запросов в распределенной базе данных
CN111581227A (zh) 事件推送方法、装置、计算机设备及存储介质
CN113791586A (zh) 一种新型的工业app与标识注册解析集成方法
CN112445866A (zh) 数据处理方法、装置、计算机可读介质及电子设备
CN116108057A (zh) 一种分布式数据库访问方法、装置、设备及存储介质
US11816163B2 (en) Systems and methods for improved transactional mainframes
US20080256552A1 (en) System and method for a cics application using a same program on a local system and a remote system
CN102867029B (zh) 一种管理分布式文件系统目录的方法及分布式文件系统
US11048547B2 (en) Method and system for routing and executing transactions
US20210141791A1 (en) Method and system for generating a hybrid data model
Koschel et al. Evaluating time series database management systems for insurance company
CN113391933A (zh) 一种处理资金的方法
JP6680897B2 (ja) 計算機システム及び分析ソースデータ管理方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination