业务定时处理方法、装置、电子设备及存储介质与流程

1.本技术涉及数据处理技术领域，更具体地，涉及一种业务定时处理方法、装置、电子设备及存储介质。


背景技术：

2.在业务系统中，通常会存在需要定时处理的业务。现在的定时处理的业务的实现方案，需要专门的脚本机器运行，存在弹性扩缩容差、配置维护困难等问题。例如，使用linux系统自带的crontab组件(linux系统中用于设置周期性被执行的组件)，需要辅助对应的python或者shell脚本，来开发设计定时任务。然而，该实现方案需要部署、运行python/shell脚本，实现过程繁琐。


技术实现要素：

3.鉴于上述问题，本技术实施例提出了一种业务定时处理方法、装置、电子设备及存储介质，以改善上述问题。
4.第一方面，本技术实施例提供了一种业务定时处理方法，应用于定时处理进程，方法包括：获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间；基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中；获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件。
5.第二方面，本技术实施例提供了一种业务定时处理装置，应用于定时处理进程，装置包括：目标业务请求获取模块、业务事件存储模块以及超时业务事件执行模块。其中，目标业务请求获取模块，用于获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间；业务事件存储模块，用于基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中；超时业务事件执行模块，用于获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件。
6.第三方面，本技术实施例提供了一种电子设备，包括处理器以及存储器；一个或多个程序被存储在存储器中并被配置为由处理器执行以实现上述的方法。
7.第四方面，本技术实施例提供了一种计算机可读存储介质，计算机可读存储介质中存储有程序代码，其中，在程序代码被处理器运行时执行上述的方法。
8.第五方面，本技术实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的方法。
9.本技术实施例提供的一种业务定时处理方法、装置、电子设备及存储介质，通过获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间；基于业务处理时
间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中；获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件。通过直接在存储组件中配置任务分表，并使用任务分表模拟时间轮的数组槽，如此实现了业务定时处理功能，简化实现业务定时处理的过程，此外，由于能够直接在存储组件中配置任务分表，减少了通过分表中间件实现分表的过程，进一步简化实现业务定时处理的过程。
附图说明
10.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
11.图1示出了本技术实施例提出的一种应用环境的示意图；
12.图2示出了本技术实施例提出的另一种应用环境的示意图；
13.图3示出了本技术实施例提出的一种业务定时处理方法的流程图；
14.图4示出了本技术实施例提出的一种时间轮结构示意图；
15.图5示出了本技术实施例提出的另一种业务定时处理方法的流程图；
16.图6示出了图5所示实施例提出的一种业务定时处理方法中s230的一种实施方式的流程图；
17.图7示出了本技术实施例提出的另一种业务定时处理方法的流程图；
18.图8示出了本技术实施例提出的另一种业务定时处理方法的流程图；
19.图9示出了本技术实施例提出的另一种业务定时处理方法的流程图；
20.图10示出了本技术实施例提出的一种服务器的架构示意图；
21.图11示出了本技术实施例提出另一种业务定时处理方法的流程图；
22.图12示出了本技术实施例提出一种业务定时处理装置的结构框图；
23.图13示出了本技术实施例提出另一种业务定时处理装置的结构框图；
24.图14示出了用于执行根据本技术实施例的业务定时处理方法的另一种电子设备的结构框图；
25.图15示出了本技术实施例的用于保存或者携带实现根据本技术实施例的业务定时处理方法的程序代码的存储单元。
具体实施方式
26.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
27.在对本技术实施例进行进一步详细说明之前，对本技术实施例中涉及一种应用环境进行介绍。
28.如图1所示，图1所示为本技术实施例所涉及的应用环境的示意图。其中，包括有客
户端110以及服务器120，服务器包括定时处理组件121，定时处理组件121包括定时处理进程1211以及存储组件1212。其中，客户端110可以生成需要定时处理的业务请求，该需要定时处理的业务请求可以包括业务事件以及对应的业务处理时间，客户端110将需要定时处理的业务请求作为目标业务请求发送给服务器120，服务器在获得目标业务请求之后调用定时处理进程1211进行处理，定时处理进程1211基于业务处理时间，将业务事件存储在预先配置于存储组件中的任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，然后定时处理进程1211便可以获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件，最后再将执行结果返回给客户端。
29.需要说明的是，图1是一种示例性的应用环境，本技术实施例所提供的方法还可以运行于其他的应用环境中。
30.可选地，如图2所示，图2所示为本技术实施例所涉及的另一种应用环境的示意图。其中，包括有客户端110以及服务器120，服务器包括定时处理组件121以及业务处理组件122，定时处理组件121包括定时处理进程1211以及存储组件1212。其中，客户端110可以生成需要定时处理的业务请求，该需要定时处理的业务请求可以包括业务事件以及对应的业务处理时间，客户端110将需要定时处理的业务请求作为目标业务请求发送给服务器120中的业务处理组件122，业务处理组件122接收到目标业务请求之后，调用定时处理进程1211，定时处理进程1211基于业务处理时间，将业务事件存储在预先配置于存储组件1212中的任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，然后定时处理进程1211便可以获取并解析时间轮的指针指向的任务分表中的超时业务事件，得到超时业务事件各自对应的回调接口以及回调参数，根据回调接口以及回调参数调用业务处理组件122执行超时业务事件，最后再由业务处理组件122将执行结果返回给客户端。
31.需要说明的是，其中，服务器120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn(content delivery network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。客户端110所在的电子设备可以为智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载设备等，但并不局限于此。
32.下面将结合附图具体描述本技术的各实施例。
33.请参阅图3，图3所示为本技术一实施例提出的一种业务定时处理方法的流程图，在本实施例中，该方法可以应用于定时处理进程，该方法包括：
34.s110，获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间。
35.可以理解的是，目标业务请求为后续进行定时处理的业务请求。目标业务请求包括业务事件以及对应的业务处理时间。其中，业务事件可以理解为某个被执行的具体业务，业务事件对应的业务处理时间可以理解为某个具体业务的执行时间。
36.其中，目标业务请求可以有多种类型。
37.在一些实施方式中，目标业务请求可以是延期业务请求。示例性地，在微信支付委托代扣的扣费业务场景中，可以存在延期扣费请求，即商户可以发起从用户处延期扣费的请求，该延期扣费请求中，业务事件是从用户处扣费，业务事件对应的业务处理时间是从接收到目标业务请求的时间算起经过延期期限后的时间，例如接收到目标业务请求的时间是
第一天下午2点，延期期限是24小时，则业务事件对应的业务处理时间是第二天下午2点。
38.在另一些实施方式中，目标业务请求还可以是定时业务。示例性地，仍以在微信支付委托代扣的扣费业务场景为例，可以存在定时扣费请求，即商户可以发起从用户处定时扣费的请求，该定时扣费请求中，业务事件是从用户处扣费，业务事件对应的业务处理时间是定时时间，例如晚上12点。
39.需要说明的是，本技术实施例中的定时处理进程的数量可以是一个或者多个。
40.s120，基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中。
41.时间轮是指一条时间闭环履带，每一节代表等长时间，每一节对应一个数组槽，即时间轮是由多个数组槽串起来的轮子，每个数组槽下链接着未来时刻到期的时间节点，通过轮转数组槽，触发执行到期的时间节点任务，时间轮示意图如图4所示，假设图4中相邻数组槽到期时间的间隔为1秒，从当前时刻0秒开始计时，1秒时到期的指针指向数组槽1，2秒时到期的指针指向数组槽2，当检查到时间过去了1秒时，数组槽1中超时的业务事件执行超时动作，当时间到了2秒时，数组槽2中超时的业务事件执行超时动作，依次类推。当业务的触发时间超过8秒，那么就用触发时间对8取模，然后再保存到对应的数组槽中，即9秒后的任务存储在数组槽1中。需要说明的是，上述示例中是以时间轮的相邻数组槽到期时间的间隔为1秒进行说明，在另一些实施方式中，时间轮的相邻数组槽到期时间的间隔也可以为2秒、5秒、10秒等。
42.因此，为了执行需要定时处理的业务请求，本实施例中采用时间轮的方式，即在获取到业务事件以及对应的业务处理时间之后，可以基于业务处理时间，首先确定与该业务事件对应的数组槽。
43.此外，本技术实施例中的存储组件具有分表功能，即能够直接通过配置分表名称、分表字段以及分表数的方式得到分表，得到分表的方式简单，不需要额外的分表中间件实现分表功能，同时，通过直接配置分表数的方式也便于对分表的数量进行拓展，以便于支持不同的时长的定时业务请求。基于此，本技术实施例中，直接在存储组件中配置任务分表，在存储组件中配置得到任务分表之后，利用任务分表模拟时间轮的数组槽，从而可以使得任务分表与业务事件在时间轮中对应的数组槽对应，如此，便可以基于业务处理时间，直接将业务事件存储在任务分表中。其中，分表的路由键的生成方式等于业务处理事件对数组槽数量取模，从而通过分表的路由键来方便定位到某个特定的分表。
44.本实施例中，通过改变时间轮相邻数组槽到期时间的间隔，便于控制业务事件执行周期，此外，通过任务分表数量与时间轮相邻数组槽到期时间的间隔的乘积，可以确定延期或者定时处理的期限，便于对业务事件的期限进行管控。
45.s130，获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件。
46.超时业务事件是指时间轮的指针指向的数组槽对应的任务分表中，业务处理时间与当前时间相同的业务事件。由于时间轮的存储规律是业务处理时间对数组槽数量取模，因此，时间轮的数组槽对应的每个任务分表中可以存储多个业务事件，那么当指针指向数组槽对应的任务分表时，任务分表中的业务事件的业务处理时间有的是与当前时间相同的，此时，便获取到业务处理时间与当前时间相同的超时业务事件。接着，定时处理进程便
可以执行超时业务事件，从而实现对目标业务请求的定时处理。
47.在一些实施方式中，进一步结合图2所示，服务器包括定时处理组件121以及业务处理组件122，此时，执行超时业务事件，包括：解析超时业务事件，得到超时业务事件各自对应的回调接口以及业务参数，调用业务处理组件提供的回调接口处理业务参数。
48.可以理解的是，业务事件在具体被执行时，可以是调用接口对业务参数进行处理实现的，而本实施例中，处理业务参数的接口可以是由业务处理组件提供的回调接口，此时，定时处理进程便可以首先对超时业务事件进行解析，得到超时业务事件对应的回调接口以及业务参数，然后再调用业务处理组件提供的回调接口对业务参数进行处理，从而实现对目标业务请求的定时处理。
49.本技术实施例提供的一种业务定时处理方法，通过获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间；基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中；获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件。通过直接在存储组件中配置任务分表，并使用任务分表模拟时间轮的数组槽，如此实现了业务定时处理功能，相较于相关技术中采用crontab组件以及脚本的方式实现业务定时处理功能，省去了部署、运行脚本的过程，简化实现业务定时处理的过程。
50.在一些实施方式中，为了实现动态扩容或者缩容、提高业务处理效率、适应不同的业务量以及提高容灾能力，可以设置多个定时处理进程，每个定时处理进程分别与一个抢锁进程对应，抢锁进程用于从存储组件中抢锁。在这种情况下，请参阅图5，图5所示为本技术一实施例提出的一种业务定时处理方法的流程图，在本实施例中，该方法可以应用于多个定时处理进程中的任一个定时处理进程，该方法包括：
51.s210，获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间。
52.需要说明的是，本技术实施例中的多个定时处理进程可以是部署于同一台机器设备上的多个进程，也可以是部署于多台不同机器设备上的多个进程，同时，这多台机器设备可以分布在不同的区域，例如，多台机器设备可以分别分布在北京、四川、新疆等区域。
53.可以理解的是，由于设置了多个定时处理进程，在获取目标业务请求之前，就需要确定哪个定时处理进程来获取目标业务请求。其中，可以有多个确定哪个定时处理进程来获取目标业务请求的方式。
54.可选地，可以通过预先设置的负载均衡策略来确定哪个定时处理进程来获取目标业务请求。可选地，还可以通过目标业务请求的发送区域来确定哪个定时处理进程来获取目标业务请求，例如，目标业务请求是靠近新疆的客户端发送的，那么可以确定部署于新疆的机器设备上的定时处理进程来获取该目标业务请求。
55.另外，需要说明的是，由于业务系统中，在随时随地地产生业务请求，因此，多个定时处理进程可以是同时在获取不同的目标业务请求。
56.s220，基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中。
57.可以理解的是，多个定时处理进程可以是共用一个存储组件，那么不管是哪个定时处理进程获取到目标业务请求，均可以基于业务处理时间，将业务事件存储在任务分表中。
58.在一些实施方式中，考虑到可能存在机器宕机或者网络异常情况，从而导致定时处理进程的业务事件出现延迟、重复、丢失、乱序等问题，因此，为了提高业务定时处理时的容灾能力以及可用性，存储组件可以使用在多个定时处理进程进行业务事件存储时进行一致性验证的分布式存储组件。如此，通过采用分布式存储组件，并在多个定时处理进程进行业务事件存储时，对各个定时处理进程进行一致性验证，保证各个定时处理进程存储的业务事件的一致性，从而消除延迟、重复、丢失、乱序等问题。
59.s230，基于抢锁进程抢锁成功，获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件，其中，抢锁进程对应于定时处理进程，抢锁进程用于从存储组件中抢锁。
60.在一些实施方式中，可以存在多个定时处理进程，如果这多个定时处理进程均同时获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件的话，会出现对同一个超时业务事件重复执行多次的异常情况。例如，仍以微信支付委托代扣的扣费业务场景为例，某个任务分表中存在一个“24小时后，从消费者小王的账户中扣除100元”的业务事件，当过了24小时之后，时间轮的指针指向该任务分表时，该业务事件成为超时业务事件，当只有一个定时处理进程能够获取并执行该超时业务事件时，该超时业务事件被正常执行，即成功从小王的账户中扣除100元。但是在存在多个定时处理进程的情况下，如果不对这多个定时处理进程做并发控制，那么这多个定时处理进程都能够获取并执行该超时业务事件时，这就可能出现多次从小王账户扣除100元的情况，从而在小王账户错误扣费。
61.在一些实施例中，锁为悲观锁，悲观锁是指对数据被外界修改持保守态度，即在数据处理过程中，将数据处于锁定状态，不同线程同时执行时，只能有一个线程执行，其他的线程在入口处等待，直到锁被释放。也即，在本技术实施例中，只有抢锁成功的抢锁进程对应的定时处理线程，能够获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件，而其他定时处理线程则不能获取该超时业务事件。
62.引入悲观锁来对多个定时处理进程做并发控制，即每个定时处理进程分别对应一个抢锁进程，在时间轮的指针指向某个任务分表时，每个定时处理进程对应的抢锁进程先执行抢锁操作，从存储组件中抢锁，从而获得抢锁结果，并将抢锁结果发送给对应的定时处理进程。只有在某个定时处理进程获取到抢锁成功的抢锁结果时，该定时处理进程才能够获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件。
63.可以理解的是，在存在多个抢锁进程抢锁的情况下，抢锁成功的抢锁进程对应的定时处理进程能够从时间轮的指针指向的任务分表中获取超时业务事件并执行该超时业务事件，其他定时处理进程不能获取该超时业务事件，因此，为了提高业务处理效率以及提高容灾能力，即使设置多个定时处理进程，也能够保证业务事件的正常执行。
64.此外，为了避免某个抢锁进程在抢锁失败后立即再进行抢锁，即避免某个抢锁进程重复针对同一个超时业务事件多次抢锁，若某个抢锁进程对应的抢锁结果为抢锁失败，可以为抢锁失败的抢锁进程设置一个睡眠时间，例如，当时间轮的事件间隔为1秒时，可以设置一个小于1秒的睡眠时间，例如800毫秒，即过了800毫秒之后才能再次进行抢锁。
65.需要说明的是，本技术实施例的方式不仅适用于存在多个定时处理进程的场景，也适用于仅存在一个定时处理进程的场景，这种情况下，有且仅有一个进程进行抢锁，此时，该进程便是抢锁成功的定时处理进程。
66.在一些实施方式中，存储组件还包括运行记录表，运行记录表记录有当前运行时间，即当前应该执行哪一个时间节点的业务事件，当前运行时间可以是存储组件所在的机器设备的系统时间。在这种情况下，如图6所示，获取时间轮的指针指向的任务分表中的超时业务事件，包括：
67.s231，从运行记录表中获取当前运行时间。
68.由于抢锁成功的抢锁进程与存储组件所在的机器设备可以不是同一台机器设备，也可能是分布于不同区域的机器设备，因此，抢锁成功的抢锁进程的系统时间与运行记录表中的当前运行时间可能不同，因此，为了避免抢锁成功的抢锁进程的系统时间早于存储组件的系统时间，从而漏掉超时业务事件，或者，为了避免抢锁成功的抢锁进程的系统时间晚于存储组件的系统时间，从而重复获取超时业务事件，抢锁成功的抢锁进程对应的定时处理进程可以获取到运行记录表中记录的当前运行时间，并根据当前运行时间确定时间轮的指针指向的任务分表。
69.s232，基于当前运行时间，确定时间轮的指针指向的任务分表。
70.定时处理进程可以用当前运行时间对应的时间戳对时间轮的数组槽数量取模的方式，找到指定的任务分表，该任务分表即是时间轮的指针指向的任务分表。
71.s233，获取任务分表中的超时业务事件。
72.在确定时间轮的指针指向的任务分表，便可以获取到把任务分表中的超时业务事件。
73.为了适应不同业务量的目标业务请求，进一步提高业务系统可用性，在一些实施方式中，请参阅图7，图7所示为本技术一实施例提出的一种业务定时处理方法的流程图，在本实施例中，该方法可以应用于定时处理进程，该方法包括：
74.s310，获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间。
75.s320，基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中。
76.s330，获取时间轮的指针指向的任务分表中的超时业务事件。
77.s340，将超时业务事件发送到消息队列，以使消息队列进行存储。
78.可以理解的是，在一些情况下，时间轮的指针指向的任务分表中的超时业务事件的数量可能存在多个。例如在某个大促活动期间，业务量增加，此时，在每一秒钟可能存在大量的目标业务请求，这就使得在未来某个时间节点上，时间轮的指针指向的任务分表中的超时业务事件的数量可能存在多个，从而造成瞬时业务高峰，因此，可以通过在定时处理组件中增加消息队列的方式来削弱瞬时流量峰值。在这种情况下，某个定时处理进程在获取时间轮的指针指向的任务分表中的超时业务事件之后，可以先将超时业务事件发送到消息队列缓存。
79.s350，在接收到消息队列返回的超时业务事件时，执行超时业务事件。
80.定时处理进程既是超时业务事件的订阅者，也是超时业务事件的消费者。在定时处理进程将超时业务事件发送到消息队列之后，定时处理进程可以对消息队列中的超时业务事件进行订阅。因此，消息队列在处理某个超时业务事件时，会向对应的订阅者返回该超时业务事件。如此，订阅某个超时业务事件的定时处理进程在接收到消息队列返回的超时业务事件之后，可以由订阅该超时业务事件的定时处理进程执行。
81.本实施例中，可以通过增加消息队列的方式来削弱瞬时流量峰值，从而使得业务系统能够应对不同业务量的目标业务请求，进一步提高了业务系统可用性。
82.请参阅图8，图8所示为本技术一实施例提出的一种业务定时处理方法的流程图，在本实施例中，可以设置多个定时处理进程，每个定时处理进程分别与一个抢锁进程对应，抢锁进程用于从存储组件中抢锁，锁为悲观锁，并且，定时处理组件中增加消息队列，该方法可以应用于定时处理进程，该方法包括：
83.s410，获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间。
84.s420，基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中。
85.s430，在存储组件中的锁异常情况下，获取时间轮的指针指向的任务分表中的超时业务事件。
86.可以理解的是，在一些特殊情况下，存储组件中设置的悲观锁可能出现异常，这种情况下，抢锁进程不能正常抢锁，此时便不再能够对多个定时处理进程获取超时业务事件进行并发控制。这种情况下，可以将锁降级，不再提供并发控制的功能，抢锁进程也不用再进行抢锁，而是由各个定时处理进程同时从存储组件中的获取超时业务事件。
87.其中，各个定时处理进程同时从存储组件中的获取超时业务事件可以有多种方式。
88.在一种实施方式中，当悲观锁出现异常，但是运行记录表正常时，各个定时处理进程依然可以根据运行记录表中记录的当前运行时间获取超时业务事件。
89.在另一种实施方式中，当悲观锁出现异常，运行记录表也出现异常时，各个定时处理进程可以根据自身所在机器设备的系统时间获取超时业务事件。
90.s440，将超时业务事件发送到消息队列，以使消息队列进行去重处理。
91.由于是各个定时处理进程同时从存储组件中的获取超时业务事件，那么可能会获取到重复超时业务事件，从而对同一种超时业务事件重复执行多次的异常情况。因此，为了避免对同一种超时业务事件重复执行多次，各个定时处理进程在获取到超时业务事件之后，可以将各自获取的超时业务事件发送到消息队列中，由消息队列进行去重处理，从而保证每一种超时业务事件仅保留一个。
92.s450，在接收到消息队列返回的第一目标超时业务事件时，执行第一目标超时业务事件，第一目标超时业务事件是消息队列对接收到的所有定时处理进程分别发送的超时业务事件进行去重处理后的超时业务事件。
93.第一目标超时业务事件是指在消息队列去重处理之后，每种超时业务事件中剩下的一个超时业务事件。消息队列在对接收到所有定时处理进程分别发送的超时业务事件进行去重之后，可以对每一种超时业务事件仅保留一个，缓存在消息队列中，即每一种超时业务事件对应有一个第一目标超时业务事件，然后消息队列便可以将去重之后缓存的第一目标超时业务事件返回给一个定时处理进程，并由该定时处理进程执行该第一目标超时业务事件。
94.同样地，消息队列将去重之后缓存的第一目标超时业务事件返回给一个定时处理进程，可以有多种确定具体返回哪个定时处理进程的方式。可选地，可以通过预先设置的负载均衡策略来确定将第一目标超时业务事件返回给哪个定时处理进程。可选地，还可以通
过该业务事件的发送区域来确定将第一目标超时业务事件返回给哪个定时处理进程求。
95.本实施例中，通过在消息队列设置对接收到的超时业务事件进行去重的功能，可以避免出现业务系统对同一个超时业务事件重复执行多次的异常情况，从而保证业务系统的正常运行。
96.需要说明的是，本技术实施例的方法也适用于未设置抢锁进程的场景，此时，如果存在多个定时处理进程，那么每个定时处理进程均可以从存储组件中获取时间轮的指针指向的任务分表中的超时业务事件，并发送到消息队列中，由消息队列统一去重。
97.请参阅图9，图9所示为本技术一实施例提出的一种业务定时处理方法的流程图，该方法可以应用于定时处理进程，定时处理组件中增加消息队列，该方法包括：
98.s510，获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间。
99.s520，基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中。
100.s530，获取时间轮的指针指向的任务分表中的超时业务事件。
101.s540，将超时业务事件发送到消息队列，以使消息队列。
102.s550，在接收到消息队列返回的超时业务事件时，执行超时业务事件。
103.结合前述实施方式可以理解的是，定时处理进程接收的超时业务事件可以是在抢锁成功的情况下，发送到消息队列，并由消息队列返回的超时业务事件，也可以是在存储组件中的锁异常情况下或者未设置抢锁进程的情况下，消息队列返回的超时业务事件。
104.s560，在接收到消息队列返回的重复执行请求时，执行重复执行请求对应的第二目标超时业务事件，其中，重复执行请求是消息队列在超过第一预设时长未接收到第二目标超时业务事件对应的反馈结果时发送的。
105.可以理解的是，由于定时处理进程既是超时业务事件的订阅者，也是超时业务事件的消费者，因此，在正常情况下，业务处理进程可以向消息队列反馈对超时业务事件的执行结果，即反馈结果，反馈结果可以是执行业务事件成功或者执行业务事件失败。
106.其中，本技术实施例的方法可以应用于图1或者图2所示的应用环境中。
107.在图1所示的应用场景中，业务成功可以是定时处理进程1211根据自身执行结果确定执行业务事件成功，业务失败可以是指定时处理进程1211根据自身执行结果确定执行业务事件失败。
108.在图2所示的应用场景中，业务成功可以是定时处理进程1211在调用业务处理组件122提供的回调接口处理业务参数之后，定时处理进程1211再根据业务处理进程122返回的业务处理结果，确定执行超时业务事件的执行结果是执行业务成功还是执行业务失败。
109.同时，定时处理进程执行超时业务事件也是存在执行期限的，不可能一直执行，也就是说，在正常情况下，不管是执行业务事件成功还是执行业务事件失败，定时处理进程均会向消息队列返回反馈结果，因此，还可以预先设置定时处理进程执行业务事件的第一预设时长。第一预设时长可以根据实际业务事件进行确定，本技术实施例中不做具体限定。可选地，第一预设时长可以为15秒、30秒、1分钟等。
110.那么在这种情况下，如果消息队列超过第一预设时长未接收到定时处理进程发送的某个超时业务事件的反馈结果，消息队列可以认为该超时业务事件未被执行，消息队列进一步认为可能是系统失败，此时，消息队列可以将该超时业务事件确定为第二目标超时
业务事件，并基于目标超时业务事件生成重复执行请求，然后按照事先配置的返回时间间隔向订阅超时业务事件的定时处理进程返回重复执行请求，如此以便于订阅该第二目标超时业务事件的定时处理进程在接收到消息队列返回的重复执行请求时，能够再次执行该第二目标超时业务事件，从而避免漏掉某个超时业务事件。若接收到反馈结果，可以表明业务事件已经被执行，消息队列不用返回重复执行请求。
111.示例性地，假设在上述步骤s550之后，定时处理进程接收到消息队列返回的a、b、c这3个超时业务事件，其中，定时处理进程在收到超时业务事件a以及c后的第一预设时长内向消息队列返回了反馈结果，而未在收到超时业务事件b后的第一预设时长内向消息队列返回反馈结果，此时，消息队列将超时业务事件b确定为第二目标超时业务事件，并基于超时业务事件b生成重复执行请求，然后再将重复执行请求发送给定时处理进程，定时处理进程在接收到重复执行请求之后便可以执行重复执行请求对应的第二目标超时业务事件，即超时业务事件b。
112.其中，系统失败的原因可以是网络延时、业务处理进程异常等情况。
113.本实施例中，在系统失败的情况下，也即消息队列是在超过第一预设时长未接收到订阅超时业务事件的定时处理进程执行第二目标超时业务事件的反馈结果时，消息队列可以再次向订阅超时业务事件的定时处理进程发送第二目标超时业务事件，通过对消息队列的配置实现重新返回第二目标超时业务事件，从而使得在系统失败的情况下超时业务事件能够被重新执行，避免漏掉某个超时业务事件，同时，由于消息队列是通用组件，是经过长期验证的，可以减少代码出错的概率，进一步提高了可用性。
114.此外，考虑到在一些异常情况下，本该被正常获取并执行的超时业务事件最终没有被执行，从而导致漏掉了某些超时业务事件。例如，运行记录表中的当前运行时间更新之后，本该获取当前运行时间对应的任务分表中的超时业务事件的定时处理进程崩溃了，导致超时业务事件未被正常获取，最终更不会被执行，从而导致漏掉了某些超时业务事件。
115.因此，为了避免漏掉某些超时业务事件，可以在定时处理进程获取并将超时业务事件发送到消息队列之后，将超时业务事件的事件状态从未完成状态更新为已完成状态，从而通过超时业务事件的状态是否发生更新便可以判断某个超时业务事件是否被成功获取并发送到消息队列。同时，在定时处理组件中增加一个异常检查进程，异常检查进程用来扫描检查超过第二预设时长之后，事件状态未发生更新的超时业务事件，即异常业务事件。其中，第二预设时长可以根据业务事件能够容忍的被执行延迟确定，若业务事件能够容忍的被执行延迟较大，可以设置较大的第二预设时长，例如1小时、2小时、12小时等，若业务事件能够容忍的被执行延迟较小，可以设置较小的第二预设时长，例如5分钟、10分钟15分钟等。
116.需要说明的是，第二预设时长是从业务事件被确定为超时业务事件的时刻开始算起的。例如，当前时间为12点整，业务事件对应的业务处理时间为1小时，那么当1点整这个时刻，该业务事件被确定为超时业务事件，即1点整这个时刻，时间轮的指针指向该业务事件所在的任务分表，该业务事件成为超时业务事件，正常情况下，在1点整这个时刻，该超时业务事件会被定时处理进程正常获取并发送到消息队列，然后定时处理进程再将该超时业务事件的事件状态从未完成状态更新为已完成状态，但是如果存在异常情况，该超时业务事件未被正常获取，此时，从1点整这个时刻算起，如果设置的第二预设时长为15分钟，那么
异常检查进程在1点15分整这个时刻会扫描获取到该超时业务事件，并确定该超时业务事件为异常业务事件。
117.若异常检查进程在超过第二预设时长之后，检查到存在事件状态未发生更新的超时业务事件，即事件状态依然为未完成状态的异常业务事件，则将该异常业务事件发送给消息队列，再由消息队列发送给定时处理进程，此时，定时处理进程便可以获取并执行异常检查进程发送的异常业务事件。如此，可以保证异常业务事件被成功执行，从而避免漏掉业务事件。其中，定时处理进程可以是任一处于正常工作的定时处理进程。
118.此外，进一步考虑到，在一些异常情况下，超时业务事件被定时处理进程成功获取并发送到了消息队列，但是定时处理进程在更新超时业务事件的事件状态时，该定时处理进程发生崩溃或者重启，此时，未成功将该超时业务事件的状态从未完成状态更新到已完成状态，这就使得异常检查线程在超过第二预设时长之后会将此超时业务事件确定为异常业务事件。
119.然而，又由于超时业务事件已经被定时处理进程发送到了消息队列，虽然处理该超时业务事件的定时处理线程崩溃或者重启了，但是消息队列会在超过预设时长未接收到执行超时业务事件的反馈结果时，会一直向订阅超时业务事件的定时处理进程返回相同的超时业务事件，直到订阅超时业务事件的定时处理进程向消息队列返回反馈结果。因此，定时处理进程在获取到超时业务事件并发送到消息队列之后，便可以认为超时业务事件会被成功执行。
120.这种情况下，就可能存在某个超时业务事件实际上在订阅该超时业务事件的定时处理进程修复或者重启后被成功处理，但是其状态一直处于未完成状态，从而会被异常检查进程检测到，并再次发送到定时处理进程进行处理，从而造成业务事件多次执行的情况，也即存在幂等问题。面对这种情况，可以在异常检查进程将该异常业务事件发送给消息队列之后，由消息队列根据业务事件的业务标识，查询是否存在对应的反馈结果，从而判断该异常业务事件是否已经被执行。如果判断结果是已经被执行，则消息队列不会再将该异常业务事件发送给定时处理进程，如果判断结果是未被执行，则消息队列将该异常业务事件发送给定时处理进程。
121.消息队列在将异常业务事件发送给定时处理进程时，首先可以判断获取该业务事件的定时处理进程是否可用，如果可用，则将该异常业务事件发送给该定时处理进程，如果不可用，则将该异常业务事件发送给其他定时处理进程。
122.示例性地，可以将该业务事件的业务标识(task id)传入到客户端标识(client id)，对公共接口(public接口)返回的结果进行判断，如果错误码是同一个客户端标识重复发送，便可以认为该异常业务事件已经被执行过，不需要重复执行。
123.在一些实施方式中，为了节约存储组件的存储资源，在将超时业务事件的时间状态更新为已完成状态之后，可以经过一段时间将其删除。例如，可以设置一周、半个月或者一个月等时间之后将超时业务事件从存储组件中删除。
124.下面再结合图11对本技术实施例提供的业务定时处理方法的流程图进行详细介绍。图11所示的业务定时处理方法具体应用于图10所示的服务器架构示意图。
125.如图11所示，该服务器架构60包括定时处理组件61以及业务处理组件62，定时处理组件61包括定时处理进程611、存储组件612、抢锁进程613以及消息队列614，其中，定时
处理进程611的数量为多个，每个定时处理进程611分别与一个抢锁进程613对应。
126.如图11所示，该业务定时处理方法包括s701-s711。
127.s701，业务处理组件调用定时处理进程提供的接口，增加目标业务请求。
128.定时处理进程提供的接口可以是facade接口，facade接口是外观类为子系统提供一个共同的对外接口。
129.目标业务请求包括业务事件以及对应的业务处理时间，业务事件具体可以包括业务事件触发时需要调用的接口和对应参数。
130.s702，定时处理进程基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中。
131.存储组件是一个具有分表功能的分布式存储组件，可以通过配置分表名称、分表字段以及分表数的方式得到分表。此处可以新建任务分表，然后利用任务分表模拟时间轮的数组槽，接着便可以将业务事件对应的业务处理时间对任务分表数取模的方式，将业务事件存储在对应的任务分表中。
132.本技术实施例的业务定时处理方法中可以用到任务分表，任务分表用于存储运行任务信息，如触发时间，触发时回调业务方参数和接口信息，任务分表的表结构具体可以记录以下信息：
133.id integer:p。表示自增标识
134.task_type integer:n。表示任务类型。
135.biz_type integer:n。表示业务类型。
136.buffer varchar[2048]。表示数组槽。
[0137]
creat_time integer:n。表示创建时间。
[0138]
update_time integer:n。表示更新时间。
[0139]
state integer:n。表示事件状态。
[0140]
log_info varchar[4096]:n。表示日志记录。
[0141]
s703，多个抢锁进程进行抢锁，获取抢锁结果，将抢锁结果发送给对应的定时处理进程。
[0142]
多个定时处理进程对应的抢锁进程分别进行抢锁，获得抢锁结果，然后将抢锁结果发送给对应的定时处理进程，其中只有一个抢锁进程能够抢锁成功，也即只有一个定时处理进程获得的抢锁结果是抢锁成功。
[0143]
在抢锁进程进行抢锁时，需要用到运行记录表，每个抢锁进程分别从运行记录表中读取业务事件的当前运行时间，带有版本号iversion，然后把读取到的业务事件的当前运行时间加1，使用版本号iversion设置回存储组件，此时，只能够有一个抢锁进程是正确的版本号可以设置成功，其他抢锁进程的版本都落后于存储组件的版本，从而设置失败，即抢锁失败，设置成功的机器获取锁成功，即抢锁成功。
[0144]
本技术实施例的业务定时处理方法中还可以用到运行记录表，运行记录表用于实现全局锁，记录当前运行时间，运行记录表的表结构具体可以记录以下信息：
[0145]
id integer：p。表示自增标识。
[0146]
key varchar。表示键。
[0147]
type integer:n。表示业务等级。
[0148]
magic integer:n。表示校验值。
[0149]
current_time integer:n。表示当前运行时间。
[0150]
agent_item_list varchar[8192]。表示定时处理进程列表。
[0151]
s704，若抢锁成功，定时处理进程获取时间轮的指针指向的任务分表中的超时业务事件。
[0152]
抢锁结果为抢锁成功的定时处理进程可以用当前运行时间对任务分表的分表数取模的方式，找到对应的任务分表，即时间轮的指针指向的任务分表，此时便可以获取任务分表中的超时业务事件。
[0153]
本技术实施例的业务定时处理方法中还可以用到触发器表，触发器表用于记录触发任务，支持不同的任务触发方式。例如，定时触发或者crontab形式触发，其中，crontab形式可以为分-时-日-月-周-命令的形式。运行记录表的表结构具体可以记录以下信息：
[0154]
id integer：p。表示开始时间。
[0155]
job_id integer:n。表示业务标识。
[0156]
end_time integer:n。表示结束时间。
[0157]
s705，定时处理进程将超时业务事件发送给消息队列，以使消息队列进行存储，并将超时业务事件的事件状态修改为已完成状态。
[0158]
s706，消息队列将超时业务事件返回给定时处理进程。
[0159]
s707，定时处理进程接收消息队列返回的超时业务事件，执行超时业务事件。
[0160]
s708，定时处理进程解析业务事件，得到超时业务事件对应的回调接口以及业务参数，调用业务处理组件提供的回调接口处理业务参数。
[0161]
本实施例中，定时处理进程具体可以通过svrkit rpc的方式调用业务处理组件。其中，svrkit是远程调用框架。
[0162]
s709，定时处理进程判断是否接收到业务处理组件返回的反馈结果。
[0163]
其中，反馈结果是指执行业务成功或者执行业务失败的结果。
[0164]
s710，定时处理进程若接收到业务处理组件返回的反馈结果，向消息队列发送反馈结果，消息队列确定业务事件被执行。
[0165]
定时处理进程若接收到业务处理组件返回的反馈结果，则表明业务事件被执行，完成对业务事件的定时处理。
[0166]
s711，定时处理进程若未接收到业务处理组件返回的反馈结果，消息队列在超过第一预设时长未接收到执行超时业务事件的反馈结果时，向定时处理进程返回重复执行请求，以使定时处理进程执行重复执行请求对应的第二目标超时业务事件。
[0167]
消息队列在超过第一预设时长未接收到执行超时业务事件的反馈结果时，将该超时业务事件确定为第二目标超时业务事件，并基于目标超时业务事件生成重复执行请求，然后按照事先配置的返回时间间隔向订阅超时业务事件的定时处理进程返回重复执行请求，以使订阅第二目标超时业务事件的定时处理进程重复执行第二目标超时业务事件。
[0168]
需要说明的是，本技术提供以上一些具体可实施方式的示例，在互不抵触的前提下，各个实施例示例之间可任意组合，以形成新一种业务定时处理方法。应当理解的，对于由任意示例所组合形成的新一种业务定时处理方法，均应落入本技术的保护范围。
[0169]
请参阅图12，图12示出了本技术一实施例提出的一种业务定时处理装置800的框
图，该装置800包括：目标业务请求获取模块810、业务事件存储模块820以及超时业务事件执行模块830。
[0170]
目标业务请求获取模块810，用于获取目标业务请求，目标业务请求包括业务事件以及对应的业务处理时间；
[0171]
业务事件存储模块820，用于基于业务处理时间，将业务事件存储在任务分表中，任务分表与业务事件在时间轮中对应的数组槽对应，任务分表预先配置于存储组件中；
[0172]
超时业务事件执行模块830，用于获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件。
[0173]
作为一种实施方式，超时业务事件执行模块830用于：基于抢锁进程抢锁成功，获取时间轮的指针指向的任务分表中的超时业务事件，并执行超时业务事件，其中，抢锁进程对应于定时处理进程，抢锁进程用于从存储组件中抢锁。
[0174]
作为一种实施方式，超时业务事件执行模块830用于：获取时间轮的指针指向的任务分表中的超时业务事件；将超时业务事件发送到消息队列进行存储；在接收到消息队列返回的超时业务事件时，执行超时业务事件。
[0175]
作为一种实施方式，超时业务事件执行模块830用于：在存储组件中的锁异常情况下，获取时间轮的指针指向的任务分表中的超时业务事件；将超时业务事件发送到消息队列进行去重处理；在接收到消息队列返回的第一目标超时业务事件时，执行第一目标超时业务事件，第一目标超时业务事件是消息队列对接收到的所有定时处理进程分别发送的超时业务事件进行去重处理后的超时业务事件。
[0176]
作为一种实施方式，请参考图13，该装置800还包括：重复执行模块840，用于在接收到消息队列返回的重复执行请求时，执行重复执行请求对应的第二目标超时业务事件，其中，重复执行请求是消息队列在超过第一预设时长未接收到第二目标超时业务事件对应的反馈结果时发送的。
[0177]
作为一种实施方式，请参考图13，该装置800还包括：异常业务事件执行模块850，用于获取并执行异常检查进程发送的异常业务事件，异常业务事件为超过第二预设时长之后，事件状态未发生更新的超时业务事件，超时业务事件在被定时处理进程获取并发送到消息队列之后，事件状态发生更新。
[0178]
作为一种实施方式，存储组件还包括运行记录表，运行记录表记录有当前运行时间，超时业务事件执行模块830用于：从运行记录表中获取当前运行时间；基于当前运行时间，确定时间轮的指针指向的任务分表；获取任务分表中的超时业务事件。
[0179]
作为一种实施方式，存储组件为在多个定时处理进程进行业务事件存储时进行一致性验证的分布式存储组件。
[0180]
作为一种实施方式，超时业务事件执行模块830用于：解析超时业务事件，得到超时业务事件对应的回调接口以及业务参数；调用业务处理组件提供的回调接口处理业务参数。
[0181]
本技术实施例提供的一种业务定时处理装置，通过直接在存储组件中配置任务分表，并使用任务分表模拟时间轮的数组槽，如此实现了业务定时处理功能，相较于相关技术中采用crontab组件以及脚本的方式实现业务定时处理功能，省去了部署、运行脚本的过程，简化实现业务定时处理的过程，此外，由于能够直接在存储组件中配置任务分表，减少
了通过分表中间件实现分表的过程，进一步简化实现业务定时处理的过程。
[0182]
需要说明的是，本技术中装置实施例与前述方法实施例是相互对应的，装置实施例中具体的原理可以参见前述方法实施例中的内容，此处不再赘述。
[0183]
下面将结合图14对本技术提供的一种电子设备进行说明。
[0184]
请参阅图14，基于上述的业务定时处理方法，本技术实施例还提供的另一种包括可以执行前述业务定时处理方法的处理器104的电子设备200，该电子设备200可以为智能手机、平板电脑、计算机、车载设备或者便携式计算机等设备。电子设备200还包括存储器104、网络模块106以及屏幕108。其中，该存储器104中存储有可以执行前述实施例中内容的程序，而处理器102可以执行该存储器104中存储的程序。
[0185]
其中，处理器102可以包括一个或者多个用于处理数据的核以及消息矩阵单元。处理器102利用各种接口和线路连接整个电子设备200内的各个部分，通过运行或执行存储在存储器104内的指令、程序、代码集或指令集，以及调用存储在存储器104内的数据，执行电子设备200的各种功能和处理数据。可选地，处理器102可以采用数字信号处理(digital signal processing，dsp)、现场可编程门阵列(field－programmable gate array，fpga)、可编程逻辑阵列(programmable logic array，pla)中的至少一种硬件形式来实现。处理器102可集成中央处理器(central processing unit，cpu)、图像处理器(graphics processing unit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器102中，单独通过一块通信芯片进行实现。
[0186]
存储器104可以包括随机存储器(random access memory，ram)，也可以包括只读存储器(read-only memory)。存储器104可用于存储指令、程序、代码、代码集或指令集。存储器104可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储终端100在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。
[0187]
网络模块106用于接收以及发送电磁波，实现电磁波与电信号的相互转换，从而与通讯网络或者其他设备进行通讯，例如和音频播放设备进行通讯。网络模块106可包括各种现有的用于执行这些功能的电路元件，例如，天线、射频收发器、数字信号处理器、加密/解密芯片、用户身份模块(sim)卡、存储器等等。网络模块106可与各种网络如互联网、企业内部网、无线网络进行通讯或者通过无线网络与其他设备进行通讯。上述的无线网络可包括蜂窝式电话网、无线局域网或者城域网。例如，网络模块106可以与基站进行信息交互。
[0188]
屏幕108可以进行界面内容的显示，也可以用于响应触控手势。
[0189]
需要说明的是，为了实现更多的功能，电子设备200还可以保护更多的器件，例如，还可以保护用于进行人脸信息采集的结构光传感器或者还可以保护用于采集虹膜的摄像头等。
[0190]
请参考图15，其示出了本技术实施例提供的一种计算机可读存储介质的结构框图。该计算机可读介质1100中存储有程序代码，程序代码可被处理器调用执行上述方法实施例中所描述的方法。
[0191]
计算机可读存储介质1100可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。可选地，计算机可读存储介质1100包括非易失性计算机可读介质(non-transitory computer-readable storage medium)。计算机可读存储介质1100具有执行上述方法中的任何方法步骤的程序代码1110的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码1110可以例如以适当形式进行压缩。
[0192]
基于上述的业务定时处理方法，根据本技术实施例的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的各种可选实现方式中提供的方法。
[0193]
综上，本技术实施例提供的一种业务定时处理方法、装置、电子设备、存储介质及计算机程序产品或计算机程序，通过直接在存储组件中配置任务分表，并使用任务分表模拟时间轮的数组槽，如此实现了业务定时处理功能，相较于相关技术中采用crontab组件以及脚本的方式实现业务定时处理功能，省去了部署、运行脚本的过程，简化实现业务定时处理的过程，此外，由于能够直接在存储组件中配置任务分表，减少了通过分表中间件实现分表的过程，进一步简化实现业务定时处理的过程。
[0194]
最后应说明的是：以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。