Business timing processing methods, devices, electronic equipment and storage media

Abstract

This application discloses a service timing processing method, apparatus, electronic device, and storage medium. The method includes: acquiring a target service request, the target service request including a service event and a corresponding service processing time; storing the service event in a task partition table based on the service processing time, the task partition table corresponding to an array slot in a time wheel, the task partition table being pre-configured in a storage component; acquiring a timed-out service event in the task partition table pointed to by the pointer of the time wheel, and executing the timed-out service event. This method simplifies the process of implementing service timing processing.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a business timing processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] In business systems, there are often tasks that require scheduled processing. Current solutions for scheduled tasks require dedicated script machines, which suffer from issues such as scalability limitations, difficulty in configuration and maintenance, and other problems. For example, using the Crontab component (a component in Linux used to schedule periodic executions) requires the assistance of corresponding Python or Shell scripts to develop and design the scheduled tasks. However, this approach involves deploying and running Python / Shell scripts, making the process cumbersome. Summary of the Invention

[0003] In view of the above problems, embodiments of this application propose a service timing processing method, apparatus, electronic device and storage medium to improve the above problems.

[0004] In a first aspect, embodiments of this application provide a business timed processing method applied to a timed processing process. The method includes: obtaining a target business request, the target business request including a business event and a corresponding business processing time; storing the business event in a task partition table based on the business processing time, the task partition table corresponding to the array slot of the business event in the time wheel, the task partition table being pre-configured in a storage component; obtaining a timeout business event in the task partition table pointed to by the pointer of the time wheel, and executing the timeout business event.

[0005] Secondly, embodiments of this application provide a business timing processing apparatus for a timing processing process. The apparatus includes: a target business request acquisition module, a business event storage module, and a timeout business event execution module. The target business request acquisition module acquires a target business request, which includes a business event and its corresponding business processing time. The business event storage module stores the business event in a task partition table based on the business processing time. The task partition table corresponds to the array slot of the business event in the time wheel, and the task partition table is pre-configured in a storage component. The timeout business event execution module acquires the timeout business event in the task partition table pointed to by the pointer of the time wheel and executes the timeout business event.

[0006] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory; one or more programs are stored in the memory and configured to be executed by the processor to implement the above-described method.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, wherein the above-described method is executed when the program code is run by a processor.

[0008] Fifthly, embodiments of this application provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned method. Embodiments of this application provide a business timing processing method, apparatus, electronic device, and storage medium. This method involves obtaining a target business request, which includes a business event and a corresponding business processing time; storing the business event in a task partition table based on the business processing time, with the task partition table corresponding to the array slot in the time wheel for each business event; and pre-configuring the task partition table in a storage component. It also involves obtaining a timed-out business event from the task partition table pointed to by the time wheel pointer and executing the timed-out business event. By directly configuring the task partition table in the storage component and using the task partition table to simulate the array slot of the time wheel, the business timing processing function is realized, simplifying the process of implementing business timing processing. Furthermore, since the task partition table can be directly configured in the storage component, the process of implementing partitioning through partitioning middleware is reduced, further simplifying the process of implementing business timing processing. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 A schematic diagram of an application environment proposed in an embodiment of this application is shown;

[0011] Figure 2 A schematic diagram of another application environment proposed in the embodiments of this application is shown;

[0012] Figure 3 A flowchart of a service timing processing method proposed in an embodiment of this application is shown;

[0013] Figure 4 A schematic diagram of a time wheel structure according to an embodiment of this application is shown;

[0014] Figure 5 A flowchart of another service timing processing method proposed in an embodiment of this application is shown;

[0015] Figure 6 It shows Figure 5 A flowchart of one implementation of S230 in a service timing processing method proposed in the illustrated embodiment;

[0016] Figure 7 A flowchart of another service timing processing method proposed in an embodiment of this application is shown;

[0017] Figure 8 A flowchart of another service timing processing method proposed in an embodiment of this application is shown;

[0018] Figure 9 A flowchart of another service timing processing method proposed in an embodiment of this application is shown;

[0019] Figure 10 A schematic diagram of a server architecture according to an embodiment of this application is shown;

[0020] Figure 11 A flowchart of another service timing processing method proposed in this application embodiment is shown;

[0021] Figure 12 This paper presents a structural block diagram of a service timing processing device according to an embodiment of the present application.

[0022] Figure 13 This invention provides a structural block diagram of another service timing processing apparatus according to an embodiment of the present application.

[0023] Figure 14 A structural block diagram of another electronic device for performing a service timing processing method according to an embodiment of this application is shown;

[0024] Figure 15 A storage unit for storing or carrying program code implementing the business timing processing method according to an embodiment of the present application is shown. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0026] Before providing a more detailed description of the embodiments of this application, an application environment related to the embodiments of this application will be introduced.

[0027] like Figure 1 As shown, Figure 1The diagram illustrates the application environment involved in this embodiment. It includes a client 110 and a server 120. The server includes a timed processing component 121, which comprises a timed processing process 1211 and a storage component 1212. The client 110 generates a business request requiring timed processing. This request may include a business event and its corresponding processing time. The client 110 sends this request to the server 120 as the target business request. After receiving the target request, the server invokes the timed processing process 1211 for processing. Based on the processing time, the timed processing process 1211 stores the business event in a pre-configured task table in the storage component. The task table corresponds to the array slot in the time wheel corresponding to the business event. The timed processing process 1211 then retrieves the timed-out business event from the task table pointed to by the time wheel pointer, executes the timed-out event, and finally returns the execution result to the client.

[0028] It should be noted that, Figure 1 This is an exemplary application environment, and the method provided in this application embodiment can also be run in other application environments.

[0029] Optionally, such as Figure 2 As shown, Figure 2 The diagram shown illustrates another application environment involved in an embodiment of this application. It includes a client 110 and a server 120. The server includes a timing processing component 121 and a business processing component 122. The timing processing component 121 includes a timing processing process 1211 and a storage component 1212. The client 110 can generate a business request that needs to be processed periodically. This business request can include a business event and its corresponding processing time. The client 110 sends the business request that needs to be processed periodically as the target business request to the business processing component 122 in the server 120. After receiving the target business request, the business processing component 122 calls the timed processing process 1211. Based on the business processing time, the timed processing process 1211 stores the business event in a task partition table pre-configured in the storage component 1212. The task partition table corresponds to the array slot of the business event in the time wheel. Then, the timed processing process 1211 can obtain and parse the timed business events in the task partition table pointed to by the pointer of the time wheel, obtain the callback interface and callback parameters corresponding to each timed business event, and call the business processing component 122 to execute the timed business event according to the callback interface and callback parameters. Finally, the business processing component 122 returns the execution result to the client.

[0030] It should be noted that server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The electronic device where client 110 is located can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, in-vehicle device, etc., but is not limited to these.

[0031] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0032] Please see Figure 3 , Figure 3 The diagram shown is a flowchart of a business timing processing method according to an embodiment of this application. In this embodiment, the method can be applied to a timing processing process, and the method includes:

[0033] S110, Obtain the target business request, which includes the business event and the corresponding business processing time.

[0034] It is understandable that the target business request is a business request that will be processed periodically later. The target business request includes a business event and its corresponding processing time. Here, a business event can be understood as a specific business operation being executed, and the processing time corresponding to the business event can be understood as the execution time of that specific business operation.

[0035] The target business request can be of various types.

[0036] In some implementations, the target business request can be a deferred business request. For example, in the WeChat Pay entrusted deduction business scenario, there can be a deferred deduction request, that is, the merchant can initiate a request to deduct the user's payment on a deferred basis. In this deferred deduction request, the business event is to deduct the payment from the user, and the business processing time corresponding to the business event is the time after the deferred period, calculated from the time the target business request is received. For example, if the target business request is received at 2 pm on the first day and the deferred period is 24 hours, then the business processing time corresponding to the business event is 2 pm on the second day.

[0037] In other implementations, the target business request can also be a scheduled business. For example, taking the deduction business scenario of WeChat Pay's entrusted deduction as an example, there can be a scheduled deduction request, that is, the merchant can initiate a request to deduct money from the user at a scheduled time. In this scheduled deduction request, the business event is to deduct money from the user, and the business processing time corresponding to the business event is a scheduled time, such as 12 o'clock at night.

[0038] It should be noted that the number of timed processing processes in the embodiments of this application can be one or more.

[0039] S120 stores business events in task partition tables based on business processing time. The task partition tables correspond to the array slots in the time wheel for each business event. The task partition tables are pre-configured in the storage component.

[0040] A time wheel is a closed-loop time conveyor belt, where each segment represents an equal time interval and corresponds to an array slot. In other words, the time wheel is a wheel made up of multiple array slots strung together. Each array slot is linked to a future time node that expires. By rotating the array slots, the tasks at the expired time nodes are triggered and executed. A diagram of the time wheel is shown below. Figure 4 As shown, assuming Figure 4 The expiration time interval between adjacent array slots in the time wheel is 1 second. The timer starts from 0 seconds. At 1 second, the pointer indicating an expiration points to array slot 1; at 2 seconds, it points to array slot 2. When 1 second has elapsed, the timed-out business event in array slot 1 executes a timeout action; when 2 seconds have elapsed, the timed-out business event in array slot 2 executes a timeout action, and so on. If the trigger time of a business event exceeds 8 seconds, the trigger time is modulo 8, and then stored in the corresponding array slot. That is, the task after 9 seconds is stored in array slot 1. It should be noted that the above example uses a 1-second interval between adjacent array slot expiration times in the time wheel. In other implementations, the interval between adjacent array slot expiration times in the time wheel can also be 2 seconds, 5 seconds, 10 seconds, etc.

[0041] Therefore, in order to execute business requests that require timed processing, this embodiment adopts a time wheel approach. That is, after obtaining the business event and the corresponding business processing time, the array slot corresponding to the business event can be determined first based on the business processing time.

[0042] Furthermore, the storage component in this embodiment has a table partitioning function, meaning that partitions can be obtained directly by configuring the partition name, partition fields, and number of partitions. Obtaining partitions is simple and does not require additional partitioning middleware. Simultaneously, directly configuring the number of partitions facilitates expansion of the number of partitions to support timed business requests of different durations. Based on this, in this embodiment, task partitions are configured directly in the storage component. After obtaining the task partitions in the storage component, the task partitions are used to simulate the array slots of the time wheel, allowing the task partitions to correspond to the array slots of the business events in the time wheel. Thus, business events can be directly stored in the task partitions based on the business processing time. The routing key for the partition is generated by taking the modulo of the number of array slots for the business processing event, thereby facilitating the location of a specific partition.

[0043] In this embodiment, by changing the interval between the expiration times of adjacent array slots of the time wheel, it is convenient to control the execution cycle of business events. In addition, by multiplying the number of task sub-tables by the interval between the expiration times of adjacent array slots of the time wheel, the period for delayed or timed processing can be determined, which facilitates the management of the period of business events.

[0044] S130: Obtain the timeout business event from the task sub-table pointed to by the time wheel pointer, and execute the timeout business event.

[0045] A timeout event refers to a business event in the task table corresponding to the array slot pointed to by the time wheel pointer, where the business processing time is the same as the current time. Since the time wheel stores data modulo the business processing time by the number of array slots, each task table corresponding to a time wheel slot can store multiple business events. Therefore, when the pointer points to the task table corresponding to the array slot, some of the business events in that table will have the same business processing time as the current time. In this case, a timeout event with the same business processing time as the current time is obtained. The scheduled processing process can then execute the timeout event, thereby achieving scheduled processing of the target business request.

[0046] In some implementations, further combined Figure 2 As shown, the server includes a timed processing component 121 and a business processing component 122. At this time, the execution of timeout business events includes: parsing the timeout business events, obtaining the callback interfaces and business parameters corresponding to each timeout business event, and calling the callback interfaces provided by the business processing component to process the business parameters.

[0047] It is understandable that when a business event is actually executed, it can be implemented by calling an interface to process business parameters. In this embodiment, the interface for processing business parameters can be a callback interface provided by the business processing component. At this time, the timed processing process can first parse the timeout business event to obtain the callback interface and business parameters corresponding to the timeout business event, and then call the callback interface provided by the business processing component to process the business parameters, thereby realizing the timed processing of the target business request.

[0048] This application provides a method for timed business processing. It involves acquiring a target business request, which includes a business event and its corresponding processing time. Based on the processing time, the business event is stored in a task partition table, which corresponds to an array slot in the time wheel. The task partition table is pre-configured in a storage component. The method then retrieves a timed-out business event from the task partition table pointed to by the time wheel pointer and executes the timed-out event. By directly configuring the task partition table in the storage component and using it to simulate the array slots of the time wheel, timed business processing is achieved. Compared to related technologies that use Crontab components and scripts to implement timed business processing, this method eliminates the need for script deployment and execution, simplifying the implementation of timed business processing.

[0049] In some implementations, to achieve dynamic scaling up or down, improve business processing efficiency, adapt to different business volumes, and enhance disaster recovery capabilities, multiple timed processing processes can be set up. Each timed processing process corresponds to a lock-acquiring process, which is used to acquire locks from storage components. In this case, please refer to [link to relevant documentation]. Figure 5 , Figure 5 The diagram shown is a flowchart of a business timing processing method according to an embodiment of this application. In this embodiment, the method can be applied to any one of multiple timing processing processes. The method includes:

[0050] S210, Obtain the target business request, which includes the business event and the corresponding business processing time.

[0051] It should be noted that the multiple timed processing processes in this application embodiment can be multiple processes deployed on the same machine device, or multiple processes deployed on multiple different machine devices. At the same time, these multiple machine devices can be distributed in different regions. For example, the multiple machine devices can be distributed in regions A, B, C, etc.

[0052] Understandably, since multiple timed processing processes are set up, it is necessary to determine which timed processing process will retrieve the target business request before doing so. There are several ways to determine which timed processing process will retrieve the target business request.

[0053] Optionally, a pre-configured load balancing strategy can be used to determine which timed processing process should acquire the target service request. Alternatively, the sending region of the target service request can also be used to determine which timed processing process should acquire the target service request. For example, if the target service request is sent by a client located near region C, then the timed processing process deployed on the machine or device located in region C can be selected to acquire the target service request.

[0054] Additionally, it should be noted that since business requests are generated anytime and anywhere in the business system, multiple timed processing processes can simultaneously acquire different target business requests.

[0055] S220 stores business events in task partition tables based on business processing time. The task partition tables correspond to the array slots in the time wheel for each business event, and the task partition tables are pre-configured in the storage component.

[0056] It is understandable that multiple timed processing processes can share a single storage component. Therefore, regardless of which timed processing process obtains the target business request, the business event can be stored in the task partition table based on the business processing time.

[0057] In some implementations, considering the possibility of machine downtime or network anomalies that could lead to delays, duplications, losses, or out-of-order delivery of business events in the scheduled processing process, a distributed storage component can be used to improve the disaster recovery capabilities and availability of scheduled business processing. This component performs consistency verification on the business events stored by multiple scheduled processing processes. By employing a distributed storage component and performing consistency verification on each scheduled processing process during business event storage, the consistency of the business events stored by each process is guaranteed, thereby eliminating problems such as delays, duplications, losses, and out-of-order delivery.

[0058] S230: Based on the successful acquisition of the lock by the lock-grabbing process, the timeout business event in the task sub-table pointed to by the time wheel pointer is obtained and the timeout business event is executed. The lock-grabbing process corresponds to the timed processing process and is used to acquire the lock from the storage component.

[0059] In some implementations, multiple timed processing processes can exist. If these multiple timed processing processes simultaneously acquire and execute timed-out business events in the task sub-table pointed to by the time wheel pointer, an abnormal situation may occur where the same timed-out business event is executed multiple times. For example, taking the WeChat Pay direct debit scenario as an example, a task sub-table contains a business event: "Deduct 100 yuan from consumer Xiao Wang's account in 24 hours." After 24 hours, when the time wheel pointer points to this task sub-table, the business event becomes a timed-out business event. If only one timed processing process can acquire and execute this timed-out business event, it is executed normally, i.e., 100 yuan is successfully deducted from Xiao Wang's account. However, if multiple timed processing processes exist and concurrency control is not implemented, then if all of them can acquire and execute the timed-out business event, it is possible that 100 yuan will be deducted from Xiao Wang's account multiple times, resulting in incorrect deductions from Xiao Wang's account.

[0060] In some embodiments, the lock is a pessimistic lock, which means that it takes a conservative approach to data modification from the outside. That is, during data processing, the data is kept in a locked state, and when different threads execute simultaneously, only one thread can execute at a time, while the other threads wait at the entry point until the lock is released. In other words, in this embodiment, only the timed processing thread corresponding to the lock-acquiring process that successfully acquires the lock can obtain the timeout business event in the task sub-table pointed to by the time wheel pointer and execute the timeout business event, while other timed processing threads cannot obtain the timeout business event.

[0061] Pessimistic locking is introduced to control concurrency among multiple timed processing processes. Each timed processing process corresponds to a lock-grabbing process. When the time wheel pointer points to a specific task table, each timed processing process's corresponding lock-grabbing process first performs a lock-grabbing operation, attempting to acquire the lock from the storage component. The process then sends the lock-grabbing result to its corresponding timed processing process. Only when a timed processing process successfully acquires the lock can it retrieve the timeout business event from the task table pointed to by the time wheel pointer and execute the timeout business event.

[0062] Understandably, when multiple lock-grabbing processes are competing for the lock, the timed processing process corresponding to the successful lock-grabbing process can obtain the timeout business event from the task sub-table pointed to by the time wheel pointer and execute the timeout business event. Other timed processing processes cannot obtain the timeout business event. Therefore, in order to improve business processing efficiency and disaster recovery capabilities, even if multiple timed processing processes are set up, the normal execution of business events can be guaranteed.

[0063] In addition, to prevent a locking process from immediately attempting to acquire a lock again after a failed attempt, i.e., to prevent a locking process from repeatedly attempting to acquire a lock for the same timeout event, a sleep time can be set for the locking process if the locking result for the failed attempt is a lock acquisition failure. For example, when the event interval of the time wheel is 1 second, a sleep time of less than 1 second can be set, such as 800 milliseconds, meaning that the locking process can only attempt to acquire a lock again after 800 milliseconds.

[0064] It should be noted that the method of this application embodiment is not only applicable to scenarios with multiple timed processing processes, but also to scenarios with only one timed processing process. In this case, only one process attempts to acquire the lock, and this process is the timed processing process that successfully acquires the lock.

[0065] In some implementations, the storage component also includes a runtime log table that records the current runtime, i.e., which time point's business event should be executed at the current time. The current runtime can be the system time of the machine or device where the storage component resides. In this case, such as... Figure 6 As shown, retrieve the timeout business events in the task sub-table pointed to by the time wheel pointer, including:

[0066] S231, retrieve the current running time from the running record table.

[0067] Since the machine on which the successful lock-acquiring process resides and the storage component may not be the same machine, or they may be machines located in different regions, the system time of the successful lock-acquiring process may differ from the current running time in the running log table. Therefore, to avoid the system time of the successful lock-acquiring process being earlier than the system time of the storage component, thus missing timeout service events, or to avoid the system time of the successful lock-acquiring process being later than the system time of the storage component, thus repeatedly obtaining timeout service events, the timed processing process corresponding to the successful lock-acquiring process can obtain the current running time recorded in the running log table and determine the task sub-table to which the time wheel pointer points based on the current running time.

[0068] S232, based on the current running time, determine the task sub-table that the time wheel pointer points to.

[0069] The timed processing process can find the specified task sub-table by taking the modulo of the number of array slots of the time wheel with the timestamp corresponding to the current running time. This task sub-table is the one pointed to by the pointer of the time wheel.

[0070] S233, retrieve timeout business events from the task sub-table.

[0071] Once the task sub-table pointed to by the time wheel pointer is determined, the timeout business events in the task sub-table can be obtained.

[0072] To adapt to target business requests with varying volumes and further improve the availability of the business system, please refer to the following implementation methods: Figure 7 , Figure 7 The diagram shown is a flowchart of a business timing processing method according to an embodiment of this application. In this embodiment, the method can be applied to a timing processing process, and the method includes:

[0073] S310, Obtain the target business request, which includes the business event and the corresponding business processing time.

[0074] S320 stores business events in task partition tables based on business processing time. The task partition tables correspond to the array slots in the time wheel for each business event, and the task partition tables are pre-configured in the storage component.

[0075] S330, retrieve the timeout business event in the task sub-table pointed to by the time wheel pointer.

[0076] S340 sends timeout service events to a message queue for storage.

[0077] Understandably, in some situations, the number of timeout events in the task partition table pointed to by the time wheel pointer may be multiple. For example, during a major promotional event, business volume increases, and there may be a large number of target business requests every second. This means that at some future time point, the number of timeout events in the task partition table pointed to by the time wheel pointer may be multiple, causing a momentary business spike. Therefore, adding a message queue to the scheduled processing component can mitigate this momentary traffic spike. In this case, after a scheduled processing process retrieves the timeout events in the task partition table pointed to by the time wheel pointer, it can first send the timeout events to the message queue cache.

[0078] S350 executes the timeout service event when it receives a timeout service event returned by the message queue.

[0079] The scheduled processing process is both a subscriber and a consumer of timeout service events. After the scheduled processing process sends a timeout service event to the message queue, it can subscribe to timeout service events in the message queue. Therefore, when the message queue processes a timeout service event, it returns the timeout service event to the corresponding subscriber. Thus, after receiving the timeout service event returned by the message queue, the scheduled processing process that subscribed to that timeout service event can execute it.

[0080] In this embodiment, instantaneous traffic spikes can be mitigated by adding message queues, thereby enabling the business system to handle target business requests with different volumes of business, and further improving the availability of the business system.

[0081] Please see Figure 8 , Figure 8 The diagram shows a flowchart of a business timing processing method according to an embodiment of this application. In this embodiment, multiple timing processing processes can be set up, each corresponding to a lock-grabbing process. The lock-grabbing process is used to grab a lock from the storage component. The lock is a pessimistic lock. Furthermore, a message queue is added to the timing processing component. This method can be applied to the timing processing processes, and the method includes:

[0082] S410, Obtain the target business request, which includes the business event and the corresponding business processing time.

[0083] S420 stores business events in task partition tables based on business processing time. The task partition tables correspond to the array slots in the time wheel for each business event, and the task partition tables are pre-configured in the storage component.

[0084] S430, in the event of a lock exception in the storage component, retrieves the timeout business event from the task sub-table pointed to by the time wheel pointer.

[0085] Understandably, in certain special circumstances, the pessimistic lock set in the storage component may malfunction. In such cases, the lock-acquiring process cannot acquire the lock normally, and concurrent control over the acquisition of timeout business events by multiple timed processing processes can no longer be achieved. In this situation, the lock can be downgraded, no longer providing concurrency control functionality, and the lock-acquiring process no longer needs to attempt to acquire the lock. Instead, each timed processing process simultaneously acquires timeout business events from the storage component.

[0086] There are several ways for each timed processing process to simultaneously retrieve timeout business events from the storage component.

[0087] In one implementation, when a pessimistic lock malfunctions but the runtime log table is normal, each timed processing process can still obtain timeout service events based on the current runtime recorded in the runtime log table.

[0088] In another implementation, when a pessimistic lock malfunctions and the runtime log table also malfunctions, each timed processing process can obtain timeout service events based on the system time of its own machine.

[0089] S440 sends timeout service events to the message queue so that the message queue can perform deduplication.

[0090] Since each timed processing process retrieves timeout events from the storage component simultaneously, it's possible to obtain duplicate timeout events, leading to the abnormal situation of executing the same timeout event multiple times. Therefore, to avoid multiple executions of the same timeout event, each timed processing process sends its retrieved timeout event to a message queue after obtaining it. The message queue then performs deduplication, ensuring that only one instance of each timeout event is retained.

[0091] S450, upon receiving the first target timeout service event returned by the message queue, execute the first target timeout service event. The first target timeout service event is the timeout service event after the message queue has deduplicated all the timeout service events sent by the received timed processing processes.

[0092] The first target timeout event refers to the single timeout event remaining among all timeout events after deduplication in the message queue. After deduplicating the timeout events received from all timed processing processes, the message queue can retain only one instance of each type of timeout event, caching it in the message queue. That is, each timeout event corresponds to one first target timeout event. The message queue can then return the deduplicated, cached first target timeout event to a timed processing process, which will then execute that first target timeout event.

[0093] Similarly, the message queue returns the first target timeout business event, after deduplication and caching, to a scheduled processing process. There are several ways to determine which scheduled processing process to return the event to. Optionally, a pre-configured load balancing strategy can be used to determine which scheduled processing process to return the first target timeout business event to. Alternatively, the sending region of the business event can also be used to determine which scheduled processing process to return the first target timeout business event to.

[0094] In this embodiment, by setting up a function to deduplicate received timeout service events in the message queue, the abnormal situation of the business system repeatedly executing the same timeout service event can be avoided, thereby ensuring the normal operation of the business system.

[0095] It should be noted that the method in this application embodiment is also applicable to scenarios where no lock-grabbing process is set. In this case, if there are multiple timed processing processes, each timed processing process can obtain the timeout business event in the task sub-table pointed to by the time wheel pointer from the storage component and send it to the message queue for unified deduplication.

[0096] Please see Figure 9 , Figure 9The diagram shown is a flowchart of a business timed processing method according to an embodiment of this application. This method can be applied to a timed processing process, and a message queue is added to the timed processing component. The method includes:

[0097] S510: Obtain the target business request, which includes the business event and the corresponding business processing time.

[0098] S520 stores business events in task partition tables based on business processing time. The task partition tables correspond to the array slots in the time wheel for each business event, and the task partition tables are pre-configured in the storage component.

[0099] S530 retrieves the timeout business event from the task sub-table pointed to by the time wheel pointer.

[0100] S540 sends timeout service events to the message queue to enable the message queue.

[0101] When the S550 receives a timeout service event returned by the message queue, it executes the timeout service event.

[0102] Based on the aforementioned implementation methods, it can be understood that the timeout service event received by the timed processing process can be a timeout service event sent to the message queue and returned by the message queue when the lock acquisition is successful, or a timeout service event returned by the message queue when the lock in the storage component is abnormal or when no lock acquisition process is set.

[0103] S560, when receiving a repeat execution request returned by the message queue, execute the second target timeout service event corresponding to the repeat execution request, wherein the repeat execution request is sent by the message queue when no feedback result corresponding to the second target timeout service event is received after a first preset time period.

[0104] Understandably, since the timed processing process is both a subscriber and a consumer of timeout business events, under normal circumstances, the business processing process can send feedback on the execution result of the timeout business event to the message queue, i.e., feedback result. The feedback result can be either successful execution of the business event or failure of the business event.

[0105] The method in this application embodiment can be applied to Figure 1 or Figure 2 The application environment shown.

[0106] exist Figure 1 In the application scenario shown, business success can be determined by the timed processing process 1211 based on its own execution result, indicating that the business event was successfully executed. Business failure can be determined by the timed processing process 1211 based on its own execution result, indicating that the business event was unsuccessful.

[0107] exist Figure 2 In the application scenario shown, business success can be determined by the timed processing process 1211 after calling the callback interface provided by the business processing component 122 to process the business parameters, and then the timed processing process 1211 determines whether the execution result of the timeout business event is successful or unsuccessful based on the business processing result returned by the business processing process 122.

[0108] Meanwhile, the timed processing process also has an execution period for timed-out business events; it cannot execute indefinitely. In other words, under normal circumstances, regardless of whether the business event execution is successful or fails, the timed processing process will return a feedback result to the message queue. Therefore, a first preset duration for the timed processing process to execute business events can be preset. This first preset duration can be determined based on the actual business event, and is not specifically limited in this embodiment. Optionally, the first preset duration can be 15 seconds, 30 seconds, 1 minute, etc.

[0109] In this scenario, if the message queue does not receive feedback from the timed processing process for a timeout service event within a first preset timeout period, the message queue can assume that the timeout service event has not been executed. The message queue may further consider this a system failure. In this case, the message queue can designate this timeout service event as a second target timeout service event and generate a re-execution request based on the target timeout service event. Then, it returns the re-execution request to the timed processing process subscribed to the timeout service event at a pre-configured return timeout interval. This ensures that the timed processing process subscribed to the second target timeout service event can re-execute the second target timeout service event upon receiving the re-execution request from the message queue, thus avoiding missing any timeout service events. If feedback is received, it indicates that the service event has already been executed, and the message queue does not need to return a re-execution request.

[0110] For example, suppose that after step S550 above, the timing process receives three timeout service events A, B, and C returned by the message queue. The timing process returns feedback results to the message queue within a first preset time after receiving timeout service events A and C, but does not return feedback results to the message queue within the first preset time after receiving timeout service event B. At this time, the message queue determines timeout service event B as the second target timeout service event, generates a repeat execution request based on timeout service event B, and then sends the repeat execution request to the timing process. After receiving the repeat execution request, the timing process can execute the second target timeout service event corresponding to the repeat execution request, i.e., timeout service event B.

[0111] System failures can be caused by factors such as network latency or abnormal business processing.

[0112] In this embodiment, in the event of system failure, that is, when the message queue does not receive feedback from the timed processing process of the subscribed timeout service event after a first preset timeout period, the message queue can resend the second target timeout service event to the timed processing process of the subscribed timeout service event. By configuring the message queue, the second target timeout service event can be returned again, so that the timeout service event can be re-executed in the event of system failure, avoiding the omission of a timeout service event. At the same time, since the message queue is a general component that has been verified over a long period of time, it can reduce the probability of code errors and further improve availability.

[0113] Furthermore, considering that under certain abnormal circumstances, timeout business events that should have been properly acquired and executed may not ultimately be executed, resulting in the omission of some timeout business events. For example, after the current runtime in the runtime log table is updated, the timed processing process that should acquire the timeout business events in the task sub-table corresponding to the current runtime crashes, causing the timeout business events to not be acquired normally and ultimately not be executed, thus resulting in the omission of some timeout business events.

[0114] Therefore, to avoid missing some timeout events, after the scheduled processing process acquires and sends the timeout event to the message queue, the event status of the timeout event can be updated from "unfinished" to "completed." This allows us to determine whether a timeout event was successfully acquired and sent to the message queue simply by checking if its status has been updated. Simultaneously, an exception checking process is added to the scheduled processing component. This process scans for timeout events whose status has not been updated after a second preset timeout period; these are considered abnormal events. The second preset timeout period can be determined based on the tolerable execution delay of the business event. If the tolerable execution delay is large, a larger second preset timeout period can be set, such as 1 hour, 2 hours, or 12 hours. If the tolerable execution delay is small, a smaller second preset timeout period can be set, such as 5 minutes, 10 minutes, or 15 minutes.

[0115] It should be noted that the second preset duration starts from the moment the business event is determined to be a timeout business event. For example, if the current time is 12:00 and the business processing time corresponding to the business event is 1 hour, then at 1:00, the business event is determined to be a timeout business event. That is, at 1:00, the time wheel pointer points to the task sub-table where the business event is located, and the business event becomes a timeout business event. Under normal circumstances, at 1:00, the timeout business event will be normally obtained by the timed processing process and sent to the message queue. Then, the timed processing process will update the event status of the timeout business event from uncompleted to completed. However, if there is an abnormal situation and the timeout business event is not normally obtained, then, starting from 1:00, if the second preset duration is set to 15 minutes, the anomaly checking process will scan and obtain the timeout business event at 1:15 and determine that the timeout business event is an abnormal business event.

[0116] If the anomaly checking process detects a timed-out business event whose event status has not been updated (i.e., the event status is still incomplete) after a second preset timeout, it sends the abnormal business event to the message queue, which then sends it to the scheduled processing process. The scheduled processing process can then retrieve and execute the abnormal business event sent by the anomaly checking process. This ensures that abnormal business events are successfully executed, thus preventing missed business events. The scheduled processing process can be any normally functioning scheduled processing process.

[0117] Furthermore, considering that in some abnormal situations, the timed-out business event may be successfully acquired and sent to the message queue by the timed processing process, but the timed processing process crashes or restarts when updating the event status of the timed-out business event. In this case, the status of the timed-out business event is not successfully updated from the unfinished state to the completed state. This causes the exception checking thread to identify the timed-out business event as an abnormal business event after the second preset time has elapsed.

[0118] However, since the timeout event has already been sent to the message queue by the scheduled processing process, even if the scheduled processing thread handling the timeout event crashes or restarts, the message queue will continue to return the same timeout event to the scheduled processing processes subscribed to the timeout event if no feedback result is received after a preset timeout period, until the scheduled processing processes subscribed to the timeout event return a feedback result to the message queue. Therefore, after the scheduled processing process obtains the timeout event and sends it to the message queue, it can be assumed that the timeout event has been successfully executed.

[0119] In this scenario, a timeout event might actually be successfully processed after the scheduled processing process subscribed to it has been repaired or restarted, but its status remains incomplete. This can be detected by the exception checking process and sent back to the scheduled processing process for processing, resulting in multiple executions of the business event—a situation known as idempotency. To address this, after the exception checking process sends the abnormal business event to the message queue, the message queue can check for a corresponding feedback result based on the business event's business identifier to determine if the abnormal business event has already been executed. If the result indicates execution, the message queue will not send the abnormal business event back to the scheduled processing process; if the result indicates no execution, the message queue will then send the abnormal business event back to the scheduled processing process.

[0120] When a message queue sends an abnormal business event to a scheduled processing process, it can first determine whether the scheduled processing process that retrieves the business event is available. If it is available, the abnormal business event is sent to that scheduled processing process; if it is not available, the abnormal business event is sent to another scheduled processing process.

[0121] For example, the task ID of the business event can be passed to the client ID, and the result returned by the public interface can be judged. If the error code is sent repeatedly by the same client ID, it can be considered that the abnormal business event has been executed and does not need to be executed again.

[0122] In some implementations, to conserve storage resources, timed-out service events can be deleted after a certain period of time following the update of their time status to "completed." For example, a period of one week, half a month, or one month can be set before deleting timed-out service events from the storage component.

[0123] Next, let's combine... Figure 11 The flowchart of the service timing processing method provided in the embodiments of this application is described in detail. Figure 11 The business timing processing method shown is specifically applied to Figure 10 The diagram shows a server architecture.

[0124] like Figure 11 As shown, the server architecture 60 includes a timed processing component 61 and a business processing component 62. The timed processing component 61 includes a timed processing process 611, a storage component 612, a lock-grabbing process 613, and a message queue 614. There are multiple timed processing processes 611, and each timed processing process 611 corresponds to a lock-grabbing process 613.

[0125] like Figure 11 As shown, the timed processing method for this service includes S701-S711.

[0126] S701, the business processing component calls the interface provided by the timed processing process to add target business requests.

[0127] The interface provided by the timed processing process can be a facade interface, which is a facade class that provides a common external interface for the subsystem.

[0128] The target business request includes the business event and the corresponding business processing time. Specifically, the business event can include the interface to be called when the business event is triggered and the corresponding parameters.

[0129] S702, the timed processing process stores business events in task sub-tables based on business processing time. The task sub-tables correspond to the array slots of the business events in the time wheel, and the task sub-tables are pre-configured in the storage component.

[0130] The storage component is a distributed storage component with table partitioning capabilities. Table partitions can be configured by specifying the partition name, partition fields, and the number of partitions. Here, a task partition can be created, and then used to simulate the array slots of the time wheel. The business event's corresponding processing time can then be stored in the corresponding task partition by taking the modulo of the number of task partitions.

[0131] The business timing processing method in this application embodiment can use task partitioning. Task partitioning is used to store running task information, such as trigger time, callback parameters and interface information of the business party when triggered. The specific table structure of task partitioning can record the following information:

[0132] Id INTEGER:P. This indicates an auto-incrementing identifier.

[0133] task_type INTEGER:N. This indicates the task type.

[0134] biz_type INTEGER:N. This indicates the business type.

[0135] Buffer VARCHAR

[2048] . Represents an array slot.

[0136] Creat_time INTEGER:N. This indicates the creation time.

[0137] `update_time INTEGER:N` indicates the update time.

[0138] state INTEGER:N. Indicates the event state.

[0139] log_info VARCHAR

[4096] :N. Represents a log record.

[0140] S703: Multiple lock-grabbing processes compete for the lock, obtain the lock-grabbing result, and send the lock-grabbing result to the corresponding timed processing process.

[0141] Multiple timed processing processes each attempt to acquire the lock, obtain the acquisition result, and then send the result to the corresponding timed processing process. Only one of these processes can successfully acquire the lock, meaning only one timed processing process receives the result indicating successful acquisition.

[0142] During the lock acquisition process, a runtime log table is used. Each lock acquisition process reads the current runtime of the business event from the runtime log table, along with the version number iVersion. Then, it increments the current runtime of the business event by 1 and sets the version number iVersion back to the storage component. At this point, only one lock acquisition process can successfully set the correct version number. The versions of other lock acquisition processes are behind the version of the storage component, thus the setting fails, i.e., the lock acquisition fails. The machine that successfully sets the version number acquires the lock successfully, i.e., the lock acquisition is successful.

[0143] The business timing processing method in this application embodiment can also use a running record table. The running record table is used to implement a global lock and record the current running time. The table structure of the running record table can specifically record the following information:

[0144] id INTEGER: P. This represents an auto-incrementing identifier.

[0145] `key` is a VARCHAR variable representing a key.

[0146] type INTEGER:N. Indicates the service level.

[0147] Magic INTEGER:N. This represents the checksum.

[0148] current_time INTEGER:N. This represents the current running time.

[0149] Agent_item_list VARCHAR

[8192] . Represents a list of timed processing processes.

[0150] S704, if the lock acquisition is successful, the timed processing process obtains the timeout business event from the task sub-table pointed to by the time wheel pointer.

[0151] If the lock acquisition result is successful, the timed processing process can find the corresponding task sub-table by taking the modulo of the number of task sub-tables with the current running time, that is, the task sub-table pointed to by the time wheel pointer. At this time, the timeout business event in the task sub-table can be obtained.

[0152] The business timing processing method in this application embodiment can also use a trigger table. The trigger table records trigger tasks and supports different task triggering methods. For example, it can be timed triggering or crontab triggering, where crontab can be in the format of minute-hour-day-month-week-command. The table structure of the execution record table can specifically record the following information:

[0153] id INTEGER: P. Indicates the start time.

[0154] job_id INTEGER:N. This represents the business identifier.

[0155] end_time INTEGER:N. This indicates the end time.

[0156] S705: The timed processing process sends timeout service events to the message queue so that the message queue can store them and change the event status of the timeout service events to the completed status.

[0157] S706, the message queue returns timed-out business events to the given processing process.

[0158] S707, the timed processing process receives timeout service events returned by the message queue and executes the timeout service events.

[0159] S708, the timed processing process parses business events, obtains the callback interface and business parameters corresponding to the timeout business event, and calls the callback interface provided by the business processing component to process the business parameters.

[0160] In this embodiment, the timed processing process can specifically call the business processing component via svrkit RPC. Here, svrkit is a remote procedure call framework.

[0161] S709, the timed processing process determines whether it has received feedback results from the business processing component.

[0162] The feedback result refers to whether the business operation was successful or failed.

[0163] In S710, if the timed processing process receives a feedback result from the business processing component, it sends the feedback result to the message queue, and the message queue determines that the business event has been executed.

[0164] If the scheduled processing process receives feedback from the business processing component, it indicates that the business event has been executed, thus completing the scheduled processing of the business event.

[0165] S711, if the timed processing process does not receive feedback results from the business processing component, and the message queue does not receive feedback results for the execution timeout business event after a first preset time, it returns a re-execution request to the timed processing process so that the timed processing process executes the second target timeout business event corresponding to the re-execution request.

[0166] If the message queue does not receive feedback results for the execution timeout business event after a first preset timeout period, it determines the timeout business event as the second target timeout business event, generates a repeat execution request based on the target timeout business event, and then returns the repeat execution request to the timed processing process that subscribes to the timeout business event according to the pre-configured return time interval, so that the timed processing process that subscribes to the second target timeout business event repeats the execution of the second target timeout business event.

[0167] It should be noted that the above-mentioned examples of specific implementable methods provided in this application can be arbitrarily combined without conflict to form a new service timing processing method. It should be understood that any new service timing processing method formed by combining any examples should fall within the protection scope of this application.

[0168] Please see Figure 12 , Figure 12 The diagram shows a block diagram of a service timing processing device 800 according to an embodiment of this application. The device 800 includes: a target service request acquisition module 810, a service event storage module 820, and a timeout service event execution module 830.

[0169] The target business request acquisition module 810 is used to acquire the target business request, which includes the business event and the corresponding business processing time.

[0170] The business event storage module 820 is used to store business events in a task partition table based on the business processing time. The task partition table corresponds to the array slot of the business event in the time wheel. The task partition table is pre-configured in the storage component.

[0171] The timeout business event execution module 830 is used to obtain the timeout business event in the task sub-table pointed to by the time wheel pointer and execute the timeout business event.

[0172] As one implementation, the timeout service event execution module 830 is used to: obtain the timeout service event in the task sub-table pointed to by the time wheel pointer based on the successful lock acquisition by the lock acquisition process, and execute the timeout service event, wherein the lock acquisition process corresponds to the timed processing process, and the lock acquisition process is used to acquire the lock from the storage component.

[0173] As one implementation, the timeout service event execution module 830 is used to: obtain the timeout service event in the task sub-table pointed to by the time wheel pointer; send the timeout service event to the message queue for storage; and execute the timeout service event when the timeout service event is received from the message queue.

[0174] In one implementation, the timeout service event execution module 830 is used to: in the event of a lock exception in the storage component, obtain the timeout service event in the task sub-table pointed to by the time wheel pointer; send the timeout service event to the message queue for deduplication processing; and execute the first target timeout service event when the message queue returns the first target timeout service event, wherein the first target timeout service event is the timeout service event after the message queue has deduplicated all the timeout service events sent by the received timed processing processes.

[0175] As one implementation method, please refer to Figure 13 The device 800 further includes a repetitive execution module 840, which is used to execute the second target timeout service event corresponding to the repetitive execution request when a repetitive execution request is received from the message queue, wherein the repetitive execution request is sent by the message queue when no feedback result corresponding to the second target timeout service event is received after a first preset time.

[0176] As one implementation method, please refer to Figure 13 The device 800 further includes: an abnormal business event execution module 850, used to acquire and execute abnormal business events sent by the abnormal inspection process. The abnormal business event is a timeout business event whose event status has not been updated after a second preset time period. The event status is updated after the timeout business event is acquired by the timed processing process and sent to the message queue.

[0177] In one implementation, the storage component also includes a running record table, which records the current running time. The timeout business event execution module 830 is used to: obtain the current running time from the running record table; determine the task sub-table pointed to by the time wheel pointer based on the current running time; and obtain the timeout business event in the task sub-table.

[0178] As one implementation method, the storage component is a distributed storage component that performs consistency verification when multiple timed processing processes store business events.

[0179] As one implementation method, the timeout business event execution module 830 is used to: parse the timeout business event, obtain the callback interface and business parameters corresponding to the timeout business event; and call the callback interface provided by the business processing component to process the business parameters.

[0180] This application provides a business timed processing device that implements business timed processing by directly configuring task partitioning in the storage component and using task partitioning to simulate the array slots of the time wheel. Compared with related technologies that use Crontab components and scripts to implement business timed processing, this eliminates the process of deploying and running scripts, simplifying the implementation of business timed processing. In addition, since task partitioning can be directly configured in the storage component, the process of implementing partitioning through partitioning middleware is reduced, further simplifying the implementation of business timed processing.

[0181] It should be noted that the device embodiments in this application correspond to the aforementioned method embodiments. The specific principles in the device embodiments can be found in the content of the aforementioned method embodiments, and will not be repeated here.

[0182] The following will combine Figure 14 This application describes an electronic device.

[0183] Please see Figure 14 Based on the aforementioned service timing processing method, this application embodiment also provides another electronic device 200 including a processor 104 capable of executing the aforementioned service timing processing method. The electronic device 200 can be a smartphone, tablet computer, computer, in-vehicle device, or portable computer, etc. The electronic device 200 further includes a memory 104, a network module 106, and a screen 108. The memory 104 stores programs capable of executing the content described in the aforementioned embodiments, and the processor 102 can execute the programs stored in the memory 104.

[0184] The processor 102 may include one or more cores for data processing and message matrix units. The processor 102 connects to various parts of the electronic device 200 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by calling data stored in the memory 104. Optionally, the processor 102 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 102 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 102 and may be implemented separately using a communication chip.

[0185] The memory 104 may include random access memory (RAM) or read-only memory (ROM). The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the terminal 100 during use (such as phonebook data, audio and video data, etc.).

[0186] Network module 106 is used to receive and transmit electromagnetic waves, realizing the mutual conversion between electromagnetic waves and electrical signals, thereby communicating with communication networks or other devices, such as audio playback devices. Network module 106 may include various existing circuit elements used to perform these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, user identity module (SIM) cards, memory, etc. Network module 106 can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices via wireless networks. The aforementioned wireless networks may include cellular telephone networks, wireless local area networks (WLANs), or metropolitan area networks (MANs). For example, network module 106 can exchange information with base stations.

[0187] Screen 108 can display interface content and can also be used to respond to touch gestures.

[0188] It should be noted that, in order to achieve more functions, electronic device 200 can also protect more devices, such as structured light sensors used for facial information acquisition or cameras used for iris acquisition.

[0189] Please refer to Figure 15 This diagram illustrates a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. The computer-readable medium 1100 stores program code that can be called by a processor to execute the methods described in the above method embodiments.

[0190] The computer-readable storage medium 1100 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 1100 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 1100 has storage space for program code 1110 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code 1110 may be compressed, for example, in a suitable form.

[0191] Based on the above-described business timing processing method, according to one aspect of the embodiments of this application, a computer program product or computer program is provided. The computer program product or computer program includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described above.

[0192] In summary, the business timed processing method, apparatus, electronic device, storage medium, and computer program product or computer program provided in this application embodiment realizes the business timed processing function by directly configuring task partitioning in the storage component and using task partitioning to simulate the array slots of the time wheel. Compared with the related technology that uses Crontab components and scripts to realize business timed processing function, it eliminates the process of deploying and running scripts, simplifying the process of realizing business timed processing. In addition, since task partitioning can be directly configured in the storage component, the process of implementing partitioning through partitioning middleware is reduced, further simplifying the process of realizing business timed processing.

[0193] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A business timed processing method, characterized in that, The method, applied to a timed processing process, includes: Obtain the target business request, which includes the business event and the corresponding business processing time; Based on the business processing time, the business event is stored in a task sub-table. The task sub-table corresponds to the array slot of the business event in the time wheel. The task sub-table is pre-configured in the storage component. Based on the successful acquisition of the lock by the lock-grabbing process, the timeout business event in the task sub-table pointed to by the pointer of the time wheel is obtained, and the timeout business event is executed. The lock-grabbing process corresponds to the timed processing process, and the lock-grabbing process is used to acquire the lock from the storage component.

2. The method according to claim 1, characterized in that, The method further includes: In the event of a lock exception in the storage component, the timeout service event is retrieved from the task sub-table pointed to by the pointer of the time wheel; The timeout service event is sent to a message queue so that the message queue can perform deduplication processing. Upon receiving the first target timeout service event returned by the message queue, the first target timeout service event is executed. The first target timeout service event is the timeout service event after the message queue has deduplicated the timeout service events sent by all the timed processing processes.

3. The method according to claim 2, characterized in that, The method further includes: Upon receiving a repeat execution request returned by the message queue, the second target timeout service event corresponding to the repeat execution request is executed, wherein the repeat execution request is sent by the message queue when no feedback result corresponding to the second target timeout service event is received for a first preset time.

4. The method according to claim 2, characterized in that, The method further includes: The abnormal service event sent by the abnormal check process is obtained and executed. The abnormal service event is a timeout service event whose event status has not been updated after a second preset time period. The event status is updated after the timeout service event is obtained by the timed processing process and sent to the message queue.

5. The method according to claim 1, characterized in that, The storage component also includes a runtime record table, which records the current runtime. The step of retrieving timeout events from the task sub-table pointed to by the time wheel pointer includes: Obtain the current running time from the running record table; Based on the current running time, determine the task sub-table that the time wheel pointer points to; Retrieve timeout business events from the task sub-table.

6. The method according to claim 1, characterized in that, The storage component is a distributed storage component that performs consistency verification when multiple timed processing processes store business events.

7. The method according to claim 1, characterized in that, The execution of the timeout service event includes: Parse the timeout business event to obtain the callback interface and business parameters corresponding to the timeout business event; The business parameters are processed by calling the callback interface provided by the business processing component.

8. A business timing processing device, characterized in that, Applied to timed processing processes, including: The target business request acquisition module is used to acquire target business requests, which include business events and corresponding business processing times. A business event storage module is used to store the business event in a task sub-table based on the business processing time. The task sub-table corresponds to the array slot of the business event in the time wheel. The task sub-table is pre-configured in the storage component. The timeout service event execution module is used to obtain the timeout service event in the task sub-table pointed to by the pointer of the time wheel based on the successful lock acquisition by the lock acquisition process, and execute the timeout service event. The lock acquisition process corresponds to the timed processing process and is used to acquire the lock from the storage component.

9. The apparatus according to claim 8, characterized in that, The timeout service event execution module is also used for: In the event of a lock exception in the storage component, the timeout service event is retrieved from the task sub-table pointed to by the pointer of the time wheel; The timeout service event is sent to a message queue so that the message queue can perform deduplication processing. Upon receiving the first target timeout service event returned by the message queue, the first target timeout service event is executed. The first target timeout service event is the timeout service event after the message queue has deduplicated the timeout service events sent by all the timed processing processes.

10. The apparatus according to claim 9, characterized in that, The service timing processing device further includes: The repeat execution module is used to execute the second target timeout service event corresponding to the repeat execution request when it receives the repeat execution request returned by the message queue, wherein the repeat execution request is sent by the message queue when it has not received the feedback result corresponding to the second target timeout service event for a first preset time.

11. The apparatus according to claim 9, characterized in that, The service timing processing device further includes: An abnormal business event execution module is used to acquire and execute abnormal business events sent by the abnormal check process. The abnormal business event is a timeout business event whose event status has not been updated after a second preset time period. The event status of the timeout business event is updated after it is acquired by the timed processing process and sent to the message queue.

12. The apparatus according to claim 8, characterized in that, The storage component also includes a runtime record table, which records the current runtime. The timeout service event execution module is further used for: Obtain the current running time from the running record table; Based on the current running time, determine the task sub-table that the time wheel pointer points to; Retrieve timeout business events from the task sub-table.

13. The apparatus according to claim 8, characterized in that, The storage component is a distributed storage component that performs consistency verification when multiple timed processing processes store business events.

14. The apparatus according to claim 8, characterized in that, The timeout business event execution module is further configured to: parse the timeout business event to obtain the callback interface and business parameters corresponding to the timeout business event; The business parameters are processed by calling the callback interface provided by the business processing component.

15. An electronic device, characterized in that, include: One or more processors; Memory; One or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs being configured to perform the method as described in any one of claims 1-7.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1-7.

17. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7.

Images