An online small batch suspicious record processing method and device

Abstract

This application provides an online small-batch suspicious record processing method and apparatus, relating to the field of artificial intelligence and also applicable to the financial field. The method includes: when a preset delay time is reached, querying the transaction processing result corresponding to the suspicious record based on key transaction information recorded in the delay queue; if the transaction processing result is not final and the preset online small-batch processing time has been reached, invoking the corresponding business processing flow according to the business type corresponding to the suspicious record, and obtaining the transaction processing result corresponding to the business processing flow; if the transaction processing result is a failure, invoking the associated business processing cluster to execute a reverse transaction, to ensure consistency in the processing results of each business processing cluster. This application can perform rapid closed-loop processing of suspicious records with high timeliness requirements based on delay queues and online small-batch processing technology, reducing manual intervention.

Description

Technical Field

[0001] This application relates to the field of batch data processing and can be used in the financial field. Specifically, it is a method and apparatus for processing small batches of suspicious records online. Background Technology

[0002] Currently, many business systems are designed and developed based on distributed technologies. However, distributed systems suffer from issues such as service call timeouts and network packet loss, making them prone to generating suspicious records that are not in a final state. These suspicious records can lead to problems such as questionable accounting, orders that have timed out but are still payable, and one-sided outstanding balances. Currently, the industry mainly offers two solutions to address the issue of suspicious records: one is manual intervention, and the other is to use traditional large-scale operations at the end of the day to check for suspicious records.

[0003] For manual intervention to resolve suspicious records, personnel need to perform log analysis, communicate with service providers that did not return correct results, adjust record status, and adjust accounts, which greatly increases the workload of staff and requires accumulated experience to complete. While the traditional end-of-day large-scale catch-all query method can reduce the workload and difficulty for personnel, it has a significant delay. Transactions occurring in the early morning of day T may not be processed until the evening of day T or the early morning of day T+1, which has a significant impact on time-sensitive businesses. Furthermore, large-scale tasks often need to be deployed separately, i.e., run on batch containers. This means that batch tasks need to call the online container's services when processing suspicious records. Once service calls occur, problems such as service call timeouts and network packet loss may occur, and the online container's service call thread pool may be consumed, affecting online business. More importantly, traditional large-scale jobs cannot be executed near the system's end-of-day cutoff time, because the system date changes during the cutoff, which can lead to errors in record processing due to changes in the system date during batch processing. Therefore, large batches of data will be unable to run near the system's end-of-day schedule, resulting in a lack of processing of suspicious records during this period, which affects the timeliness of transactions. Summary of the Invention

[0004] To address the problems in the prior art, this application provides an online small-batch suspicious record processing method and apparatus, which can quickly close the loop for suspicious records with high timeliness requirements based on delayed queues and online small-batch processing technology, reducing manual intervention.

[0005] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0006] Firstly, this application provides a method for processing small batches of suspicious records online, including:

[0007] When the preset delay time is reached, the transaction processing result corresponding to the suspicious record is queried based on the key transaction information recorded in the delay queue; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; there is a business interaction relationship between the first business processing cluster and the second business processing cluster;

[0008] If the transaction processing result is not final and the preset online small batch processing time has been reached, the corresponding business processing flow is invoked according to the business type corresponding to the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained.

[0009] If the transaction processing result is a failure, the associated business processing cluster is invoked to execute the reverse transaction to ensure that the processing results of each business processing cluster are consistent.

[0010] Furthermore, the step of querying the transaction processing result corresponding to the suspicious record based on the key transaction information recorded in the delay queue when the preset delay time is reached includes:

[0011] When the delay time is reached, the key transaction information is retrieved from the delay queue; wherein, the key transaction information includes the transaction number corresponding to the suspicious record;

[0012] The query is executed by calling a thread in the second business processing cluster based on the transaction number, and the transaction processing result is obtained.

[0013] If the transaction processing result is a success, the status of the suspicious record will be updated to success.

[0014] Furthermore, before invoking a thread in the second business processing cluster to execute a query based on the transaction number and obtaining the transaction processing result, the process further includes:

[0015] Determine whether the current status of the queried record is in a final state; wherein, the final state includes a success state and a failure state;

[0016] If the transaction has reached the final state, then the query for the transaction processing result is stopped.

[0017] Furthermore, if the transaction processing result is not final and the preset online small-batch processing time has been reached, the corresponding business processing flow is invoked according to the business type corresponding to the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained, including:

[0018] If the transaction processing result is not final and the preset online small batch processing time has been reached, the suspicious record will be locked.

[0019] If locking is successful, the corresponding business processing flow is invoked according to the business type of the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained;

[0020] If the transaction processing result is successful, the status of the suspicious record is updated to successful and the suspicious record is unlocked.

[0021] Furthermore, after obtaining the transaction processing result corresponding to the business processing flow, the method further includes:

[0022] Determine whether the number of queries initiated corresponding to the suspicious record has exceeded the preset maximum number of initiations;

[0023] If not, update the number of queries initiated and the online batch processing time.

[0024] Furthermore, if the transaction processing result is a failure, the step of invoking the associated business processing cluster to execute a reverse transaction to ensure that the processing results of each business processing cluster are consistent includes:

[0025] If the transaction processing result is a failure, query whether the transaction processing result recorded in the database server corresponding to the associated business processing cluster is a success.

[0026] If so, the associated business processing cluster is invoked to execute the reverse transaction to ensure that the processing results of each business processing cluster are consistent.

[0027] Secondly, this application provides an online small-batch suspicious record processing device, comprising:

[0028] The delay queue query unit is used to query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue when a preset delay time is reached; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; the first business processing cluster and the second business processing cluster have a business interaction relationship;

[0029] The online batch query unit is used to, if the transaction processing result is not final and the preset online batch processing time has been reached, call the corresponding business processing flow according to the business type corresponding to the suspicious record, and obtain the transaction processing result corresponding to the business processing flow.

[0030] The same unit is used to call the associated business processing cluster to execute the reverse transaction if the transaction processing result is a failure, so as to ensure that the processing results of each business processing cluster are consistent.

[0031] Furthermore, the delayed queue query unit includes:

[0032] A key information acquisition module is used to acquire the key transaction information from the delay queue when the delay time is reached; wherein, the key transaction information includes the transaction number corresponding to the suspicious record;

[0033] The processing result query module is used to call a thread in the second business processing cluster to perform a query based on the transaction number and obtain the transaction processing result;

[0034] The first state update module is used to update the state of the suspicious record to success if the transaction processing result is a success state.

[0035] Furthermore, the delayed queue query unit also includes:

[0036] The final state determination module is used to determine whether the current state of the queried record is in the final state; wherein, the final state includes the success state and the failure state;

[0037] The query stop module is used to stop querying the transaction processing result if the final state has been reached.

[0038] Furthermore, the online batch query unit includes:

[0039] The locking processing module is used to lock the suspicious record if the transaction processing result is not final and the preset online small batch processing time has been reached.

[0040] The processing result acquisition module is used to, if the locking is successful, call the corresponding business processing flow according to the business type corresponding to the suspicious record, and obtain the transaction processing result corresponding to the business processing flow;

[0041] The unlocking module is used to update the status of the suspicious record to success and unlock the suspicious record if the transaction processing result is a success state.

[0042] Furthermore, the online batch query unit also includes:

[0043] The query count determination module is used to determine whether the number of queries initiated for the suspicious record has exceeded the preset maximum number of queries;

[0044] The count-time update module is used to update the record of the number of queries initiated and the online small batch processing time, if not.

[0045] Furthermore, the same unit includes:

[0046] The associated status query module is used to query whether the transaction processing result recorded in the database server corresponding to the associated business processing cluster is a success if the transaction processing result is a failure.

[0047] The consistency processing module is used to, if so, call the associated business processing cluster to execute the reverse transaction, so as to ensure that the processing results of each business processing cluster are consistent.

[0048] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the online small-batch suspicious record processing method.

[0049] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the online small-batch suspicious record processing method.

[0050] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the online small-batch suspicious record processing method.

[0051] To address the problems in existing technologies, the online small-batch suspicious record processing method and apparatus provided in this application can store key transaction information in a delayed queue when anomalies such as service call timeout or network packet loss occur. The delay time can be set according to different business needs. At the same time, a small batch task runs in the background of the online container, which starts when the container starts. The task scans the suspicious record table and calls different business methods locally according to different business scenarios to complete the final state closure. Thus, based on the delayed queue and online small-batch processing technology, the suspicious records with high timeliness requirements can be processed quickly and closed in a loop, reducing manual intervention. At the same time, it solves the problems of low scheduling frequency and timeout of service call online containers in traditional large-batch processing, and avoids the problem of the system being unable to execute near the end of the day. Attached Figure Description

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

[0053] Figure 1 This is a flowchart of the online small-batch suspicious record processing method in the embodiments of this application;

[0054] Figure 2 This is one of the flowcharts for delayed queue processing in the embodiments of this application;

[0055] Figure 3This is the second flowchart of the delayed queue processing in the embodiments of this application;

[0056] Figure 4 This is one of the flowcharts for online small-batch processing in the embodiments of this application;

[0057] Figure 5 This is the second flowchart of online small-batch processing in the embodiments of this application;

[0058] Figure 6 This is a flowchart of the same process in the embodiments of this application;

[0059] Figure 7 This is a structural diagram of the online small-batch suspicious record processing device in the embodiments of this application;

[0060] Figure 8 This is one of the structural diagrams of the delayed queue query unit in the embodiments of this application;

[0061] Figure 9 This is the second structural diagram of the delayed queue query unit in the embodiments of this application;

[0062] Figure 10 This is a structural diagram of the online batch query unit in the embodiments of this application;

[0063] Figure 11 This is a structural diagram of the online batch query unit in the embodiments of this application;

[0064] Figure 12 This is a structural diagram of the same unit in the embodiments of this application;

[0065] Figure 13 This is a schematic diagram of the structure of the electronic device in the embodiments of this application;

[0066] Figure 14 This is a schematic diagram of a distributed system service call in an embodiment of this application;

[0067] Figure 15 This is a schematic diagram of container service exception handling in an embodiment of this application;

[0068] Figure 16 This is a flowchart of the delayed queue processing in an embodiment of this application;

[0069] Figure 17 This is a flowchart of the online small-batch processing in the embodiments of this application. Detailed Implementation

[0070] 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 skilled in the art without creative effort are within the scope of protection of this application.

[0071] It should be noted that the online small-batch suspicious record processing method and apparatus provided in this application can be used in the financial field, or in any field other than the financial field. The application field of the online small-batch suspicious record processing method and apparatus provided in this application is not limited.

[0072] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0073] In one embodiment, see Figure 1 In order to enable rapid closed-loop processing of suspicious records with high timeliness requirements based on delayed queues and online small-batch processing technology, and to reduce manual intervention, this application provides an online small-batch suspicious record processing method, including:

[0074] S101: When the preset delay time is reached, query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; there is a business interaction relationship between the first business processing cluster and the second business processing cluster;

[0075] S102: If the transaction processing result is not final and the preset online small-batch processing time has been reached, the corresponding business processing flow is invoked according to the business type corresponding to the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained; wherein, the final state includes the success state and the failure state, and the non-final state means neither a success state nor a failure state. The reason for the transaction processing result being non-final may be that an anomaly occurred during the transaction processing, thereby interrupting the transaction processing process.

[0076] S103: If the transaction processing result is a failure, the associated business processing cluster is invoked to execute a reverse transaction to ensure consistency in the processing results of each business processing cluster. The associated business processing cluster refers to a business processing cluster that has a business relationship with the first business processing cluster; the associated business processing cluster and the first business processing cluster should maintain consistent data records. See also Figure 14In this embodiment, the associated business processing cluster can include only business server group 4 and database server group 7, or it can include both business server group 3 and database server group 6. Preferably, if the transaction processing result is a failure, then both can be called simultaneously. Figure 14 The two business processing clusters on the right (including business server group 4 and database server group 7, and business server group 3 and database server group 6) perform reverse transactions. In a complete business process, a service in the upper right container (business server group 3 and database server group 6) can be executed first, followed by a service in the lower right container (business server group 4 and database server group 7). They are executed sequentially in the execution flow. In a suspicious record scenario, it can be understood that a part of the business has been processed in one business processing cluster, but a delay error occurs when processing another part of the business in another business processing cluster. In this scenario, since it is impossible to know whether the overall business has been successfully processed, this is a suspicious record for the system. Therefore, it is necessary to query the two business processing clusters to check their respective processing results. If the first business processing cluster has successfully processed the business, the remaining steps can continue to be completed according to the subsequent process. If the second business processing cluster fails to process the business, it is necessary to call the first business processing cluster to perform a reverse transaction, that is, cancel the processing and return to the original state before the business processing.

[0077] It is understood that the embodiments of this application are based on a distributed system. Figure 14 The service call relationships of this distributed system are shown. This distributed system includes: a registry center 1, business server groups 2-4, and database server groups 5-7.

[0078] In this context, Registry Center 1 refers to the service registry, which records the mapping relationship between services and service addresses. Common distributed registry centers include Zookeeper, Eureka, Consul, and Nacos, which have functions such as service discovery, service configuration, and service health checks. Registry Center 1 is a highly available registry center cluster deployed across multiple zones, ensuring that if one zone experiences a catastrophic problem, another zone can still operate normally; or, if a single registry center fails, other registry centers can still provide stable functionality, ensuring stable system operation. The execution entity in this embodiment can be a server, and this distributed system has a network connection.

[0079] Business server groups 2-4 refer to server groups within the system that perform business module functions. Each business server group includes three online containers. Containers within the same business server group have the same functionality, while containers in different business server groups have different functionalities. For example, containers in business server group 2 have the same functionality, but the containers in business server group 2 and business server group 3 have different functionalities. Simply put, different business server groups belong to different systems, and service calls between different systems are made via Remote Procedure Call (RPC). Each container is connected to registry center 1, registering and subscribing to services on registry center 1 to complete service calls between containers. Each business server group's containers are connected to a database server group, and different business server groups connect to different database server groups. Each container contains an online mini-batch processor, which starts when the container starts. The mini-batch processing service can be developed based on Spring Task, Quartz, etc., and the scheduling can be controlled by setting the startup frequency, such as starting every minute or starting only after each execution and then waiting one minute.

[0080] Database server groups 5-7 refer to a high-availability database cluster with one primary and three backup servers. Under normal circumstances, each container's read and write operations are performed on the primary database. In case of an anomaly, the system can perform a primary-backup switch, with read and write operations then performed on the backup database. The primary and backup databases synchronize data using a semi-synchronous method to ensure data timeliness and eventual consistency. The database typically uses a relational database to store data, such as MySQL, Oracle, or DB2.

[0081] In summary, this distributed system service call diagram illustrates how a transaction completes calls between different containers and how data persistence is performed within a distributed system. After the caller initiates a business transaction, the transaction proceeds to a container within business server group 1, such as container 1. Depending on the specific business process, container 1 performs different processing steps. For example, container 1 might call a service provided by a container in business server group 2, and then call another service provided by a container in business server group 3. After all business processes are completed, container 1 registers the transaction data in the main database of database server group 5 and then returns the result to the caller. Similarly, for containers in business server groups 2 and 3, after their services are called, they also register their business data in database server groups 6 and 7, respectively.

[0082] Based on the aforementioned distributed system, this invention provides a method for handling suspicious records using a delayed queue and online mini-batch processing. When online transactions encounter problems such as service call timeouts or network packet loss, key information of the current transaction (also known as transaction key information) can be passed into a delayed queue. After the delay time expires, the execution entity in this embodiment retrieves the transaction key information of previous transactions from the delayed queue to judge and query suspicious records, in order to complete the state closure as quickly as possible. If no result is obtained (also known as the final state), subsequent online mini-batch processing will be used to scan suspicious records in the background of the online container and query the results of these records within a certain period of time, in order to make every effort to close the record state.

[0083] By setting up a delayed queue, suspicious records can obtain final results as early as possible, improving the system's real-time processing capabilities. Continuous online small-batch scanning and processing of suspicious records allows for a closed-loop record status management process without manual intervention. This also avoids the problem of traditional batch jobs being paused for a period of time due to cross-day switching. Running small batches on an online container only requires local method calls, reducing the risk of service calls and minimizing the consumption of service thread pools.

[0084] Specifically, when anomalies such as service call timeouts or network packet loss occur during the transaction process, key transaction information is stored in a delayed queue, with delay times set according to different business needs. Simultaneously, a small batch task runs in the background of the online container. This task starts with the container and scans a suspicious table for suspicious records, locally invoking different business methods to complete the final state loop according to different business scenarios. The aforementioned suspicious table can be an existing business table or a specially set suspicious registration table, which registers a record for scanning when an anomaly occurs. Delay queue implementations include DelayQueue, Redis ZSet, Redis expired key callbacks, RabbitMQ, and Kafka. Online small batch implementations include Spring Task and Quartz.

[0085] See Figure 14By setting a delay queue, when the preset delay time is reached, the execution entity of this application embodiment can query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue. The suspicious record is stored in the first business processing cluster (including business server group 2 and database server group 5), and the transaction processing result is stored in the second business processing cluster (including business server group 3 and database server group 6). Since there is a business interaction relationship between the first business processing cluster and the second business processing cluster, the second business processing cluster may have previously executed the transaction corresponding to the suspicious record, thereby generating a transaction processing result in the second business processing cluster. At this time, if the first business processing cluster wants to know the transaction processing result, it needs to send a request to the second business processing cluster to obtain the transaction processing result.

[0086] Next, the execution entity of this application embodiment can determine whether the transaction processing result is a final state (successful state or failure state); if the transaction processing result is not a final state and the preset online small batch processing time has been reached, the corresponding business processing flow is called according to the business type (also known as business scenario) corresponding to the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained.

[0087] If the executing entity in this embodiment determines that the transaction processing result is a failure, it needs to call the associated business processing clusters (which may include, but are not limited to, business server group 4 and database server group 7, business server group 3 and database server group 6) to perform a reverse transaction to ensure that the processing results of each business processing cluster are consistent. This is because a failure state indicates that the transaction execution has failed, and the associated business processing clusters may have recorded an incorrect execution state (such as mistakenly recording a success state). In this case, a reverse transaction needs to be performed to restore the state before the transaction execution.

[0088] As described above, the online small-batch suspicious record processing method and apparatus provided in this application can store key transaction information in a delayed queue when anomalies such as service call timeout or network packet loss occur. The delay time can be set according to different business needs. At the same time, a small batch task runs in the background of the online container, which starts when the container starts. The task scans the suspicious record table and calls different business methods locally according to different business scenarios to complete the final closed loop. Based on the delayed queue and online small-batch processing technology, the suspicious records with high timeliness requirements can be processed quickly and closed loop, reducing manual intervention. At the same time, it solves the problem of low scheduling frequency and timeout of service call online containers in traditional large-batch processing, and avoids the problem of the system being unable to execute near the end of the day.

[0089] The following provides a detailed explanation of steps S101 to S103.

[0090] Step S101: When the preset delay time is reached, query the transaction processing result corresponding to the suspicious record according to the transaction key information recorded in the delay queue; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; there is a business interaction relationship between the first business processing cluster and the second business processing cluster.

[0091] Figure 2 This is a specific embodiment of the online small-batch suspicious record processing method provided in the embodiments of this application.

[0092] In one embodiment, see Figure 2 When the preset delay time is reached, the process of querying the transaction processing result corresponding to the suspicious record based on the key transaction information recorded in the delay queue includes:

[0093] S201: When the delay time is reached, retrieve the key transaction information from the delay queue; wherein, the key transaction information includes the transaction number corresponding to the suspicious record; wherein, the transaction number includes the order number, etc.

[0094] S202: Based on the transaction number, invoke a thread in the second business processing cluster to execute a query and obtain the transaction processing result;

[0095] S203: If the transaction processing result is a success, update the status of the suspicious record to success.

[0096] Furthermore, in one embodiment, see... Figure 3 Before invoking a thread in the second business processing cluster to execute a query based on the transaction number and obtaining the transaction processing result (step S202), the method further includes:

[0097] S301: Determine whether the current status of the queried record is in a final state; wherein, the final state includes a success state and a failure state;

[0098] S302: If the final state has been reached, then stop querying the transaction processing result.

[0099] It is understood that steps S201 to S203 and steps S301 to S302 correspond to the process of querying transaction processing results using a delayed queue.

[0100] Figure 15 This is a diagram illustrating the exception handling of a container service, which includes: thread 11, delayed queue 12, database 13, thread 14, database 15, thread 16, and database 17.

[0101] In this embodiment, thread 11 refers to a thread within a container of business server group 2 (belonging to the first business processing cluster) (as shown in the diagram of container 1). Specifically, it refers to the thread responsible for service call processing, such as the Dubbo thread. Each container has multiple threads responsible for service calls; only one thread is illustrated here. After receiving a service request, thread 11 performs the corresponding business process processing, which requires RPC calls to services provided by containers in business server group 3 (belonging to the second business processing cluster) and business server group 4 (belonging to the associated business processing cluster). When a call timeout occurs, the suggested key information for this transaction, such as the order number, is stored in the delay queue 12 with a certain delay time. Simultaneously, the business data for this transaction is registered in the suspicious table in database 13 and its status is set to suspicious.

[0102] Delayed queue 12 refers to a queue that stores work tasks and retrieves them into the thread pool for execution after a certain delay. A delayed queue can be understood as an ordered heap structure weighted by final execution time, with the earliest executed task as the root node of the heap. Common implementations include DelayQueue, Redis ZSet, Redis expired key callbacks, RabbitMQ, and Kafka.

[0103] Database 13 refers to the primary database in database server group 5 (belonging to the first business processing cluster), which is used to store business data.

[0104] Thread 14 refers to a thread within a container in business server group 3 (belonging to the second business processing cluster) (the thread in container 4 shown in the diagram). Specifically, it refers to the thread responsible for service call processing, such as the Dubbo thread. This thread and thread 11 belong to two different systems and provide different services.

[0105] Database 15 refers to the primary database in database server group 6 (belonging to the second business processing cluster), which is used to store the business data of thread 14.

[0106] Thread 16 refers to a thread within a container in business server group 4 (belonging to the associated business processing cluster) (the thread in container 7 shown in the figure). Specifically, it refers to the thread responsible for service call processing, such as the Dubbo thread. This thread, along with threads 11 and 14, does not belong to the same system and provides different services.

[0107] Here, threads 11 and 16 are connected by a dotted line, specifically indicating that when thread 11 calls the service provided by thread 16, the service call times out and does not return a normal result. However, thread 16 itself is unaware of this; it still completes its task according to its own business process and saves the data to database 17.

[0108] Database 17 refers to the primary database in database server group 7 (which belongs to the related business processing cluster), and it is used to store the business data of thread 16.

[0109] In summary, the container service exception handling diagram illustrates how a service call timeout is handled in a distributed system. After receiving the service request, thread 11 completes its own container's business logic according to the business process. Next, thread 11 initiates an RPC request to thread 14. Upon receiving the request, thread 14 completes its business process within the specified timeout period, registers the data in database 15, and returns the result to thread 11. After receiving the result from thread 14, thread 11 initiates another RPC request to thread 16. Upon receiving the request, thread 16 begins executing its own business process. However, thread 11 does not receive the result from thread 16 within the set timeout period. Therefore, thread 11 registers the key elements of this transaction (key transaction information) in a delayed queue, sets a certain delay time according to its business logic, and registers it as suspicious in the suspicious table of database 13. Thread 16, after completing its own business process, registers the result in database 17. If subsequent queries are initiated in the delayed queue or online in small batches, thread 16 will return the successfully processed result to the caller.

[0110] Figure 16 This is the flowchart for the delayed queue processing, and its steps include S1601 to S1608:

[0111] Step S1601: The first delayed task in the delay queue has reached its time limit. Retrieve the task and begin execution.

[0112] Step S1602: Query the suspicious table based on the key transaction information stored in the task, such as order number, transaction number, event number, etc.

[0113] Step S1603: Determine whether the status of the retrieved record is in the final state; if it is in the final state, it means that the caller has already initiated a query, then proceed to step S1608; otherwise, proceed to step S1604.

[0114] Step S1604: Based on the transaction information stored in the suspicious transaction table, initiate the query process for that transaction. (e.g., call...) Figure 14 The query service provided by the container in business server group 3 or business server group 4 obtains the processing result of the other party's system for this transaction.

[0115] Step S1605: Determine the status of the query result; if the return is successful, it means that the transaction is successful, proceed to step S1606; if the return is unsuccessful, it means that the transaction has clearly failed, proceed to step S1607; for other return conditions, it means that this delayed queue cannot confirm the result (non-final state), and multiple queries need to be initiated to determine the result, proceed to step S1608.

[0116] Step S1606: If the result is confirmed to be successful, update the record status to success and complete the incomplete business process.

[0117] Step S1607: Since the result is confirmed as a failure, update the record status to failure and complete the incomplete business process. Simultaneously, a reverse transaction needs to be invoked for other system services that previously returned success to ensure consistency in processing results across all systems.

[0118] Step S1608: The query for this delayed queue has been completed.

[0119] As can be seen from the above description, the online small-batch suspicious record processing method provided in this application can query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue when the preset delay time is reached.

[0120] In one embodiment, see Figure 4 If the transaction processing result is not final and the preset online small batch processing time has been reached, the corresponding business processing flow is invoked according to the business type corresponding to the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained, including:

[0121] S401: If the transaction processing result is not final and the preset online small batch processing time has been reached, the suspicious record is locked.

[0122] S402: If the locking is successful, the corresponding business processing flow is invoked according to the business type of the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained;

[0123] S403: If the transaction processing result is a success state, update the status of the suspicious record to success and unlock the suspicious record.

[0124] Furthermore, in one embodiment, see... Figure 5 After obtaining the transaction processing result corresponding to the business processing flow (step S402), the method further includes:

[0125] S501: Determine whether the number of queries initiated corresponding to the suspicious record has exceeded the preset maximum number of initiations;

[0126] S502: If not, update the number of queries initiated and the online small batch processing time.

[0127] It is understood that steps S401 to S403 and steps S501 to S502 correspond to the process of querying transaction processing results using a delayed queue.

[0128] Figure 17 This is an online small batch processing flowchart, with steps S1701 to S1716.

[0129] Step S1701: The online small batch setup time on a certain container has expired, the small batch starts, and the total number of initialization records is 0.

[0130] Step S1702: Search the database connected to this container for up to 500 suspicious table records. The query conditions are: the status is not final, the current time is greater than the record's next execution time, and the record's initiation count is less than or equal to the maximum allowed processing count. The maximum allowed processing count is a system parameter that can be adjusted in real time. This parameter ensures that each record is processed only a certain number of times, avoiding endless scanning and reducing resource waste.

[0131] Step S1703: Determine if there are any records in this query; if so, proceed to step S1704, otherwise proceed to step S1716.

[0132] Step S1704: Determine whether all records have been traversed. If they have been traversed, return to step S1702; otherwise, retrieve the next record and proceed to step S1705.

[0133] Step S1705: Attempt to lock the retrieved suspicious record. If the lock is successful, proceed to step S1706; otherwise, return to step S1704. Because there are multiple containers in the same business server group, each running the same batch and connecting to the same database, batches on different containers may scan the same record. To avoid duplicate processing, each record is attempted to be locked. If another batch has already locked it, this record does not need to be processed again. If no lock is acquired, the record is processed by this batch. There are many locking methods, such as based on a registry center, Redis, or a database. For example, when locking based on a registry center, a path can be written to it, where the information is the container's unique sequence number or IP address. Before writing the path, check if the path exists. If it does not exist, it means the record has not been processed and locking can be successful; if it exists, check if the information on the path belongs to this container. If it does, it means the same container is processing it, and processing continues. If it is not the same container, it means the record is already being processed by another batch, and further processing is unnecessary.

[0134] Step S1706: The same table may contain data from different business transactions, and it is necessary to determine whether different businesses follow different business processes.

[0135] Step S1707: Call the local methods of different business processes to initiate corresponding queries for different services.

[0136] Step S1708: Determine the returned query result; if successful, proceed to step S1710; if unsuccessful, proceed to step S1712; if after the above processing, the result is still in another state (not the final state), such as unknown result or no transaction record, proceed to step S1709.

[0137] Step S1709: Determine if the number of queries initiated for this transaction record has exceeded the maximum number of initiations. If so, proceed to step S1712; otherwise, proceed to step S1711. The maximum number of initiations is a system parameter that can be adjusted as needed and takes effect in real time. This parameter ensures that records do not continuously initiate queries; otherwise, the number of such records would increase, affecting the efficiency of small-batch processing and wasting system resources.

[0138] Step S1710: If the result is confirmed to be successful, update the record status to success and complete the incomplete business process.

[0139] Step S1711: Increment the recorded number of initiations by 1 and update the next execution time. The next execution time can be set by adding a fixed amount of time to the current record, such as adding 5 minutes. Alternatively, it can be set to increase the time as the number of initiations increases, such as adding (n-1)×5 or 5^(n-1), where n represents the recorded number of initiations, and n>1.

[0140] Step S1712: Since the result is confirmed to be a failure, update the record status to failure and complete the incomplete business process. Simultaneously, a reverse transaction needs to be invoked for other services that previously returned success to ensure consistency in the processing results across all systems.

[0141] Step S1713: Unlock the record. If it is based on a registry center, the path can be deleted.

[0142] Step S1714: Increment the total number of records by 1.

[0143] Step S1715: Determine if the total number of records processed is greater than the maximum allowed number of records to be processed. If yes, the processing of this small batch is complete, proceed to step S1716; otherwise, return to step S1704. The maximum allowed number of records to be processed is a system parameter that can be adjusted as needed and takes effect in real time. This parameter is used to ensure that each small batch can be completed normally.

[0144] Step S1716: After the small batch execution is completed, exit the task and wait for the next invocation.

[0145] As can be seen from the above description, the online small-batch suspicious record processing method provided in this application can, when the transaction processing result is not final and the preset online small-batch processing time has been reached, call the corresponding business processing flow according to the business type corresponding to the suspicious record, and obtain the transaction processing result corresponding to the business processing flow.

[0146] In one embodiment, see Figure 6 If the transaction processing result is a failure, the associated business processing cluster is invoked to execute a reverse transaction to ensure that the processing results of each business processing cluster are consistent, including:

[0147] S601: If the transaction processing result is a failure, query whether the transaction processing result recorded in the database server corresponding to the associated business processing cluster is a success.

[0148] S602: If so, call the associated business processing cluster to execute the reverse transaction to ensure that the processing results of each business processing cluster are consistent.

[0149] Understandably, step S1607 indicates that if the result is clearly a failure, the record status is updated to failure, completing the incomplete business process. Simultaneously, a reverse transaction needs to be invoked for other system services that have previously returned success to ensure consistency in the processing results across all systems. Specifically, a reverse transaction is an inversion of the original transaction; for example, if the original transaction was a consumption transaction, then the reverse transaction is equivalent to canceling that consumption transaction.

[0150] Similarly, step S1712 above indicates that if the result is clearly a failure, the record status is updated to failure, completing the incomplete business process. Simultaneously, a reverse transaction needs to be invoked for other services that have previously returned success to ensure consistency in the processing results across all systems.

[0151] As can be seen from the above description, the online small-batch suspicious record processing method provided in this application can call the associated business processing cluster to execute the reverse transaction if the transaction processing result is a failure, so as to ensure that the processing results of each business processing cluster are consistent.

[0152] Furthermore, since the aforementioned delayed queue and online batch processing are both deployed on online containers, these can be deployed separately in another container. This container does not provide business services but only handles suspicious records. When a timeout occurs on the business container, the key elements of the record can be pushed to a message queue. Another container subscribes to the contents of this message queue, receives suspicious tasks, and places them in its delayed queue. Simultaneously, a background batch processing instance is deployed on this container to continuously scan suspicious table records and initiate queries against the original online container for the scanned records. This reduces the performance consumption of the original online container, especially when the system crashes and a large number of suspicious records are generated, significantly freeing up the memory and CPU of the online container.

[0153] Based on the same inventive concept, this application also provides an online small-batch suspicious record processing device, which can be used to implement the method described in the above embodiments, as described in the following embodiments. Since the principle of the online small-batch suspicious record processing device in solving the problem is similar to that of the online small-batch suspicious record processing method, the implementation of the online small-batch suspicious record processing device can refer to the implementation of the software performance benchmark determination method, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0154] In one embodiment, see Figure 7 In order to enable rapid closed-loop processing of suspicious records with high timeliness requirements based on delayed queues and online small-batch processing technology, and to reduce manual intervention, this application provides an online small-batch suspicious record processing device, including:

[0155] The delay queue query unit 701 is used to query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue when a preset delay time is reached; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; the first business processing cluster and the second business processing cluster have a business interaction relationship;

[0156] The online batch query unit 702 is used to call the corresponding business processing flow according to the business type corresponding to the suspicious record and obtain the transaction processing result corresponding to the business processing flow if the transaction processing result is not final and the preset online batch processing time has been reached.

[0157] The same unit 703 is used to call the associated business processing cluster to execute the reverse transaction if the transaction processing result is a failure, so as to ensure that the processing results of each business processing cluster are consistent.

[0158] In one embodiment, see Figure 8 The delayed queue query unit 701 includes:

[0159] The key information acquisition module 801 is used to acquire the key transaction information from the delay queue when the delay time is reached; wherein, the key transaction information includes the transaction number corresponding to the suspicious record;

[0160] The processing result query module 802 is used to call a thread in the second business processing cluster to perform a query based on the transaction number and obtain the transaction processing result;

[0161] The first state update module 803 is used to update the state of the suspicious record to success if the transaction processing result is a success state.

[0162] In one embodiment, see Figure 9 The delayed queue query unit 701 further includes:

[0163] The final state determination module 901 is used to determine whether the current state of the queried record is in the final state; wherein, the final state includes the success state and the failure state;

[0164] The query stop module 902 is used to stop querying the transaction processing result if the final state has been reached.

[0165] In one embodiment, see Figure 10 The online batch query unit 702 includes:

[0166] The locking processing module 1001 is used to lock the suspicious record if the transaction processing result is not final and the preset online small batch processing time has been reached.

[0167] The processing result acquisition module 1002 is used to, if the locking is successful, call the corresponding business processing flow according to the business type corresponding to the suspicious record, and obtain the transaction processing result corresponding to the business processing flow;

[0168] The unlocking module 1003 is used to update the status of the suspicious record to success and unlock the suspicious record if the transaction processing result is a success state.

[0169] In one embodiment, see Figure 11 The online batch query unit 702 further includes:

[0170] The query count determination module 1101 is used to determine whether the number of queries initiated corresponding to the suspicious record has exceeded the preset maximum number of queries;

[0171] The count time update module 1102 is used to update the number of queries initiated and the online small batch processing time if no.

[0172] In one embodiment, see Figure 12 The same unit 703 includes:

[0173] The associated status query module 1201 is used to query whether the transaction processing result recorded in the database server corresponding to the associated business processing cluster is a success if the transaction processing result is a failure.

[0174] The consistency processing module 1202 is used to call the associated business processing cluster to perform a reverse transaction if the transaction is true, so as to ensure that the processing results of each business processing cluster are consistent.

[0175] From a hardware perspective, in order to enable rapid closed-loop processing of suspicious records with high timeliness requirements based on delayed queues and online small-batch processing technology, and to reduce manual intervention, this application provides an embodiment of an electronic device for implementing all or part of the online small-batch suspicious record processing method. The electronic device specifically includes the following components:

[0176] The system comprises a processor, a memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to enable information transmission between the online small-batch suspicious record processing device and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the online small-batch suspicious record processing method and the online small-batch suspicious record processing device in the embodiments, the content of which is incorporated herein, and repeated details will not be described again.

[0177] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0178] In practical applications, parts of the online small-batch suspicious record processing method can be executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing capabilities of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0179] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0180] Figure 13 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 13 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 13 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0181] In one embodiment, the online small-batch suspicious record processing method function can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls:

[0182] S101: When the preset delay time is reached, query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; there is a business interaction relationship between the first business processing cluster and the second business processing cluster;

[0183] S102: If the transaction processing result is not final and the preset online small batch processing time has been reached, call the corresponding business processing flow according to the business type corresponding to the suspicious record, and obtain the transaction processing result corresponding to the business processing flow.

[0184] S103: If the transaction processing result is a failure, the associated business processing cluster is invoked to execute the reverse transaction to ensure that the processing results of each business processing cluster are consistent.

[0185] As described above, the online small-batch suspicious record processing method and apparatus provided in this application can store key transaction information in a delayed queue when anomalies such as service call timeout or network packet loss occur. The delay time can be set according to different business needs. At the same time, a small batch task runs in the background of the online container, which starts when the container starts. The task scans the suspicious record table and calls different business methods locally according to different business scenarios to complete the final closed loop. Based on the delayed queue and online small-batch processing technology, the suspicious records with high timeliness requirements can be processed quickly and closed loop, reducing manual intervention. At the same time, it solves the problem of low scheduling frequency and timeout of service call online containers in traditional large-batch processing, and avoids the problem of the system being unable to execute near the end of the day.

[0186] In another embodiment, the online small-batch suspicious record processing device can be configured separately from the central processing unit 9100. For example, the data composite transmission device online small-batch suspicious record processing device can be configured as a chip connected to the central processing unit 9100, and the function of the online small-batch suspicious record processing method can be realized through the control of the central processing unit.

[0187] like Figure 13 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 13 All components shown; in addition, the electronic device 9600 may also include Figure 13 For components not shown, please refer to existing technologies.

[0188] like Figure 13 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0189] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0190] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0191] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0192] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device's communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0193] The communication module 9110 is a transmitter / receiver 9110 that transmits and receives signals via the antenna 9111. The communication module (transmitter / receiver) 9110 is coupled to the central processing unit 9100 to provide input signals and receive output signals, which can be the same as in a conventional mobile communication terminal.

[0194] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is also coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored sound via the speaker 9131.

[0195] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the online small-batch suspicious record processing method with a server or client as the execution subject in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the online small-batch suspicious record processing method with a server or client as the execution subject in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0196] S101: When the preset delay time is reached, query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; there is a business interaction relationship between the first business processing cluster and the second business processing cluster;

[0197] S102: If the transaction processing result is not final and the preset online small batch processing time has been reached, call the corresponding business processing flow according to the business type corresponding to the suspicious record, and obtain the transaction processing result corresponding to the business processing flow.

[0198] S103: If the transaction processing result is a failure, the associated business processing cluster is invoked to execute the reverse transaction to ensure that the processing results of each business processing cluster are consistent.

[0199] As described above, the online small-batch suspicious record processing method and apparatus provided in this application can store key transaction information in a delayed queue when anomalies such as service call timeout or network packet loss occur. The delay time can be set according to different business needs. At the same time, a small batch task runs in the background of the online container, which starts when the container starts. The task scans the suspicious record table and calls different business methods locally according to different business scenarios to complete the final closed loop. Based on the delayed queue and online small-batch processing technology, the suspicious records with high timeliness requirements can be processed quickly and closed loop, reducing manual intervention. At the same time, it solves the problem of low scheduling frequency and timeout of service call online containers in traditional large-batch processing, and avoids the problem of the system being unable to execute near the end of the day.

[0200] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0201] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0202] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0203] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0204] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. An online small-batch suspect record processing method, characterized by, include: When the preset delay time is reached, the transaction processing result corresponding to the suspicious record is queried based on the key transaction information recorded in the delay queue; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; there is a business interaction relationship between the first business processing cluster and the second business processing cluster, and the suspicious record is a record that has a delay error when the same business is divided into two business processing clusters for processing, and it is impossible to determine whether the overall business has been successfully processed; If the transaction processing result is not final and the preset online small-batch processing time has been reached, the corresponding business processing flow is invoked according to the business type corresponding to the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained, including: if the transaction processing result is not final and the preset online small-batch processing time has been reached, locking the suspicious record; if locking is successful, the corresponding business processing flow is invoked according to the business type corresponding to the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained; if the transaction processing result is successful, the status of the suspicious record is updated to successful and the suspicious record is unlocked. If the transaction processing result is a failure, the associated business processing cluster is invoked to execute the reverse transaction to ensure that the processing results of each business processing cluster are consistent.

2. The online small-batch suspicious record processing method according to claim 1, characterized by, When the preset delay time is reached, the process of querying the transaction processing result corresponding to the suspicious record based on the key transaction information recorded in the delay queue includes: When the delay time is reached, the key transaction information is retrieved from the delay queue; wherein, the key transaction information includes the transaction number corresponding to the suspicious record; The query is executed by calling a thread in the second business processing cluster based on the transaction number, and the transaction processing result is obtained. If the transaction processing result is a success, the status of the suspicious record will be updated to success.

3. The online micro-batch suspect record processing method of claim 2, wherein, Before invoking a thread in the second business processing cluster to execute a query based on the transaction number and obtaining the transaction processing result, the process further includes: Determine whether the current status of the queried record is in a final state; wherein, the final state includes a success state and a failure state; If the transaction has reached the final state, then stop querying the transaction processing result.

4. The online micro-batch suspect record processing method of claim 1, wherein, After obtaining the transaction processing result corresponding to the business processing flow, the process further includes: Determine whether the number of queries initiated corresponding to the suspicious record has exceeded the preset maximum number of initiations; If not, update the number of queries initiated and the online batch processing time.

5. The online micro-batch suspect record processing method of claim 1, wherein, If the transaction processing result is a failure, the associated business processing cluster is invoked to execute a reverse transaction to ensure that the processing results of each business processing cluster are consistent, including: If the transaction processing result is a failure, query whether the transaction processing result recorded in the database server corresponding to the associated business processing cluster is a success. If so, the associated business processing cluster is invoked to execute the reverse transaction to ensure that the processing results of each business processing cluster are consistent.

6. An on-line small-lot suspicious record processing apparatus characterized by comprising: include: The delay queue query unit is used to query the transaction processing result corresponding to the suspicious record based on the transaction key information recorded in the delay queue when a preset delay time is reached; wherein, the suspicious record is stored in the first business processing cluster, and the transaction processing result is stored in the second business processing cluster; the first business processing cluster and the second business processing cluster have a business interaction relationship, and the suspicious record is a record that has a delay error when the same business is divided into two business processing clusters for processing, and it is impossible to determine whether the overall business has been successfully processed; The online batch query unit is used to call the corresponding business processing flow according to the business type corresponding to the suspicious record if the transaction processing result is not final and the preset online batch processing time has been reached, and to obtain the transaction processing result corresponding to the business processing flow. The online batch query unit is specifically used to lock the suspicious record if the transaction processing result is not final and the preset online batch processing time has been reached; if the locking is successful, the corresponding business processing flow is invoked according to the business type of the suspicious record, and the transaction processing result corresponding to the business processing flow is obtained; if the transaction processing result is successful, the status of the suspicious record is updated to successful and the suspicious record is unlocked. The same unit is used to call the associated business processing cluster to execute the reverse transaction if the transaction processing result is a failure, so as to ensure that the processing results of each business processing cluster are consistent.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the online small-batch suspicious record processing method according to any one of claims 1 to 5.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the online small-batch suspicious record processing method according to any one of claims 1 to 5.

9. A computer program product comprising computer programs / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the online small-batch suspicious record processing method according to any one of claims 1 to 5.

Images