业务数据的处理方法和装置、存储介质、电子装置
技术领域
本申请涉及数据处理领域,具体而言,涉及一种业务数据的处理方法和装置、存储介质、电子装置。
背景技术
热点账户具有以下特征,一是与该账户关联的交易量大,交易笔数多;二是与该账户关联的交易频次高,并发量高;严格意义上讲,只要符合上述两个特征的账户都可称为热点账户,而这里的账户不局限为实体账户、虚拟账户、记账簿等,只是在金融领域,账户的概念及场景涉及相对较广泛。
热点账户问题是在账户系统设计、开发中普遍需要解决的技术难点,需要解决单账户余额频繁修改导致锁并发从而影响整个系统吞吐性能的问题,目前解决的方法主要有以下几个:降低锁粒度,将热点单账户拆分多个子账户,将对一个账户的操作转化为对多个账户的操作,以此降低了锁的粒度,减少并发阻塞概率,从而提高整个系统吞吐性能;临时表异步更新,将所有对账户的操作保存在临时表中,然后异步通过定时任务扫描临时表对热点账户进行操作。
发明人经过对以上解决方案进行分析认识到:降低锁粒度主要存在以下几个缺点:会出现服务“停顿”,例如将扣减的热点账户拆分多个子账户,如果某个子账户余额不足,会对该子账户做资金归集,将其他子账户余额归集到该子账户(每个子账户设置可归集金额限制),而在资金归集过程,这个扣减的热点账户是“停顿”状态(即服务不可用状态);业务比较复杂,例如要查询热点账户余额,需要将所有的子账户余额进行汇总,汇总中各账户余额不是同一时刻状态,得到账户余额也是不准确的(业务操作频繁时,账户余额误差越大);无法彻底解决高并发业务场景下账户系统吞吐阻塞造成的问题。
临时表异步更新主要存在以下缺点:业务量巨大时,临时表的维护比较复杂,因为当临时表数据量很大时,需要解决大表查询、失效数据清除等问题,同时,异步更新的时效性,也很难保证。
针对上述的问题,目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种业务数据的处理方法和装置、存储介质、电子装置,以至少解决相关技术中业务数据的处理效率较低的技术问题。
根据本申请实施例的一个方面,提供了一种业务数据的处理方法,包括:获取业务应用中业务账号的业务操作,其中,业务操作用于业务账号指示对数据库中属于业务账号的目标业务数据进行处理;生成用于表示业务操作的目标业务消息;将目标业务消息保存至目标消息队列,其中,目标消息队列用于保存未被成功消费过的业务消息;在从目标消息队列中获取到目标业务消息的情况下,对数据库中的目标业务数据进行处理。
根据本申请实施例的另一方面,还提供了一种业务数据的处理装置,包括:获取单元,用于获取业务应用中业务账号的业务操作,其中,业务操作用于业务账号指示对数据库中属于业务账号的目标业务数据进行处理;生成单元,用于生成用于表示业务操作的目标业务消息;保存单元,用于将目标业务消息保存至目标消息队列,其中,目标消息队列用于保存未被成功消费过的业务消息;处理单元,用于在从目标消息队列中获取到目标业务消息的情况下,对数据库中的目标业务数据进行处理。
根据本申请实施例的另一方面,还提供了一种存储介质,该存储介质包括存储的程序,程序运行时执行上述的方法。
根据本申请实施例的另一方面,还提供了一种电子装置,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器通过计算机程序执行上述的方法。
在本申请实施例中,将待处理的业务操作以业务消息的形式保存在消息队列中进行蓄洪,无需维护热点子账户故无需维护复杂的业务逻辑,不必维护临时表规避了大临时表造成的低效率查询问题,可以解决相关技术中业务数据的处理效率较低的技术问题,进而达到提高处理效率的技术效果。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是根据本申请实施例的业务数据的处理方法的硬件环境的示意图;
图2是根据本申请实施例的一种可选的业务数据的处理方法的流程图;
图3是根据本申请实施例的可选的业务数据的处理方案的示意图;
图4是根据本申请实施例的可选的业务数据的处理方案的示意图;
图5是根据本申请实施例的一种可选的业务数据的处理装置的示意图;以及,
图6是根据本申请实施例的一种终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先,在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释:
消息队列:消息的传输过程中保存消息的容器,这里指具有收发消息完整功能的消息中间件;消息生产者是消息的发送方;消息消费者是消息的接收处理方。
kafkaMq:是一个高吞吐量分布式消息系统,是由开源的消息中间件。
多生产单消费模式:指可以有多个“生产者”(线程)并行发送消息给消息队列,同一时刻,只有一个“消费者”(线程)来接收处理消息队列消息。
在账户系统中,会频繁对一个账户信息(即热点账户的账户信息)进行修改,很容易发生多个线程同时修改的情况。基于此,根据本申请实施例的一方面,提供了一种业务数据的处理方法的方法实施例。
可选地,在本实施例中,上述业务数据的处理方法可以应用于如图1所示的由终端101和服务器103所构成的硬件环境中。如图1所示,服务器103通过网络与终端101进行连接,可用于为终端或终端上安装的客户端提供服务(如金融服务、网购服务等),可在服务器上或独立于服务器设置数据库105,用于为服务器103提供数据存储服务,上述网络包括但不限于:广域网、城域网或局域网,终端101并不限定于PC、手机、平板电脑等。
本申请实施例的业务数据的处理方法可以由服务器103来执行,也可以是由服务器103和终端101共同执行。图2是根据本申请实施例的一种可选的业务数据的处理方法的流程图,如图2所示,该方法可以包括以下步骤:
步骤S202,获取业务应用中业务账号的业务操作,业务操作用于业务账号指示对数据库中属于业务账号的目标业务数据进行处理。上述业务账号为在上述业务应用(如金融业务、购物平台等)中使用的热点账号。
步骤S204,生成用于表示业务操作的目标业务消息。
步骤S206,将目标业务消息保存至目标消息队列,目标消息队列用于保存未被成功消费过的业务消息,此处的未被成功消费过是指新收到的业务消息,还可以包括消费过但是处理失败的消息。
消息队列是消息的传输过程中保存消息的容器,可以采用具有收发消息完整功能的消息中间件。
步骤S208,在从目标消息队列中获取到目标业务消息的情况下,对数据库中的目标业务数据进行处理。
通过上述步骤S202至步骤S208,将待处理的业务操作以业务消息的形式保存在消息队列中进行蓄洪,无需维护热点子账户故无需维护复杂的业务逻辑,不必维护临时表规避了大临时表造成的低效率查询问题,可以解决相关技术中业务数据的处理效率较低的技术问题,进而达到提高处理效率的技术效果。下面结合图2所示的步骤进一步详述本申请的技术方案。
在步骤S202提供的技术方案中,获取业务应用中业务账号的业务操作,例如,用户购买理财产品时,购买理财产品这一业务操作即表示对数据库中属于该用户的目标业务数据进行处理,记录所购买的理财产品和购买数量。
在步骤S204提供的技术方案中,生成用于表示业务操作的目标业务消息,如按照预定的消息模板填写入需要修改所购买的理财产品和购买数量等的信息。
可选地,本方案可采用多生产单消费模式,指可以有多个“生产者”(线程)并行发送消息给消息队列,同一时刻,只有一个“消费者”(线程)来接收处理消息队列消息。生成用于表示业务操作的目标业务消息时,为了高效的处理消息,从多个生产者中查找目标生产者,目标生产者为多个生产者中资源利用率最低或者资源余量最大或者被指定的生产者;通过目标生产者生成用于表示业务操作的目标业务消息。
可选地,为了防止消息队列因为发生故障而导致消息丢失,在生成用于表示业务操作的目标业务消息之后,将目标业务消息保存至第二数据库,第二数据库用于备份生成的业务消息。
在步骤S206提供的技术方案中,将目标业务消息保存至目标消息队列,目标消息队列用于保存未被成功消费过的业务消息。
可选地,在将目标业务消息保存至目标消息队列之后,在通过对比目标消息队列中的业务消息和第二数据库中的业务消息确定目标业务消息保存失败或者目标消息队列发生故障的情况下,将第二数据库中的目标业务消息保存至目标消息队列,以避免因为故障或者失败导致的消息丢失影响用户的业务操作。
在步骤S208提供的技术方案中,在从目标消息队列中获取到目标业务消息的情况下,对数据库中的目标业务数据进行处理。
可选地,从目标消息队列中获取目标业务消息,确定多个消费者中的第一消费者,第一消费者是多个消费者中用于消费目标业务消息的消费者,在确定多个消费者中的第一消费者时,在目标消息队列的偏向锁未被分配的情况下,接收到多个消费者中的消费者获取偏向锁的请求,确定多个消费者中当前被分配偏向锁的消费者为第一消费者,其中,偏向锁用于获取目标消息队列中业务消息的处理权限;在目标消息队列的偏向锁已被分配的情况下,将多个消费者中被分配偏向锁的消费者作为第一消费者;通过目标消息队列从目标消息队列中获取目标业务消息。
为了保证业务的正常稳定处理,在将目标业务消息保存至目标消息队列之后,可以按照如下方式记录消息的处理状态:在第一消费者从目标消息队列中获取目标业务消息之后,将目标业务消息的处理状态由待处理变更为处理中;在对数据库中的目标业务数据的处理失败的情况下,将目标业务消息的处理状态由处理中变更为处理失败;在对数据库中的目标业务数据的处理完成的情况下,将目标业务消息的处理状态由处理中变更为处理成功。在对数据库中的目标业务数据进行处理之后,可将对目标业务消息的处理状态发送至目标生产者,以便于生产者能够实时了解消息的消费进度。
在对数据库中的目标业务数据的处理失败的情况下,在目标业务消息的处理失败次数未达到目标阈值的情况下,直接重复执行目标业务消息,或者将目标业务消息的处理状态由处理失败变更为待处理,并保存至目标消息队列,以等待再次被执行;在目标业务消息的处理失败次数达到目标阈值的情况下,将目标业务消息交由多个消费者中的第二消费者进行消费或者生产用于表示目标业务消息处理失败的提示信息,其中,第二消费者不同于第一消费者。
在上述方案中,无需维护热点子账户,故无需维护复杂的业务逻辑;采用消息队列进行消息“削峰”,可以彻底解决并发阻塞造成的系统性能瓶颈,同时不必维护临时表,规避了大临时表需要解决的问题;消费队列进行定制化改造使其具有可以支持串行顺序消费,无需自己维护并发相关问题,也不存在“锁”失败导致大量重试的无谓消耗系统资源的问题。
作为一种可选的实施例,下面结合具体的实施方式进一步详述本申请的技术方案。
热点账户问题一直是金融等账户系统中不得不面对、不得不解决的问题。虽然相关技术中采用“热点子账户”、“临时账户异步更新”等解决方案,但是这些方案,特别是在大业务量场景下,带来的业务系统复杂度提升、影响业务系统性能和时效性等问题一直困扰着相关开发人员。本方案中采用支持大数据量、高并发场景的消息中间件,例如rabbitMq、rocketMq、kafkaMq、fMq等。
消息队列创建可在高并发场景下进行“削峰”限流,提高系统可用性、稳定性和吞吐性能,以及异步解耦,提高系统内聚性。“同步转异步,并行转串行”是解决热点账户核心思想,消息队列这种天然的异步、缓冲特性,非常适合解决热点账户问题。
如直接使用消息中间件来解决热点账户问题,只是简单使用消息中间件作为异步通信的工具,没有将锁并发、消息丢失以及重试、消息重复消费进行统一管理,而是由业务系统自己维护,并不会很好降低业务开发的开发工作量和难度,还会带来系统的额外开销。
因此,本申请提出了基于消息队列解决账户系统热点账户难题,结合当前热点账户系统中需要处理的难点和解决思想,对消息中间件进行定制化开发与重构,提供了一套完善账户问题解决方案,规避了现有解决方案中业务复杂、开发难度高、时效性不及时、即时账户余额不准确等问题。在本申请的改进的消息中间件中提供了以下定制化功能:
(1)防止消息丢失功能
账户系统对系统的稳定性要求极高,任何账户操作的遗漏都会造成用户金额的损失,因此,在改进的消息队列客户端中,集成了防止消息丢失功能。该功能在生产者发送消息出现异常时,可以将消息保存到数据库Redis中(同时也支持持久化mysql数据库),并自动进行重试或者报警。
(2)多生产者生产消息,单消费者消费消息功能
相关技术中的解决方案都是由业务系统提供锁并发控制,这种方案往往会带来一些问题,比如会获取并发锁失败重试消费的系统开销,从而影响系统性能。在改进的消息队列中,将并发锁机制进行了优化,原有的“同步锁”升级成“偏向锁”,即多消费客户端在消费时,如果某一个客户端获取了消息消费的并发锁,那么以后该队列的所有消息都由该客户端消费。同时为了防止单客户端消费带来的“单点”问题,改进消息队列中引入了失败检查机制,如果该客户端消费失败超过了用户定义的失败配置(包括失败次数、重试次数以及持续时间等指标)时,会切换到新客户端进行消费或者业务报警。
(3)消费回调功能
原有的消息中间件都是单程通信,也就是说消息的生产者只知道消息发送成功,却无法知道消息是否业务处理成功,这种情况往往会导致各个服务之间状态不一致,导致后续操作失败。为此,在改进的消息队列客户端中,提供了消息回调功能,即当消费者处理完消息时,会回调生产者处理消息的结果(该功能也具有重试、报警相关机制)。
基于改进的消息队列解决账户系统中热点账户问题具体方法如下:
步骤1,如图3和图4所示,在业务层检测到业务操作时,消息中间件(采用改进的消息队列)生产消息,将所有业务操作中对热点账户操作发送到消息队列(保存在主从消息队列中),同时开启防止消息丢失功能。
在发送mq消息失败的情况下保存消息内容,并进行重试,多次重试仍然失败的情况下可以进行报警。
步骤2,消费消息,幂等消费消息(防止消息队列中重复信息),可以串行消费消息,对热点账户进行操作,并将更新热点帐户的操作结果返回给业务系统,成功则更新相关数据库,非业务的失败则抛出异常进行重试(如果是业务的失败,则说明无法重试成功,故不要抛出异常进行重试)。
步骤3,回调消费消息,将更新热点账户结果返回对应业务方(生产者),完成业务闭环,并将处理结果持久化保存在数据库中。
采用本申请的技术方案,降低了账户系统热点账户的业务复杂度和开发难度,不必维护并发冲突、临时表复杂业务逻辑,大大提升了开发效率;提升了热点账户余额即时性,规避了定时任务的延时影响;不存在系统“停顿”问题(即子账户资金归集导致服务不可用)。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本申请各个实施例的方法。
根据本申请实施例的另一个方面,还提供了一种用于实施上述业务数据的处理方法的业务数据的处理装置。图5是根据本申请实施例的一种可选的业务数据的处理装置的示意图,如图5所示,该装置可以包括:
获取单元501,用于获取业务应用中业务账号的业务操作,其中,业务操作用于业务账号指示对数据库中属于业务账号的目标业务数据进行处理;
生成单元503,用于生成用于表示业务操作的目标业务消息;
保存单元505,用于将目标业务消息保存至目标消息队列,其中,目标消息队列用于保存未被成功消费过的业务消息;
处理单元507,用于在从目标消息队列中获取到目标业务消息的情况下,对数据库中的目标业务数据进行处理。
需要说明的是,该实施例中的获取单元501可以用于执行本申请实施例中的步骤S202,该实施例中的生成单元503可以用于执行本申请实施例中的步骤S204,该实施例中的保存单元505可以用于执行本申请实施例中的步骤S206,该实施例中的处理单元507可以用于执行本申请实施例中的步骤S208。
此处需要说明的是,上述模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在如图1所示的硬件环境中,可以通过软件实现,也可以通过硬件实现。
通过上述模块,将待处理的业务操作以业务消息的形式保存在消息队列中进行蓄洪,无需维护热点子账户故无需维护复杂的业务逻辑,不必维护临时表规避了大临时表造成的低效率查询问题,可以解决相关技术中业务数据的处理效率较低的技术问题,进而达到提高处理效率的技术效果。
可选地,装置还包括:备份单元,用于在生成用于表示业务操作的目标业务消息之后,将目标业务消息保存至第二数据库,其中,第二数据库用于备份生成的业务消息;恢复单元,用于在将目标业务消息保存至目标消息队列之后,在通过对比目标消息队列中的业务消息和第二数据库中的业务消息确定目标业务消息保存失败或者目标消息队列发生故障的情况下,将第二数据库中的目标业务消息保存至目标消息队列。
可选地,生成单元包括:查找模块,用于从多个生产者中查找目标生产者,其中,目标生产者为多个生产者中资源利用率最低或者资源余量最大或者被指定的生产者;生成模块,用于通过目标生产者生成用于表示业务操作的目标业务消息。
可选地,处理单元包括:确定模块,用于确定多个消费者中的第一消费者,其中,第一消费者是多个消费者中用于消费目标业务消息的消费者;获取模块,用于通过目标消息队列从目标消息队列中获取目标业务消息。
可选地,所述确定模块还用于:在所述目标消息队列的偏向锁未被分配的情况下,接收到所述多个消费者中的消费者获取所述偏向锁的请求,确定所述多个消费者中当前被分配所述偏向锁的消费者为所述第一消费者,其中,所述偏向锁用于获取所述目标消息队列中业务消息的处理权限;在所述目标消息队列的所述偏向锁已被分配的情况下,将所述多个消费者中被分配所述偏向锁的消费者作为所述第一消费者。
可选地,上述装置还可包括状态管理单元,用于在将所述目标业务消息保存至目标消息队列之后,在所述第一消费者从所述目标消息队列中获取所述目标业务消息之后,将所述目标业务消息的处理状态由待处理变更为处理中;在对所述数据库中的所述目标业务数据的处理失败的情况下,将所述目标业务消息的处理状态由处理中变更为处理失败;在对所述数据库中的所述目标业务数据的处理完成的情况下,将所述目标业务消息的处理状态由处理中变更为处理成功;在对所述数据库中的所述目标业务数据进行处理之后,将对所述目标业务消息的处理状态发送至目标生产者。
可选地,上述装置还可包括,故障处理单元,用于在对所述数据库中的所述目标业务数据的处理失败的情况下,在所述目标业务消息的处理失败次数未达到目标阈值的情况下,直接重复执行所述目标业务消息,或者将所述目标业务消息的处理状态由处理失败变更为待处理,并保存至所述目标消息队列,以等待再次被执行;在所述目标业务消息的处理失败次数达到所述目标阈值的情况下,将所述目标业务消息交由多个消费者中的第二消费者进行消费或者生产用于表示所述目标业务消息处理失败的提示信息,其中,所述第二消费者不同于所述第一消费者。
此处需要说明的是,上述模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在如图1所示的硬件环境中,可以通过软件实现,也可以通过硬件实现,其中,硬件环境包括网络环境。
根据本申请实施例的另一个方面,还提供了一种用于实施上述业务数据的处理方法的服务器或终端。
图6是根据本申请实施例的一种终端的结构框图,如图6所示,该终端可以包括:一个或多个(图6中仅示出一个)处理器601、存储器603、以及传输装置605,如图6所示,该终端还可以包括输入输出设备607。
其中,存储器603可用于存储软件程序以及模块,如本申请实施例中的业务数据的处理方法和装置对应的程序指令/模块,处理器601通过运行存储在存储器603内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的业务数据的处理方法。存储器603可包括高速随机存储器,还可以包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器603可进一步包括相对于处理器601远程设置的存储器,这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的传输装置605用于经由一个网络接收或者发送数据,还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中,传输装置605包括一个网络适配器(Network Interface Controller,NIC),其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中,传输装置605为射频(Radio Frequency,RF)模块,其用于通过无线方式与互联网进行通讯。
其中,具体地,存储器603用于存储应用程序。
处理器601可以通过传输装置605调用存储器603存储的应用程序,以执行下述步骤:
获取业务应用中业务账号的业务操作,其中,所述业务操作用于所述业务账号指示对数据库中属于所述业务账号的目标业务数据进行处理;
生成用于表示所述业务操作的目标业务消息;
将所述目标业务消息保存至目标消息队列,其中,所述目标消息队列用于保存未被成功消费过的业务消息;
在从所述目标消息队列中获取到所述目标业务消息的情况下,对所述数据库中的所述目标业务数据进行处理。
处理器601还用于执行下述步骤:
在生成用于表示所述业务操作的目标业务消息之后,将所述目标业务消息保存至第二数据库,其中,所述第二数据库用于备份生成的业务消息;
在将所述目标业务消息保存至目标消息队列之后,在通过对比所述目标消息队列中的业务消息和所述第二数据库中的业务消息确定所述目标业务消息保存失败或者所述目标消息队列发生故障的情况下,将所述第二数据库中的所述目标业务消息保存至所述目标消息队列。
可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例在此不再赘述。
本领域普通技术人员可以理解,图6所示的结构仅为示意,终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices,MID)、PAD等终端设备。图6其并不对上述电子装置的结构造成限定。例如,终端还可包括比图6中所示更多或者更少的组件(如网络接口、显示装置等),或者具有与图6所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:闪存盘、只读存储器(Read-Only Memory,ROM)、随机存取器(RandomAccess Memory,RAM)、磁盘或光盘等。
本申请的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以用于执行业务数据的处理方法的程序代码。
可选地,在本实施例中,上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
可选地,在本实施例中,存储介质被设置为存储用于执行以下步骤的程序代码:
获取业务应用中业务账号的业务操作,其中,所述业务操作用于所述业务账号指示对数据库中属于所述业务账号的目标业务数据进行处理;
生成用于表示所述业务操作的目标业务消息;
将所述目标业务消息保存至目标消息队列,其中,所述目标消息队列用于保存未被成功消费过的业务消息;
在从所述目标消息队列中获取到所述目标业务消息的情况下,对所述数据库中的所述目标业务数据进行处理。
可选地,存储介质还被设置为存储用于执行以下步骤的程序代码:
在生成用于表示所述业务操作的目标业务消息之后,将所述目标业务消息保存至第二数据库,其中,所述第二数据库用于备份生成的业务消息;
在将所述目标业务消息保存至目标消息队列之后,在通过对比所述目标消息队列中的业务消息和所述第二数据库中的业务消息确定所述目标业务消息保存失败或者所述目标消息队列发生故障的情况下,将所述第二数据库中的所述目标业务消息保存至所述目标消息队列。
可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例在此不再赘述。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在上述计算机可读取的存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在存储介质中,包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。
在本申请的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。