Digital service platform message retransmission method, equipment and medium

Abstract

The invention discloses a digital service platform message retransmission method and device and a medium, and the method comprises the steps: transmitting a message corresponding to a digital service platform to a receiving end through a message transmitting processor, obtaining a transmitting state corresponding to the message, and updating an error log table corresponding to the message according to the transmitting state; calling an error log query thread, querying an error message log in the error log table, and pushing an error message corresponding to the queried error message log to a delay queue; and calling the service retransmission thread pool, sequentially obtaining the specified error messages to be retransmitted from the delay queue, and retransmitting the specified error messages to the receiving end.

Description

[0001] This application claims priority based on the invention patent application filed with the China National Patent Office on December 29, 2023, with the application number 202311872361.0 and the invention title "A Method, Device, and Medium for Resending Government-Enterprise Portal Service Messages". Technical Field

[0002] This application relates to the technical field of message pushing, and specifically to a method, device, and medium for resending messages on a digital service platform. Background Art

[0003] In a digital service platform, a large amount of data needs to be pushed to the user side every day. This data may include important business information such as orders and transaction records. Digital service platform message pushing is of great significance for timely notification and communication, smooth progress of business processes, improvement of user experience, response to emergencies, and data security and confidentiality, which helps to improve work efficiency, reduce risks, and enhance user satisfaction.

[0004] However, due to reasons such as network jitter or errors in the other party's service interface, the push messages often fail, which may lead to data loss problems, thus affecting the push quality of service information. Therefore, there is an urgent need for an efficient and reliable method for resending messages on a digital service platform to improve the message reliability and stability of the digital service platform and provide a better service experience for users. Summary of the Invention

[0005] To solve the above problems, this application proposes a method for resending messages on a digital service platform, including:

[0006] Sending a message corresponding to the digital service platform to the receiving end through a message sender, and obtaining the sending status corresponding to the message. According to the sending status, updating the error log table corresponding to the message;

[0007] Invoking an error log query thread to query the error message logs in the error log table, and pushing the error messages corresponding to the queried error message logs to a delay queue;

[0008] Invoking a business resending thread pool to sequentially obtain the specified error messages to be resent from the delay queue, and resending the specified error messages to the receiving end.

[0009] In the embodiments of the present application, by updating the error log table to record the messages that failed to be sent and their error message logs, the traceability and recoverability of data are ensured, facilitating subsequent error analysis and troubleshooting. In this way, even if an error occurs during the sending process, the system can accurately record and track the error messages, providing support for subsequent retransmission and processing. When the sending status is "send failed", the system will record the error message in the error log table and push it to the delay queue, and call the business retransmission thread pool to obtain the specified error message to be retransmitted from the delay queue and retransmit it. Such an error handling and retry mechanism can automatically handle the error messages that failed to be sent, effectively solving the problem of data loss caused by failed data push, improving the reliability and stability of the digital service platform service, and increasing the reliability and successful delivery rate of messages. Through the sending message processor, the quality and stability of message sending can be monitored in real time, ensuring the stability and reliability of the message push system of the digital service platform.

[0010] To solve the above problems, the present application proposes a method for retransmitting government-enterprise portal service messages, including:

[0011] Sending the message corresponding to the government-enterprise portal service to the receiving end through the sending message processor, and obtaining the sending status corresponding to the message. According to the sending status, updating the error log table corresponding to the message; wherein, the sending status includes "send successful" and "send failed", and the error log table is composed of error messages with the sending status of "send failed", including the retransmission time, re-push times and error reasons of the error messages;

[0012] Calling the error log query thread to query the error messages in the error log table and pushing the queried error messages to the delay queue;

[0013] Calling the business retransmission thread pool to sequentially obtain the specified error messages to be retransmitted from the delay queue and sending the specified error messages to the kafka message queue;

[0014] Through the sending message processor, listening to the specified error messages re-pushed in the kafka message queue and re-sending the specified error messages to the receiving end.

[0015] In an implementation manner of the present application, updating the error log table corresponding to the message according to the sending status specifically includes:

[0016] For the successful messages with the sending status of "send successful" in the message, generating a send successful event corresponding to the successful messages;

[0017] Push the sending success event to the success event handler, and through the success event handler, obtain the message ID corresponding to the success message, so as to delete the success message log corresponding to the message ID in the error log table according to the message ID.

[0018] In the embodiment of the present application, when the message sending status is sending successfully, through the success event handler, the message ID corresponding to the success message can be obtained. The message ID can be used to locate the success message in the error log table and delete the corresponding success message log in the error log table, so as to realize the cleaning work of the error log table and provide a data basis for the next message retransmission.

[0019] In an implementation manner of the present application, according to the sending status, update the error log table corresponding to the message, specifically including:

[0020] For the error message with the sending status of sending failure in the message, generate a sending re-push event corresponding to the error message;

[0021] Push the sending re-push event to the re-push event handler, and through the re-push event handler, write the error message log corresponding to the error message into the error log table;

[0022] Preferably, writing the error message log corresponding to the error message into the error log table includes:

[0023] Judge whether there is an error message log corresponding to the message ID of the error message in the error log table;

[0024] If it exists, update the error message log corresponding to the error message in the error log table; wherein, the error message log includes the re-push times corresponding to the error message;

[0025] If it does not exist, write the error message log corresponding to the error message into the error log table.

[0026] In the embodiment of the present application, through the re-push event handler, the error message log corresponding to the error message can be written into the error log table. The error log table is used to record the messages with sending failures, including relevant error reasons, re-push times, etc. Writing the error messages into the error log table is helpful for subsequent error handling and retry mechanisms, and is more convenient for tracking error reasons. The re-push event handler can help the system capture the messages with sending failures and perform corresponding processing. Through the error log table, the message information with sending failures can be recorded and basic data can be provided for subsequent error handling and retry mechanisms to ensure the reliability and recoverability of the data.

[0027] In an implementation of the present application, according to the sending status, update the error log table corresponding to the message, specifically including:

[0028] For the error message in the message with the sending status of sending failure, generate a sending re-push event corresponding to the error message;

[0029] Push the sending re-push event to the re-push event processor, and write the error message into the error log table through the re-push event processor.

[0030] In an implementation of the present application, push the queried error message to the delay queue, specifically including:

[0031] Lock the queried error message, and for the error message after successful locking, determine whether the error message has been stored in the delay queue;

[0032] If so, discard the error message;

[0033] If not, determine the current retransmission time of the error message, and push the error message to the delay queue;

[0034] Preferably, the determining the current retransmission time of the error message specifically includes:

[0035] Obtain the current time and the previous retransmission time of the error message;

[0036] Based on the previous retransmission time, the current time and a preset time value, determine the current retransmission time of the error message.

[0037] The embodiment of the present application performs a locking operation on the queried error message, and processes the error message after successful locking to ensure that other operations will not interfere with the processing process of the message during processing. The delay queue can realize the ordered processing and delayed retransmission of messages. By calculating the current retransmission time of the error message, it can ensure that the message can be retransmitted at a certain time interval, realizing the delayed push of the error message, avoiding the situation of continuous retries in case of problems with the other party's interface server, improving the success rate of message sending, and the discard mechanism is used to avoid repeatedly pushing invalid error messages, improving the efficiency and resource utilization rate of the system.

[0038] In an implementation of the present application, push the queried error message to the delay queue, specifically including:

[0039] Lock the queried error message, and for the error message after successful locking, determine whether the error message has been stored in the delay queue;

[0040] If so, discard the error message;

[0041] If not, determine the current retransmission time of the error message and push the error message into the delay queue.

[0042] In an implementation manner of the present application, determining the current retransmission time of the error message specifically includes:

[0043] Obtain the current time and the previous retransmission time of the error message;

[0044] In the case where the previous retransmission time is empty, add the current time and the preset time value to obtain the current retransmission time of the error message;

[0045] In the case where the previous retransmission time is not empty, determine the current retransmission time of the error message based on the previous retransmission time, the current time, and the preset time value;

[0046] Preferably, the determining the current retransmission time of the error message based on the previous retransmission time, the current time, and the preset time value specifically includes:

[0047] Add the previous retransmission time and the preset time value to obtain the candidate retransmission time after addition, and compare the candidate retransmission time with the current time;

[0048] If the candidate retransmission time is less than the current time, use the current time as the current retransmission time of the error message; otherwise, use the candidate retransmission time as the current retransmission time of the error message.

[0049] In the embodiment of the present application, when retransmitting the error message, it can be retransmitted according to a preset time interval, and can be flexibly adjusted according to the previous retransmission time and the current time to avoid the retransmission time being too early or too late, realizing the dynamic adjustment of the retransmission time and improving the retransmission efficiency of the error message. When there is no historical retransmission record, add the current time and the preset time value to obtain the current retransmission time of the error message. This mechanism enables the effective determination of the current retransmission time even in the absence of historical data. For the case where the previous retransmission time is not empty, calculate the current retransmission time of the error message by combining the previous retransmission time, the current time, and the preset time value, taking into account both historical data and real-time time, thus ensuring the accuracy of the retransmission time.

[0050] In an implementation manner of the present application, determining the current retransmission time of the error message specifically includes:

[0051] Obtain the current time and the previous retransmission time of the error message;

[0052] When the previous retransmission time is empty, add the current time and a preset time value to obtain the current retransmission time of the error message;

[0053] When the previous retransmission time is not empty, add the previous retransmission time and the preset time value to obtain a candidate retransmission time after addition, and compare the candidate retransmission time with the current time;

[0054] If the candidate retransmission time is less than the current time, use the current time as the current retransmission time of the error message; otherwise, use the candidate retransmission time as the current retransmission time of the error message.

[0055] The embodiments of the present application can retransmit error messages according to a preset time interval when retransmitting error messages, and can flexibly adjust according to the previous retransmission time and the current time to avoid too early or too late retransmission time, realizing dynamic adjustment of the retransmission time and improving the retransmission efficiency of error messages.

[0056] In an implementation manner of the present application, the re-sending the specified error message to the receiving end includes:

[0057] Send the specified error message to the kafka message queue;

[0058] Through the sending message processor, listen for the specified error message re-pushed in the kafka message queue, and re-send the specified error message to the receiving end.

[0059] The embodiments of the present application can implement an automatic re-push mechanism by listening for error messages in the kafka message queue through a sending message processor, greatly improving the fault tolerance and robustness of the system. At the same time, the kafka message queue realizes decoupling between the sending end and the receiving end, enabling the sending end to immediately send the error message to kafka without waiting for an immediate response from the receiving end, and then continue to process other tasks, improving the overall response speed.

[0060] In an implementation manner of the present application, after calling the business retransmission thread pool to sequentially obtain the specified error messages to be retransmitted from the delay queue, the method further includes:

[0061] Obtain the message identifier of the specified error message, use the message identifier as the lock keyword, and lock the specified error message;

[0062] Preferably, sending the specified error message to the kafka message queue specifically includes:

[0063] Determine whether the specified error message is successfully locked;

[0064] When the locking of the specified error message is successful, determine whether the specified error message exists in the error log table;

[0065] If so, according to the error log table, determine whether the retry count of the specified error message is greater than a preset value. When the retry count is not greater than the preset value, release the lock added to the specified error message, and send the released specified error message to the kafka message queue.

[0066] The embodiment of the present application realizes the locking operation of the specified error message. The purpose is to ensure the uniqueness and exclusivity of the message when processing the specified error message, avoid repeated processing or simultaneous processing of the same error message in a concurrent environment, and thus ensure the correctness and consistency of the error message processing. By using the message identifier as the lock key, it can be ensured that the locking operations between different error messages are independent of each other, avoiding unnecessary concurrent conflicts, and improving the concurrent processing ability and stability of the system. By checking the retry count in the error log table and comparing it with the preset value, the effective control of the retry count of the error message can be realized. When the retry count exceeds the preset value, the message is no longer sent to the Kafka message queue, which can effectively avoid resource waste and potential system problems caused by frequent retries.

[0067] In an implementation manner of the present application, after calling the business resend thread pool to sequentially obtain the specified error messages to be resent from the delay queue, the method further includes:

[0068] Obtain the message identifier of the specified error message, and use the message identifier as the lock key to lock the specified error message.

[0069] The embodiment of the present application realizes the locking operation of the specified error message. The purpose is to ensure the uniqueness and exclusivity of the message when processing the specified error message, avoid repeated processing or simultaneous processing of the same error message in a concurrent environment, and thus ensure the correctness and consistency of the error message processing. By using the message identifier as the lock key, it can be ensured that the locking operations between different error messages are independent of each other, avoiding unnecessary concurrent conflicts, and improving the concurrent processing ability and stability of the system.

[0070] In an implementation manner of the present application, sending the specified error message to the kafka message queue specifically includes:

[0071] Determine whether the locking of the specified error message is successful;

[0072] When the locking of the specified error message is successful, determine whether the specified error message exists in the error log table;

[0073] If so, according to the error log table, determine whether the retry count of the specified error message is greater than a preset value. When the retry count is greater than the preset value, release the lock added to the specified error message and send the released specified error message to the kafka message queue.

[0074] The embodiments of the present application can implement the judgment, processing and management of error messages, ensuring that error messages can be correctly redelivered after reaching a certain number of sending times. At the same time, through the use of the locking mechanism and the message queue, the concurrent processing and reliability of error messages can be guaranteed.

[0075] In an implementation manner of the present application, after determining the current retry time of the error message, the method further includes:

[0076] Create an error message request object, and through the error message request object, update the previous retry time of the error message to the current retry time;

[0077] Alternatively, after determining the current retry time of the error message based on the previous retry time, the current time, and the preset time value, the method further includes:

[0078] When the retry count of the error message is not greater than the preset value, determine the delay time of the error message;

[0079] Based on the delay time and the current retry time, determine a new current retry time, and update the current retry time of the error message based on the new current retry time;

[0080] Preferably, determining the delay time of the error message specifically includes:

[0081] Based on the retry count of the error message, determine the corresponding delay time of the error message; wherein, the delay time is positively correlated with the retry count.

[0082] The embodiments of the present application can record the time point of this message retry, provide a basis for subsequent retry operations, and ensure that error messages can be redelivered according to the preset retry strategy. At the same time, through the use of the error message request object, relevant information can be encapsulated and passed, improving the readability and maintainability of the code. By introducing the delay time and dynamically adjusting it according to the retry count, a more flexible error message retry strategy is realized. This strategy can gradually increase the delay time according to the retry count of the message, thereby avoiding the system pressure that may be brought by frequent retries in a short time.

[0083] An embodiment of the present application provides a message retransmission device for a digital service platform, the device comprising:

[0084] At least one processor;

[0085] And a memory communicatively connected to the at least one processor;

[0086] Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute a message retransmission method for a digital service platform as described above.

[0087] An embodiment of the present application provides a non-volatile computer storage medium storing computer-executable instructions, and when the computer executes the executable instructions, it implements a message retransmission method for a digital service platform as described in any one of the above. BRIEF DESCRIPTION OF THE DRAWINGS

[0088] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments and descriptions thereof of the present application are used to explain the present application, and do not constitute an improper limitation to the present application. In the drawings:

[0089] Figure 1 is a schematic flow chart of a message retransmission method for a digital service platform provided by an embodiment of the present application;

[0090] Figure 2 is a schematic flow chart of a message retransmission method for a government-enterprise portal service provided by an embodiment of the present application;

[0091] Figure 3 is a schematic structural diagram of a message retransmission device for a digital service platform provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0092] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0093] The following will describe in detail the technical solutions provided by each embodiment of the present application in conjunction with the drawings.

[0094] As Figure 1 shown, a message retransmission method for a digital service platform provided by an embodiment of the present application includes:

[0095] S101: Send a message corresponding to the digital service platform to the receiving end through the sending message processor, obtain the sending status corresponding to the message, and update the error log table corresponding to the message according to the sending status.

[0096] The digital service platform is an online platform that integrates various digital services and functions, aiming to provide users with a convenient and personalized service experience, including e-commerce service platforms, financial service platforms, government and enterprise portal service platforms, social media service platforms, etc. Through message push, the digital service platform can effectively provide users with personalized and real-time information, helping users obtain the required content or services more conveniently.

[0097] When the message sent by the digital service platform fails, it is necessary to try to resend it to ensure the timely receipt of the message. For each failed message sending record, the server will record the corresponding error message through the error log table. The error log table consists of error message logs with a sending status of sending failure, including the resending time, number of resends, and error reason of the error message. The error log table records the detailed information of the error messages with sending failures, which enables operation and maintenance personnel or developers to conveniently track and troubleshoot problems. By analyzing the error information in the error log table, the problem can be quickly located and corresponding measures can be taken for repair and handling. During the process of resending the message, the server needs to obtain the sending status corresponding to the message and update the error log table corresponding to the message according to the sending status.

[0098] In one embodiment, for a message with a sending status of sending successfully, it has been successfully resent to the receiving end. At this time, it indicates that this message has been successfully resent. Therefore, the message log corresponding to this message in the error log table needs to be deleted to ensure that only error message logs with sending failures are saved in the error log table. This can improve the resending efficiency of error messages when resending error messages later. The deletion of the successful message log needs to be implemented through the successful event processor. First, the server needs to generate a corresponding sending success event for the successful message with a sending status of sending successfully in the message. The sending success event contains relevant information of the successful message, such as message content, sending time, etc. Then, the generated sending success event is pushed to the successful event processor. The successful event processor is responsible for receiving and processing the successful event. In the successful event processor, the message id of the successful message can be obtained through the successful event. The message id is the unique identifier of the successful message in the error log table and is used to locate and operate on this successful message. Finally, according to the obtained message id, the successful message log corresponding to this message id in the error log table is located and deleted to ensure that only error message logs with sending failures are retained in the error log table.

[0099] In one embodiment, for a message with a sending status of sending failure that still fails to be successfully sent to the receiving end during the current retransmission process, a sending re-push event corresponding to the error message needs to be generated at this time. Then, the sending re-push event is pushed to the re-push event processor. After receiving the sending re-push event, the re-push event processor can perform some processing operations as needed. For example, the error message can be re-sent to the target recipient, etc. In this way, through the re-push event processor, the error message can be written into the error log table.

[0100] Preferably, when writing the error message log corresponding to the error message into the error log table, it is necessary to check whether there is an error message log corresponding to the message ID of this error message in the error log table to avoid duplicate writing of the error message log into the error log table. If there is already a corresponding error message log in the error log table, since the current retransmission time has changed compared with the original error message log in the error log table in terms of the corresponding error sending time and the number of re-pushes, it is necessary to update the error message log corresponding to this error message on the basis of maintaining the original error record. The main content of the update is the number of re-pushes corresponding to the error message. At this time, the error message still fails to be re-pushed. Correspondingly, the number of re-pushes of this error message needs to be incremented by one. By recording the re-push information of the error message, it is more convenient for calculating the subsequent sending delay time.

[0101] In one embodiment, for a message with a sending status of sending failure that still fails to be successfully sent to the receiving end during the current retransmission process, since the current retransmission time has changed compared with the original error record in the error log table in terms of the corresponding error sending time and the number of re-pushes, it is necessary to re-write the error message of the current sending failure into the error log table on the basis of maintaining the original error record to update the error log table.

[0102] If there is no corresponding error message log in the error log table, a new log record will be created for this error message, and the relevant information of this error message will be written into the error log table. In this way, the processing process of each error message can be completely recorded, providing data support for subsequent error troubleshooting and system optimization.

[0103] S102: Call the error log query thread to query the error message logs in the error log table and push the error messages corresponding to the queried error message logs to the delay queue.

[0104] After the error log table is updated, the next round of error message re-push process will begin. First, you need to create an error log query thread to periodically scan the error messages in the error log table. By calling the error log query thread, you can query the error message log in the error log table in pages. After obtaining the error message log, you need to push the queried error message log to the delay queue. The delay queue can implement an automatic retry mechanism. When data push fails, the delay queue can automatically retry according to the preset time interval until it is successfully pushed, which can improve the success rate of data push. The delay queue can be implemented using message middleware such as RabbitMQ or Kafka, or using Redis's sorted set.

[0105] In one embodiment, the embodiment of the present application provides a mechanism for locking an error message to ensure that only one thread can process the error message at the same time. Specifically, a mutex lock can be used to implement the locking mechanism. After the error message is queried through the error log query thread, the error message must first be locked. If the locking is successful, the next step of processing is entered; if the locking fails, it means that other threads are processing the error message, and you can choose to wait for a period of time and try again, or directly skip the processing of the error message. After the locking is successful, for the error message after the locking is successful, it is determined whether the error message has been stored in the delay queue. This process is judged by querying the delay queue or maintaining a set of records that have been stored in the error message. If the error message already exists in the delay queue, it means that the error message has been processed and you can choose to discard the error message. If the error message is not in the delay queue, it is necessary to determine the current retransmission time of the error message, and push the error message to the delay queue, and then through the relevant mechanism of the delay queue, such as the delay function of the message queue or using a scheduled task to trigger the message retransmission, so that the error message can be retransmitted according to the set current retransmission time. After the processing is completed, the lock of the error message needs to be released to allow other threads to process the error message. In a multi-threaded environment, the combination of locking and delay queues can achieve retransmission and delayed processing of error messages.

[0106] Preferably, the retransmission time of the error message needs to be determined based on the actual retransmission situation of the error message. First, the current time and the last retransmission time of the error message are obtained, and then the current retransmission time of the error message is determined based on the last retransmission time, the current time and the preset time value. The preset time value is usually set according to business needs and system performance requirements, and it represents the length of time that should be between two retransmission attempts. Combining the preset time value, the current time and the last retransmission time to determine the current retransmission time helps to implement a reasonable and effective retransmission strategy.

[0107] In one embodiment, the server needs to obtain the current time and the previous retransmission time of the error message. If the previous retransmission time is empty, it means that this error message is being retransmitted for the first time. In this case, the retransmission time needs to be determined based on the current time. The current time and the preset time value are added together to obtain the current retransmission time of the error message. The preset time value can be set according to the actual message processing volume. When the number of error messages is large, the preset time value can be appropriately reduced to improve the retransmission efficiency of the error message. If the previous retransmission time is not empty, it means that this error message has been retransmitted before. In this case, based on the previous retransmission time, the previous retransmission time and the preset time value are added together to obtain the candidate retransmission time after addition. Then, the candidate retransmission time is compared with the current time. If the candidate retransmission time is less than the current time, it means that the retransmission time point has arrived, and the current time needs to be used as the current retransmission time of the error message. Otherwise, the candidate retransmission time is used as the current retransmission time of the error message. Through such processing, it can be ensured that the retransmission time of the error message can be dynamically adjusted according to the actual situation, thereby improving the retransmission efficiency of the error message.

[0108] Among them, the retransmission time of the error message needs to be determined according to the actual retransmission situation of this error message. The server needs to obtain the current time and the previous retransmission time of the error message. If the previous retransmission time is empty, it means that this error message is being retransmitted for the first time. In this case, the retransmission time needs to be determined based on the current time. The current time and the preset time value are added together to obtain the current retransmission time of the error message. The preset time value can be set according to the actual message processing volume. When the number of error messages is large, the preset time value can be appropriately reduced to improve the retransmission efficiency of the error message. If the previous retransmission time is not empty, it means that this error message has been retransmitted before. In this case, based on the previous retransmission time, the previous retransmission time and the preset time value are added together to obtain the candidate retransmission time after addition. Then, the candidate retransmission time is compared with the current time. If the candidate retransmission time is less than the current time, it means that the retransmission time point has arrived, and the current time needs to be used as the current retransmission time of the error message. Otherwise, the candidate retransmission time is used as the current retransmission time of the error message. Through such processing, it can be ensured that the retransmission time of the error message can be dynamically adjusted according to the actual situation, thereby improving the retransmission efficiency of the error message.

[0109] In one embodiment, in the retry process of processing error messages, in addition to considering the current time and the previous retry time to determine the basic retry strategy, the retry strategy is also dynamically adjusted according to the retry count of the error message. This is mainly to avoid frequent and ineffective retry operations by introducing a delay time in the case of increasing retry counts, thereby improving the stability and efficiency of the system.

[0110] Specifically, when the retry count of the error message is not greater than a preset value, the delay time corresponding to the error message is further determined. Based on the delay time and the current retry time, a new current retry time is determined. In this way, the current retry time of the error message can be updated according to the new current retry time, thus realizing the delayed retry of the error message. The delay time is determined according to the retry count of the error message, and there is a positive correlation between the two. That is to say, as the retry count increases, the delay time will also increase accordingly.

[0111] The purpose of determining the delay time is to let the system wait for a period of time before each retry, so as to leave enough time to handle possible problems or wait for the improvement of external conditions such as the network environment. By increasing the delay time, the resource consumption and performance impact caused by consecutive retries can be reduced, and at the same time, it helps to reduce the risk of retry failure caused by network congestion or excessive system load.

[0112] It should be noted that after calculating the current retry time of the error message, the corresponding retry time record needs to be updated. The server creates an error message request object, and through the error message request object, updates the previous retry time of the error message to the current retry time, so as to ensure that the retry time record obtained in the next message retry is the latest, ensuring the accuracy of the retry time.

[0113] S103: Call the business retry thread pool, sequentially obtain the specified error message to be retried from the delay queue, and resend the specified error message to the receiving end.

[0114] The server needs to call the business retry thread pool to handle the error message to be retried. Since the message will be consumed and processed after the delay time arrives, by continuously checking whether the error message in the delay queue needs to be retried, the business retry thread pool can sequentially obtain the specified error message to be retried from the delay queue and send the specified error message to the kafka message queue, thereby realizing the retry of the specified error message.

[0115] In one embodiment, the server creates a global lock object pool for storing all possible message identifiers and their corresponding lock objects. After obtaining the message identifier of a specified error message, the corresponding lock object is retrieved from the lock object pool based on the message identifier, and then the obtained lock object is used to lock the specified error message. By using the message identifier as the lock key, it can be ensured that the processing of the same error message is mutually exclusive, thus avoiding multiple threads from processing the same error message simultaneously and ensuring the orderly processing of error messages. It should be noted that the lock object pool needs to be shared globally to ensure that different threads can obtain the lock object corresponding to the same message identifier.

[0116] Further, after locking the specified error message, the server needs to determine whether the lock is successfully obtained by judging the return value of the locking operation. If the return is successful, it indicates that the specified error message has been successfully locked; otherwise, it needs to wait for a period of time and then retry to obtain the lock. When the specified error message is successfully locked, by querying the error log table, it is judged whether the specified error message exists in the error log table. If it does not exist in the error log table, it means that the current specified error message does not need to be re-pushed, and the lock on the specified error message can be released and the current process can be ended. If it exists in the error log table, according to the error log table, it is judged whether the re-push count of the specified error message is not greater than the preset value. When the re-push count is not greater than the preset value, the specified error message needs to be re-pushed. At this time, the lock added to the specified error message needs to be released, and the released specified error message is re-sent to the receiving end.

[0117] In one embodiment, the server can re-send the specified error message to the receiving end through the Kafka message queue. First, the released specified error message is sent to the Kafka message queue. The server can process the re-pushed specified error message in the Kafka message queue through a sending message processor. After starting the sending message processor in the application, by listening for the specified error message in the Kafka message queue, it is ensured that the sending message processor can respond and process the received message in a timely manner. Furthermore, the sending message processor can use the corresponding sending method to re-send the specified error message to the receiving end according to the received specified error message. After re-sending the specified error message, the sending status of the specified error message can be monitored, such as confirming whether it is successfully sent or whether there is a sending failure, and the error log table can be updated according to the actual sending status to determine whether another round of error message re-sending is still required.

[0118] As Figure 2 shown, a method for re-sending government-enterprise portal service messages provided by an embodiment of the present application includes:

[0119] S201: Send the message corresponding to the government and enterprise portal service to the receiving end through the sending message processor, and obtain the sending status corresponding to the message. Update the error log table corresponding to the message according to the sending status. Among them, the sending status includes successful sending and failed sending. The error log table consists of error messages with a sending status of failed sending, including the resending time, the number of re-pushes, and the error reason of the error message.

[0120] S202: Invoke the error log query thread to query the error messages in the error log table, and push the queried error messages to the delay queue.

[0121] S203: Invoke the service resending thread pool to sequentially obtain the specified error messages to be resent from the delay queue, and send the specified error messages to the kafka message queue.

[0122] S204: Listen for the specified error messages resent in the kafka message queue through the sending message processor, and resend the specified error messages to the receiving end.

[0123] The above is the method embodiment proposed by this application. Based on the same idea, some embodiments of this application also provide the device and non-volatile computer storage medium corresponding to the above method.

[0124] Figure 3 It is a schematic structural diagram of a digital service platform message resending device provided by an embodiment of this application. As Figure 3 shown, it includes:

[0125] At least one processor; and,

[0126] A memory communicatively connected to at least one processor; wherein,

[0127] The memory stores instructions executable by at least one processor. The instructions are executed by at least one processor, enabling at least one processor to:

[0128] Send the message corresponding to the digital service platform to the receiving end through the sending message processor, and obtain the sending status corresponding to the message. Update the error log table corresponding to the message according to the sending status.

[0129] Invoke the error log query thread to query the error message logs in the error log table, and push the error messages corresponding to the queried error message logs to the delay queue.

[0130] Invoke the service resending thread pool to sequentially obtain the specified error messages to be resent from the delay queue, and resend the specified error messages to the receiving end.

[0131] An embodiment of the present application provides a non-volatile computer storage medium storing computer-executable instructions, and when the computer executes the executable instructions, the following operations are implemented:

[0132] Sending a message corresponding to a digital service platform to a receiving end through a message sender, obtaining a sending status corresponding to the message, and updating an error log table corresponding to the message according to the sending status;

[0133] Invoking an error log query thread to query error message logs in the error log table, and pushing error messages corresponding to the queried error message logs into a delay queue;

[0134] Invoking a service retransmission thread pool to sequentially obtain specified error messages to be retransmitted from the delay queue, and retransmitting the specified error messages to the receiving end.

[0135] The embodiments in the present application are all described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for the relevant parts, reference can be made to the partial description of the method embodiments.

[0136] The devices and media provided by the embodiments of the present application correspond one by one to the methods. Therefore, the devices and media also have beneficial technical effects similar to those of the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be elaborated here.

[0137] Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program codes.

[0138] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts 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, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate for implementing the operations in the flow Figure 1one or more processes and / or blocks Figure 1 means for the functions specified in one or more blocks

[0139] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction means that implements the functions in the process Figure 1 one or more processes and / or blocks Figure 1 specified in one or more blocks

[0140] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the functions specified in the process Figure 1 one or more processes and / or blocks Figure 1 steps for the functions specified in one or more blocks

[0141] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory

[0142] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media

[0143] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology for information storage. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves

[0144] It should also be noted that the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or apparatus. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

[0145] The above are only examples of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and changes can be made to the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for resending messages on a digital service platform, characterized in that The method includes: Sending a message corresponding to the digital service platform to the receiving end through a message sender, and obtaining the sending status corresponding to the message. According to the sending status, updating the error log table corresponding to the message; Invoking an error log query thread to query the error message logs in the error log table, and pushing the error messages corresponding to the queried error message logs into a delay queue; Invoking a service retransmission thread pool to sequentially obtain specified error messages to be retransmitted from the delay queue, and re-sending the specified error messages to the receiving end.

2. The method for resending messages on a digital service platform according to claim 1, characterized in that Updating the error log table corresponding to the message according to the sending status, specifically including: Generating a sending success event corresponding to the success message for the success message with the sending status of sending success in the message; Pushing the sending success event to a success event processor, and obtaining the message id corresponding to the success message through the success event processor, so as to delete the success message log corresponding to the message id in the error log table according to the message id.

3. A method for resending messages on a digital service platform according to claim 2, characterized in that, Updating the error log table corresponding to the message according to the sending status, specifically including: Generating a sending re-push event corresponding to the error message for the error message with the sending status of sending failure in the message; Pushing the sending re-push event to a re-push event processor, and writing the error message log corresponding to the error message into the error log table through the re-push event processor; Preferably, writing the error message log corresponding to the error message into the error log table includes: Judging whether there is an error message log corresponding to the message id of the error message in the error log table; If it exists, updating the error message log corresponding to the error message in the error log table; wherein, the error message log includes the re-push times corresponding to the error message; If it does not exist, writing the error message log corresponding to the error message into the error log table.

4. A method for resending messages on a digital service platform according to claim 1, characterized in that, Pushing the queried error message into the delay queue, specifically including: Locking the queried error message, and judging whether the error message has been stored in the delay queue for the error message after successful locking; If so, discarding the error message; If not, determining the current retransmission time of the error message, and pushing the error message into the delay queue; Preferably, determining the current retransmission time of the error message specifically includes: Obtaining the current time and the previous retransmission time of the error message; Determining the current retransmission time of the error message based on the previous retransmission time, the current time, and a preset time value.

5. A method for resending messages on a digital service platform according to claim 4, characterized in that, Determining the current retransmission time of the error message, specifically including: Obtaining the current time and the previous retransmission time of the error message; In the case where the previous retransmission time is empty, adding the current time and the preset time value to obtain the current retransmission time of the error message; In the case where the previous retransmission time is not empty, determining the current retransmission time of the error message based on the previous retransmission time, the current time, and the preset time value; Preferably, determining the current retransmission time of the error message based on the previous retransmission time, the current time, and the preset time value specifically includes: Adding the previous retransmission time and the preset time value to obtain a candidate retransmission time after addition, and comparing the candidate retransmission time with the current time; If the candidate retransmission time is less than the current time, taking the current time as the current retransmission time of the error message; otherwise, taking the candidate retransmission time as the current retransmission time of the error message.

6. A method for resending messages on a digital service platform according to claim 1, characterized in that, The resending the specified error message to the receiving end includes: Sending the specified error message to the kafka message queue; Through the sending message processor, listening for the specified error message re-pushed in the kafka message queue, and resending the specified error message to the receiving end.

7. A method for resending messages on a digital service platform according to claim 6, characterized in that, After calling the business retransmission thread pool to sequentially obtain the specified error messages to be retransmitted from the delay queue, the method further includes: Obtaining the message identifier of the specified error message, using the message identifier as the lock keyword, and locking the specified error message; Preferably, sending the specified error message to the kafka message queue specifically includes: Judging whether the specified error message is successfully locked; When the specified error message is successfully locked, judging whether the specified error message exists in the error log table; If so, according to the error log table, judging whether the retransmission times of the specified error message are greater than a preset value. When the retransmission times are not greater than the preset value, releasing the lock added to the specified error message, and sending the released specified error message to the kafka message queue.

8. A method for resending messages on a digital service platform according to claim 4 or 5, characterized in that After determining the current retransmission time of the error message, the method further includes: Creating an error message request object, and updating the previous retransmission time of the error message to the current retransmission time through the error message request object; Or, after determining the current retransmission time of the error message based on the previous retransmission time, the current time, and the preset time value, the method further includes: When the retransmission times of the error message are not greater than a preset value, determining the delay time of the error message; Based on the delay time and the current retransmission time, determining a new current retransmission time, and updating the current retransmission time of the error message based on the new current retransmission time; Preferably, determining the delay time of the error message specifically includes: Based on the retransmission times of the error message, determining the delay time corresponding to the error message; wherein, the delay time is positively correlated with the retransmission times.

9. A digital service platform message retransmission device, characterized in that, The device includes: At least one processor; And a memory communicatively connected to the at least one processor; Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a method for resending messages of a digital service platform according to any one of claims 1-8.

10. A non-volatile computer storage medium stores computer-executable instructions, characterized in that, When the computer executes the executable instructions, it implements a method for resending messages on a digital service platform as described in any one of claims 1-8.

Images