A message sending method, device and equipment based on a message middleware and a storage medium

Abstract

The application provides a message sending method and device based on a message middleware, equipment and a storage medium, and the method comprises the following steps: performing format verification on a message sending request submitted by a business party; after the message sending request is verified, a message object of the message sending request is serialized and written into a message database table corresponding to the message middleware; target messages are extracted from the message database table by a plurality of preset consumer instances, and the target messages are subjected to business verification; if the business verification is passed, a corresponding downstream channel interface is called according to the message type of the target message to send the message. Through the implementation of the application scheme, the messages are uniformly written into the message middleware database table after the format verification, and the consumer instance is used for separate processing, so that the large batch message sending demand can be easily coped with, and the high-concurrent processing capability of the message sending is improved.

Description

A message sending method, apparatus, device, and storage medium based on message middleware Technical Field

[0001] This application relates to the field of message processing, and in particular to a message sending method, apparatus, device and storage medium based on message middleware. Background Technology

[0002] In today's enterprise application environments, a large amount of user interaction and business processing relies on multi-channel message notifications. For example, e-commerce platforms need to simultaneously push SMS verification codes, coupon emails, and WeChat reminders to millions of users during large-scale promotional events; medical platforms need to send batches of appointment reminders and test result notifications to patients; and financial platforms need to send transaction confirmations or risk warnings to customers through multiple channels. These message sending requirements are often characterized by diverse message types, huge sending volumes, and strict time requirements. However, in existing technical solutions, message sending logic is usually highly coupled with business logic, and the calling interfaces for different channels are scattered in the business code, which easily leads to processing bottlenecks when the system faces large-scale concurrent messages. Summary of the Invention

[0003] This application provides a message sending method, apparatus, device, and storage medium based on message middleware, which is used to solve the performance bottleneck problem that easily occurs when related technologies face the demand for sending large amounts of messages.

[0004] The first aspect of this application provides a message sending method based on message middleware, the message sending method based on message middleware includes:

[0005] Perform format validation on message sending requests submitted by business parties;

[0006] After the message sending request passes the verification, the message object of the message sending request is serialized and written into the message database table corresponding to the message middleware;

[0007] The target message is extracted from the message database table by a number of preset consumer instances, and the target message is then subjected to business verification.

[0008] If the business verification passes, the corresponding downstream channel interface is invoked to send the message according to the message type of the target message.

[0009] Optionally, in the first implementation of the first aspect of this application, the step of performing format validation on the message sending request submitted by the business party includes:

[0010] By parsing each field parameter in the message sending request submitted by the business party, the set of target parameters to be verified is obtained.

[0011] Based on the target parameter set, the required fields are compared for completeness, and a first verification result is generated.

[0012] The second verification result is obtained by comparing the data types of the valid fields in the first verification result;

[0013] Based on the second verification result, a consistency comparison is performed on the logical relationships between the fields to determine the final verification result.

[0014] Optionally, in a second implementation of the first aspect of this application, the step of retrieving the target message from the message database table using a preset number of consumer instances and performing business verification on the target message includes:

[0015] A first verification data set is obtained by retrieving the message identifier of the target message;

[0016] Based on the first verification data set, a comparison is made to determine whether the target message already exists in the historical sending record, and a duplicate verification result is generated.

[0017] Based on the duplicate verification result, the corresponding receiver identifier is extracted from the messages that still need to be processed, and the receiver identifier is compared with the preset limit parameter to obtain the limit verification result.

[0018] Extract the timestamp parameter of the valid message from the limit verification result, and compare it with the difference between the timestamp parameter and the current system time to generate the timeliness verification result;

[0019] Based on the timeliness verification result, determine whether the business verification of the target message passes.

[0020] Optionally, in the third implementation of the first aspect of this application, after the step of calling the corresponding downstream channel interface to send the message according to the message type of the target message if the business verification passes, it further includes:

[0021] The first processing result is obtained by parsing the sending result of the target message;

[0022] Based on the first processing result, the message processing time is statistically analyzed to generate time consumption data;

[0023] The log records are updated based on the time consumption data and the first processing result to obtain the second processing result;

[0024] Extract the message object of the failure message from the second processing result, and obtain the dynamic retry parameter set based on the historical failure records associated with the message object;

[0025] Based on the set of dynamic retry parameters, the preset retry count threshold and retry interval threshold are compared to generate new retry conditions.

[0026] The new retry conditions are used to determine whether the message object should be rewritten into the message database table of the corresponding message middleware.

[0027] Optionally, in the fourth implementation of the first aspect of this application, after the step of calling the corresponding downstream channel interface to send the message according to the message type of the target message if the business verification passes, it further includes:

[0028] Receive the asynchronous push receipt from the downstream channel interface;

[0029] The content of the sent receipt is parsed to extract the target message identifier and the corresponding status parameters;

[0030] The corresponding receipt result is generated by comparing the state parameters with the preset state mapping relationship.

[0031] Locate the log record of the target message in the log storage based on the target message identifier, and update the log record based on the receipt result.

[0032] Optionally, in the fifth implementation of the first aspect of this application, before the step of parsing the receipt content of the sent receipt and extracting the target message identifier and the corresponding status parameter, the method further includes:

[0033] A unique identifier is assigned to the target message during the generation phase to obtain the target message identifier, and the target message identifier is bound to the original request parameters of the target message to generate an initial tracking record;

[0034] Based on the target message identifier, the corresponding processing events of the target message in the message middleware and the consumer instance are collected to generate intermediate tracking records;

[0035] The initial and intermediate tracking records associated with the target message identifier are aggregated to generate a tracking dataset, which is then merged and written into the log storage.

[0036] Optionally, in a sixth implementation of the first aspect of this application, the method further includes:

[0037] Real-time performance monitoring metrics are constructed based on the aforementioned tracking data set;

[0038] The real-time performance monitoring indicators are dynamically analyzed to generate performance evaluation results;

[0039] If the performance evaluation results indicate that the message throughput is lower than a preset threshold and the failure rate is higher than a preset threshold, then a joint optimization of consumer instance concurrency expansion and retry parameter reduction is triggered.

[0040] If the performance evaluation results indicate that the message throughput is higher than the preset threshold and the retry success rate is stable, then a joint optimization of consumer instance concurrency reduction and quota parameter increase is triggered.

[0041] A second aspect of this application provides a message sending apparatus based on a message middleware, the message sending apparatus based on a message middleware being used to implement a message sending method based on a message middleware. The message sending apparatus based on a message middleware includes:

[0042] The first verification module is used to verify the format of message sending requests submitted by the business party.

[0043] The writing module is used to serialize the message object of the message sending request and write it into the message database table corresponding to the message middleware after the message sending request is verified.

[0044] The second verification module is used to extract target messages from the message database table through a preset number of consumer instances and perform business verification on the target messages.

[0045] The sending module is used to call the corresponding downstream channel interface to send the message according to the message type of the target message if the service verification passes.

[0046] A third aspect of this application provides an electronic device, including a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory, and when the processor executes the computer program, it implements the steps of the message sending method based on message middleware provided in the first aspect of this application.

[0047] The fourth aspect of this application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the message sending method based on message middleware provided in the first aspect of this application.

[0048] In summary, the message sending method, apparatus, device, and storage medium based on message middleware provided in this application performs format verification on message sending requests submitted by the business party. After the message sending request passes verification, the message object of the message sending request is serialized and written into the message database table corresponding to the message middleware. Target messages are extracted from the message database table using several preset consumer instances, and the target messages undergo business verification. If the business verification passes, the corresponding downstream channel interface is called to send the message according to the message type of the target message. Through the implementation of this application, messages are uniformly written into the message middleware database table after format verification, and the large-volume message sending requirements are easily handled by separating processing using consumer instances, thereby improving the high-concurrency processing capability of message sending. Attached Figure Description

[0049] Figure 1 is a flowchart illustrating the message sending method based on message middleware provided in an embodiment of this application;

[0050] Figure 2 is a schematic diagram of the program modules of the message sending device based on message middleware provided in an embodiment of this application;

[0051] Figure 3 is a schematic diagram of the structure of the electronic device provided in the embodiment of this application. Detailed Implementation

[0052] To make the inventive objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. 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.

[0053] To address the performance bottleneck issue that related technologies often encounter when facing large-volume message sending demands, this application provides a message sending method based on a message middleware. Figure 1 is a flowchart illustrating the message sending method based on a message middleware provided in this embodiment. The message sending method based on a message middleware includes the following steps:

[0054] Step 110: Validate the format of the message sending request submitted by the business party.

[0055] Specifically, the technical solution used for format validation of message sending requests submitted by business users is based on a parameter parsing and rule comparison mechanism. Requests submitted by business users typically include multiple parameters such as target user identifier, message type, message content, and sending time. The parsing module reads each field in the request item by item, forming a set of parameters to be validated. Then, according to a preset rule base, the required fields in the parameter set are checked for completeness, the data format is checked for consistency, and numeric, string, or timestamp fields are compared to ensure consistency with system standards. When the validation results indicate that the input data is missing, incorrect, or does not conform to the specifications, the request will be blocked from entering subsequent processing stages, thus ensuring that all data entering the message middleware are message objects with valid structure and content.

[0056] In one optional implementation of this embodiment, the step of performing format validation on the message sending request submitted by the business party includes: parsing each field parameter in the message sending request submitted by the business party to obtain a set of target parameters to be validated; performing an integrity comparison on the required fields according to the target parameter set to generate a first validation result; performing a data type comparison on the legal fields in the first validation result to obtain a second validation result; and performing a consistency comparison on the logical relationships between the fields according to the second validation result to determine the final validation result.

[0057] In this embodiment, in the message sending method based on message middleware, parsing the message sending request submitted by the business party item by item is the core step in ensuring the legality and integrity of the message. The message sending request contains multiple field parameters, each carrying specific information such as the recipient identifier, message content, message type, and sending timestamp. Item-by-item parsing refers to extracting each field in the message request sequentially and mapping it to a predefined parameter model of the system to form a target parameter set to be verified. The generation of the target parameter set includes not only the extraction of field names and values ​​but also the identification of field attributes, such as whether a field is required, the allowed value range, and length constraints. This provides an accurate basis for integrity comparison. Integrity comparison involves checking the submitted message request based on the required attributes of each field in the target parameter set. It confirms that all required fields have provided valid values. For missing or empty required fields, a verification error is generated, forming the first verification result. The first verification result not only identifies which fields passed the integrity check but also records the fields that failed and their reasons, thus providing basic data for subsequent data type verification. Data type comparison compares the values ​​of valid fields in the first verification result with the defined types of the fields. For example, it checks whether numeric fields are integers or floating-point numbers, whether date fields conform to the expected time format, and whether string fields meet length and character set requirements. This data type comparison yields a second verification result, indicating the validity status of each field and specific error information. Logical relationship consistency comparison further verifies the fields that passed data type verification in the second result against business rules. For example, the sending time must be later than the current system time, the message type and message content format should match, and the receiver identifier and limit parameters must meet preset constraints. This comparison determines whether there are logical conflicts or unreasonable situations between fields, ultimately generating a final verification result that clarifies whether the message request can enter the message middleware for serialization and writing. For instance, if the message type is "SMS," the message content field should be in text format and its length should not exceed the limit, and the sending time must be after the current system time. If any of these conditions are not met, the logical consistency check fails, and the message is rejected from downstream processing. The entire process involves step-by-step verification, applying rules for field integrity, data type, and business logic in sequence to ensure that messages conform to the agreed-upon specifications between the business party and the system before entering the message middleware, thus achieving reliable and accurate message sending.

[0058] Step 120: After the message sending request passes the verification, serialize the message object of the message sending request and write it into the message database table corresponding to the message middleware.

[0059] Specifically, after the message sending request passes verification, the message object needs to be serialized and written to the corresponding message database table of the message middleware. According to the object serialization protocol, the parameter information in the message object is converted into transmittable binary data or structured strings to ensure data consistency across processes and nodes. The serialized message is assigned to a specific topic or partition in the message middleware (such as Kafka) based on its type, and then written to the corresponding database table. Through persistent storage and a distributed architecture, the message middleware can guarantee the sequential writing and reliable preservation of message data. Even in the event of system failure or node downtime, messages can be recovered using the middleware's own replication mechanism.

[0060] Step 130: Extract the target message from the message database table using a number of preset consumer instances, and perform business verification on the target message.

[0061] Specifically, after the message object is written to the message middleware, several pre-defined consumer instances are scheduled to retrieve the target message from the message database table and perform business validation on it. During this process, the message middleware allocates messages from different partitions to different consumer instances according to the consumer group's partitioning strategy to support parallel consumption. After retrieving the target message, each consumer instance performs business validation to determine if the target message is still valid.

[0062] In one optional implementation of this embodiment, the steps of extracting target messages from a message database table using a preset number of consumer instances and performing business verification on the target messages include: retrieving the message identifier of the target message to obtain a first verification data set; comparing whether the target message already exists in historical sending records based on the first verification data set to generate a duplicate verification result; extracting the corresponding receiver identifier for messages that still need to be processed based on the duplicate verification result, and comparing the receiver identifier with a preset limit parameter to obtain a limit verification result; extracting the timestamp parameter of valid messages in the limit verification result, and comparing the difference between the timestamp parameter and the current system time to generate a timeliness verification result; and determining whether the business verification of the target message passes based on the timeliness verification result.

[0063] In this embodiment, the message sending method based on message middleware relies on the retrieval of message identifiers for business verification of target messages. Each target message is assigned a unique identifier during the generation stage. This identifier serves as a unique index for the message in the system, used for quick location and matching in the message database table and historical records. By retrieving the message identifier of the target message, a data set related to the message can be obtained from the historical sending records stored in the system. This data set includes the message's sending status, receiver information, sending time, and failure reason during past processing, thus forming a first verification data set. This data set can be used to compare whether the target message already exists in the historical sending records, i.e., to perform duplicate verification. Duplicate verification determines whether the target message identifier matches the message identifier that has been processed or is currently being processed in the historical records, thereby generating a duplicate verification result. This result indicates whether the message is being sent for the first time or is being sent repeatedly. Duplicate messages can be directly intercepted or marked for special processing. For messages that still need processing, the recipient identifier can be extracted from the repeated verification results. Each recipient may have preset quota parameters configured in the system to limit the number of messages that can be received per unit of time. Quota parameters may include daily limits, hourly limits, or maximum reception volume for a specific time period. By comparing the recipient identifier with the quota parameters, the quota verification result can be obtained. This result shows whether each message meets the recipient's sending limit. If the limit is exceeded, the sending is postponed or rejected. Furthermore, for messages that are still determined to be valid in the quota verification results, the message's timestamp parameter needs to be extracted. The timestamp records the specific time the message was generated or entered into the database. By comparing the difference between this timestamp and the current system time, a timeliness verification result can be generated. This result is used to determine whether the message has expired. For example, if the message has been delayed for too long, its sending meaning may have become invalid, and therefore it will no longer be sent. Ultimately, based on the timeliness verification results, a comprehensive judgment can be made as to whether the target message passes the business verification. If the message meets the conditions in duplicate verification, quota verification, and timeliness verification, it is considered valid and can be sent through the downstream channel interface. Otherwise, it will be marked as failing and the corresponding reason will be recorded. For example, if the message corresponding to the target message identifier does not appear in the historical record, the recipient's daily sending volume does not exceed the upper limit, and the message generation time is less than the maximum allowed delay threshold, then the business verification passes, and the system will continue with subsequent sending processing. If any condition is not met, the message will be blocked from entering the sending queue, thereby ensuring the accuracy, compliance, and overall controllability of message sending.

[0064] Step 140: If the business verification passes, the corresponding downstream channel interface is called to send the message according to the message type of the target message.

[0065] Specifically, after the target message passes business verification, the system will call the corresponding downstream channel interface to send the message based on its message type. The system automatically matches the appropriate downstream interface based on the type field in the target message. For example, when the message type is SMS, the system will call the API interface provided by the SMS gateway; when the message type is email, the system will construct an SMTP protocol message and send it to the mail server; when the message type is WeChat notification, the system will call the interface of the WeChat Open Platform; and when the message type is smart message, the system will call the dedicated interface of the smart push platform.

[0066] In an optional implementation of this embodiment, after the step of calling the corresponding downstream channel interface to send the message according to the message type of the target message if the business verification passes, the method further includes: parsing the sending result of the target message to obtain a first processing result; statistically analyzing the message processing time based on the first processing result to generate time consumption data; updating the log records based on the time consumption data and the first processing result to obtain a second processing result; extracting the message object of the failed message in the second processing result, and obtaining a dynamic retry parameter set based on the historical failure records associated with the message object; comparing the preset retry count threshold and retry interval threshold based on the dynamic retry parameter set to generate new retry conditions; and determining whether to rewrite the message object into the message database table of the corresponding message middleware based on the new retry conditions.

[0067] In this embodiment, each target message returns a processing result after being sent through the downstream channel interface. The processing result includes information such as whether the message was sent successfully, the reason for failure, the sending time, and the message identifier. By parsing the sending result, a first processing result can be extracted. This first processing result records the message's sending status and related parameters, providing basic data for statistics and log updates. Processing time statistics for the first processing result are obtained by calculating the time difference between the message entering the sending queue and receiving a sending confirmation. This time data reflects the performance of message flow and processing in the system, which is crucial for monitoring system throughput and identifying potential bottlenecks. Then, by combining the time data with the first processing result to update the log records, a second processing result can be generated. The second processing result not only records the sending status of each message but also includes information such as the time consumption, the reason for failure, and the processing time, thereby achieving comprehensive recording and tracking of message processing. For failed messages in the second processing result, the message object needs to be further extracted. The message object contains core data such as message content, recipient information, sending timestamp, and a unique identifier. Through this message object, its associated historical failure records can be queried. These historical failure records document the number of failures, reasons for failure, and processing time of the message during previous processing. Analyzing these historical failure records generates a dynamic retry parameter set. This set defines the maximum number of retries, the retry interval, and possible adjustment strategies for the current message, allowing the system to flexibly adjust its retry strategy based on actual conditions—determining whether to continue retrying and when to retry. Subsequently, the dynamic retry parameter set is compared with preset retry thresholds and retry interval thresholds to generate new retry conditions. These new conditions determine whether the message still has a chance to be sent again and the specific time interval for the next retry. The new retry conditions determine whether the failed message should be rewritten into the message database table of the message middleware. If the retry conditions are met, the message object is rewritten into the message queue and awaits processing by the next consumer instance. This achieves an automated retry mechanism for failed messages, improving message delivery rate and system reliability. For example, if a text message fails to be sent on its first attempt due to network fluctuations, the time taken to send it is recorded as processing time. The system calculates the next retry interval as five minutes based on the historical number of failures and dynamic retry parameters, and if the number of retries does not exceed the upper limit, the message will be rewritten into the message middleware table to await the next round of sending processing. If the number of retries has reached the threshold or the reason for failure is unrecoverable, the system will terminate the retry of the message and record the failure information and final status in the log, thereby achieving precise monitoring and dynamic management of the entire message sending process.

[0068] In one optional implementation of this embodiment, if the business verification passes, after the step of calling the corresponding downstream channel interface to send the message according to the message type of the target message, the method further includes: receiving a sending receipt asynchronously pushed by the downstream channel interface; parsing the receipt content to extract the target message identifier and the corresponding status parameters; comparing the status parameters with a preset status mapping relationship to generate a corresponding receipt result; locating the log record of the target message in the log storage according to the target message identifier, and updating the log record according to the receipt result.

[0069] In this embodiment, receiving the asynchronous push receipt from the downstream channel interface is a crucial step in ensuring the traceability of message sending status. The downstream channel interface refers to the interface provided by the message sending system to send messages to the target terminal or system and return the processing result. The send receipt is pushed asynchronously, meaning that the downstream channel actively returns the sending result to the message system after processing the message, rather than the message system actively polling. This asynchronous mode reduces system waiting and blocking, improves overall throughput, and ensures the real-time nature of the sending status. Parsing the received send receipt requires structured processing of the receipt content. The receipt content includes information such as the target message identifier, sending status, error code or success code, and sending time. Through parsing, the target message identifier and corresponding status parameters can be extracted. The target message identifier is used to uniquely locate the message in the system, while the status parameters reflect the result of message sending, such as success, failure, delay, or exception. After extracting the status parameters, they need to be compared with a preset status mapping relationship. The status mapping relationship defines the correspondence between the original status codes returned by downstream channels and the standard statuses within the system. By comparing them, the statuses of different downstream channels can be uniformly mapped to identifiable receipt results within the system, thus forming standardized receipt records. By locating the corresponding log record in the log storage using the target message identifier, the historical information of the message stored in the system can be accurately found, including message content, sending time, number of sending attempts, historical failure records, and time consumption data. Then, the generated receipt results are used to update the log records, writing the receipt results into the status field of the log, and updating information such as the number of sending attempts, processing time, and failure reasons as needed, to achieve a complete record of the message lifecycle. For example, if an SMS message is sent via a downstream interface and the receipt status is "DELIVERED", the target message identifier and status parameters are extracted after parsing the receipt. The status mapping relationship maps "DELIVERED" to "sent successfully" within the system. After locating the log record through the target message identifier, the status in the log is updated to "sent successfully", and the sending time and time consumption are recorded. If the receipt status is "FAILED", it is mapped to "sent failed", and the error code and failure reason are recorded, providing a basis for subsequent dynamic retry or alarm. The entire process, through asynchronous receipt reception, parsing, status mapping, and log updating, achieves real-time synchronization and consistency management between the downstream channel sending results and the system's internal logs, making the message sending status traceable and statistically verifiable, and providing accurate data support for subsequent message retries and performance analysis.

[0070] In an optional implementation of this embodiment, before parsing the receipt content of the sent receipt and extracting the target message identifier and corresponding status parameters, the method further includes: assigning a unique identifier to the target message during the generation stage, obtaining the target message identifier, and binding the target message identifier with the original request parameters of the target message to generate an initial tracking record; collecting the corresponding processing events of the target message in the message middleware and consumer instance according to the target message identifier to generate an intermediate tracking record; and aggregating the initial tracking record and intermediate tracking record associated with the target message identifier to generate a tracking dataset, which is then merged and written into the log storage.

[0071] In this embodiment, the implementation of full-process tracking of target messages relies on assigning a unique identifier during the message generation stage. Each target message is assigned a globally unique identifier by the system upon generation. This identifier is used to uniquely identify the message in the message middleware, consumer instance, and log storage, ensuring accurate association with all subsequent processing events. The target message identifier not only serves as an index but also needs to be bound to the original request parameters of the target message. The original request parameters include information such as message content, recipient identifier, message type, and sending timestamp. This binding generates an initial tracking record, which records the initial state of message generation and related metadata, providing starting point information for message flow and enabling the system to trace the message source and original request. Subsequently, during the process of a message entering the message middleware and being processed by the consumer instance, each target message triggers various processing events, including enqueue, dequeue, serialization writing, business verification, sending invocation, and asynchronous receipt processing. These processing events are collected using the target message identifier to generate intermediate trace records. These records document the message's processing status, timestamps, and potential anomalies at each stage, providing data support for analyzing message processing flows, diagnosing problems, and evaluating system performance. For example, when an SMS message is retrieved from the consumer instance for business verification, the processing event records the message's verification status and time; this information constitutes part of the intermediate trace record. Next, the initial trace record and the intermediate trace record need to be aggregated. Aggregation refers to integrating the initial state of the message generation stage with various event information from the intermediate processing stage based on the target message identifier, forming a complete trace dataset. This dataset contains information about the entire message lifecycle from generation, storage, consumption, and sending to receiving receipts, and can display the time consumption, status changes, and anomalies at each stage, thereby achieving comprehensive monitoring and traceability of the message lifecycle. Finally, the aggregated tracking data set is written to the log storage. The log storage, acting as a persistent database or log system, not only preserves the message processing history but also provides a basis for statistical analysis, performance evaluation, troubleshooting, and retry strategies. For example, an SMS message is assigned the identifier MSG20250910001 during the generation phase and bound to the original request parameters to form an initial tracking record. When this message is retrieved by a consumer instance for limit verification and business verification, the generated intermediate tracking record records the verification status and time. This intermediate record is then aggregated with the initial tracking record to form a complete tracking dataset, which is then written to the log storage. This allows for real-time querying of the entire processing of MSG20250910001, making every step from message generation to successful or failed delivery clearly visible, ensuring the transparency and controllability of the messaging system.

[0072] In one optional implementation of this embodiment, real-time performance monitoring metrics are constructed based on the tracking data set; the real-time performance monitoring metrics are dynamically analyzed to generate performance evaluation results; if the performance evaluation results indicate that the message throughput is lower than a preset threshold and the failure rate is higher than a preset threshold, then a joint optimization of consumer instance concurrency expansion and retry parameter reduction is triggered; if the performance evaluation results indicate that the message throughput is higher than a preset threshold and the retry success rate is stable, then a joint optimization of consumer instance concurrency contraction and quota parameter increase is triggered.

[0073] In this embodiment, the introduction of real-time performance monitoring and adaptive optimization mechanisms in the message sending method based on message middleware can effectively improve the system's processing capability and stability in dynamic environments. The prerequisite for implementing this mechanism is the deep utilization of the tracking dataset, which completely records the entire process of a target message from generation to receipt, including parameters such as time consumption, status, failure records, and retry status. Based on the tracking dataset, real-time performance monitoring metrics can be constructed. These metrics are a set of dynamic statistics used to characterize the system's performance over a period of time. Their core components include message throughput, average processing time, failure rate, and retry success rate. Message throughput refers to the number of messages successfully processed by the system per unit time, directly reflecting the system's processing capacity; average processing time is the average time from message entry to final receipt, reflecting processing efficiency; failure rate represents the proportion of failed messages to the total number of processed messages within a certain time window, measuring system reliability; and retry success rate refers to the proportion of messages that have changed from failure to success after a retry strategy, reflecting the effectiveness of the retry mechanism. Once performance monitoring metrics are established, they need to be dynamically analyzed. Dynamic analysis refers to continuous calculation and trend identification of real-time collected data. By comparing threshold ranges and historical change curves, performance evaluation results are generated, which are a quantitative description of the system's health status. If the analysis results show that message throughput is lower than the preset threshold while the failure rate is higher, it indicates that the system has insufficient message processing speed and many failures. This state will lead to backlog and a degraded user experience, thus requiring joint optimization. The first part of joint optimization is consumer instance concurrency expansion, which dynamically increases the number of concurrent instances processing messages, thereby increasing computing resources and processing threads to improve overall throughput. The second part is retry parameter reduction. Retry parameters include the number of retries and the retry interval. Reducing these parameters means reducing unnecessary duplicate requests and shortening the interval, thereby reducing resource waste and quickly determining whether messages are unrecoverable when the system is under heavy pressure. Conversely, if performance evaluation results show that message throughput exceeds the preset threshold and retry success rate remains stable, it indicates that the system's processing capacity is sufficient or even redundant, and the retry strategy also shows a high success rate. In this case, continuing to maintain high concurrency and strict quota policies will lead to a decrease in resource utilization, thus requiring the triggering of another joint optimization. The first part of this operation is consumer instance concurrency reduction, that is, reducing the number of concurrent instances while ensuring that processing performance is not affected, releasing excess computing resources to reduce system costs; the second part is quota parameter increase. The quota parameter defines the number of messages that the receiver can accept within a certain period of time. Increasing the quota parameter means appropriately relaxing the limit when the system capacity is sufficient, allowing more legitimate requests to be processed quickly, thereby improving overall throughput and improving user experience.For example, if the system detects that the throughput in the past minute is only 200 messages / second, far below the threshold of 500 messages / second, and the failure rate reaches 8%, exceeding the threshold of 5%, then an expansion operation is immediately triggered to increase the number of consumer instances and lower the retry parameters to alleviate the bottleneck. In another scenario, when the throughput reaches 800 messages / second and the retry success rate remains above 95%, it indicates that the system has significant capacity. At this point, a contraction operation is triggered to reduce resource consumption and increase the quota parameters, allowing more requests to successfully enter the system. Through this real-time monitoring and dynamic adjustment based on tracking data sets, the system can maintain stability and efficiency under different load environments, achieving a dynamic balance between message processing performance and resource utilization.

[0074] Optionally, historical processing samples are constructed based on the tracking data set and sending receipts, and a prediction model is trained using these historical processing samples. The prediction model is then used to predict the message throughput trend, failure rate trend, and retry success rate trend within a future preset time window, generating predictive performance results. If the predictive performance results indicate that the message throughput will be lower than the threshold and the failure rate will increase within the future time window, then joint optimization of consumer instance concurrency expansion, message batch merging, and backup channel pre-switching is triggered before the problem occurs. If the predictive performance results indicate that the message throughput will reach a high level and the failure rate will decrease within the future time window, then joint optimization of consumer instance concurrency contraction and priority parameter adjustment is triggered.

[0075] In this embodiment, the construction of historical processing samples based on the tracking data set and sending receipts first merges the original records and receipts into training samples on an event-by-event basis. Historical processing samples refer to labeled input feature pairs with target predicted values. Input features include throughput sequences, failure rate sequences, retry success rate sequences, channel-level statistics, and time features within a rolling window. Target predicted values ​​are quantitative expressions of indicators within a preset future time window, which refers to a time range of several minutes or hours in the future. After sample construction, feature engineering is performed, including aggregate statistics, lag feature generation, normalization, and category encoding. Next, a suitable prediction model is selected. The prediction model is a mathematical or statistical model capable of learning the mapping relationship between historical samples and future indicators. Model types can include tree-based regression models to capture non-linear relationships and sequence-based deep learning models to capture time dependencies. The model training process involves dividing historical samples into training and validation sets and using time-based cross-validation for generalization evaluation. During training, a loss function is defined to minimize prediction error, and regularization, early stopping, and hyperparameter search are used to prevent overfitting. After training, several metrics are evaluated on an independent test set to ensure that the mean absolute error of predicted throughput and the ability to discriminate failure rate trends meet business accuracy requirements. After the model is deployed as an online service, it uses real-time collected tracking data and receipts as input to generate predictive performance results for future time windows. The predictive performance results are trend judgments of metrics with confidence intervals, accompanied by model confidence scores. If the prediction results indicate that the throughput is below a threshold and the failure rate is rising within the future window, a joint optimization strategy is triggered before the problem occurs. Joint optimization includes consumer instance concurrency expansion to improve parallel processing capabilities, message batch merging to reduce single message processing overhead, and backup channel pre-switching to route high-risk messages to backup channels in advance. Message batch merging refers to merging several small messages into a single transmission according to type and destination to reduce protocol overhead. Backup channel pre-switching determines the candidate set based on the channel's historical reliability and real-time status and performs pre-warming. Conversely, if the predicted throughput is high and the failure rate decreases, concurrency contraction and priority parameter adjustment are triggered. Priority parameter adjustment refers to dynamically changing queue priorities and limits according to business importance, thereby reducing resources and saving costs while ensuring critical business operations. To avoid frequent fluctuations, the triggering action is jointly controlled by confidence thresholds, minimum trigger intervals, and change buffer mechanisms. Furthermore, online learning is used to continuously fine-tune the model with newly arrived tracking data and feedback to improve prediction accuracy and adaptability.

[0076] According to the message sending method based on message middleware provided in this application, the message sending request submitted by the business party is format-validated. After the message sending request passes the validation, the message object of the message sending request is serialized and written to the message database table corresponding to the message middleware. The target message is extracted from the message database table using several preset consumer instances, and the target message is then validated for business purposes. If the business validation passes, the corresponding downstream channel interface is called to send the message based on the message type of the target message. Through the implementation of this application, messages are uniformly written to the message middleware database table after format validation, and the large-volume message sending requirements can be easily handled by separating processing using consumer instances, thereby improving the high-concurrency processing capability of message sending.

[0077] Figure 2 illustrates a message sending device based on a message middleware according to an embodiment of this application. This message sending device can be used to implement the message sending method based on a message middleware in the aforementioned embodiments. As shown in Figure 2, the message sending device based on a message middleware mainly includes:

[0078] The first verification module 10 is used to perform format verification on the message sending request submitted by the business party.

[0079] The writing module 20 is used to serialize the message object of the message sending request and write it into the message database table corresponding to the message middleware after the message sending request is verified.

[0080] The second verification module 30 is used to extract target messages from the message database table through a number of preset consumer instances and perform business verification on the target messages.

[0081] The sending module 40 is used to call the corresponding downstream channel interface to send the message according to the message type of the target message if the business verification passes.

[0082] In one optional implementation of this embodiment, the first verification module is specifically used to: parse the field parameters in the message sending request submitted by the business party item by item to obtain a set of target parameters to be verified; perform an integrity comparison of the required fields according to the target parameter set to generate a first verification result; perform a data type comparison of the legal fields in the first verification result to obtain a second verification result; and perform a consistency comparison of the logical relationships between the fields according to the second verification result to determine the final verification result.

[0083] In one optional implementation of this embodiment, the second verification module is specifically used for: retrieving the message identifier of the target message to obtain a first verification data set; comparing whether the target message already exists in the historical sending record based on the first verification data set to generate a duplicate verification result; extracting the corresponding receiver identifier for messages that still need to be processed based on the duplicate verification result, and comparing the receiver identifier with a preset limit parameter to obtain a limit verification result; extracting the timestamp parameter of the valid message in the limit verification result, and comparing the difference between the timestamp parameter and the current system time to generate a timeliness verification result; and determining whether the business verification of the target message passes based on the timeliness verification result.

[0084] In an optional implementation of this embodiment, the writing module is further configured to: parse the sending result of the target message to obtain a first processing result; statistically analyze the message processing time based on the first processing result to generate time consumption data; update the log records based on the time consumption data and the first processing result to obtain a second processing result; extract the message object of the failed message in the second processing result, and obtain a dynamic retry parameter set based on the historical failure records associated with the message object; compare the preset retry count threshold and retry interval threshold based on the dynamic retry parameter set to generate new retry conditions; and determine whether to rewrite the message object into the message database table of the corresponding message middleware based on the new retry conditions.

[0085] In an optional embodiment of this invention, the message sending device based on message middleware further includes an update module. The update module is configured to: receive a sending receipt asynchronously pushed from a downstream channel interface; parse the receipt content to extract the target message identifier and corresponding status parameters; compare the status parameters with a preset status mapping relationship to generate a corresponding receipt result; locate the log record of the target message in the log storage based on the target message identifier, and update the log record using the receipt result.

[0086] In an optional embodiment of this invention, the message sending device based on message middleware further includes a generation module. The generation module is configured to: assign a unique identifier to the target message during the generation phase, obtain a target message identifier, and bind the target message identifier to the original request parameters of the target message to generate an initial tracking record; collect the corresponding processing events of the target message in the message middleware and consumer instance according to the target message identifier to generate intermediate tracking records; and aggregate the initial tracking records and intermediate tracking records associated with the target message identifier to generate a tracking dataset, which is then merged and written into the log storage.

[0087] In an optional embodiment of this invention, the message sending device based on message middleware further includes a control module. The control module is used to construct real-time performance monitoring indicators based on a tracking data set; dynamically analyze the real-time performance monitoring indicators to generate performance evaluation results; if the performance evaluation results indicate that the message throughput is lower than a preset threshold and the failure rate is higher than a preset threshold, then a joint optimization of consumer instance concurrency expansion and retry parameter reduction is triggered; if the performance evaluation results indicate that the message throughput is higher than a preset threshold and the retry success rate is stable, then a joint optimization of consumer instance concurrency contraction and quota parameter increase is triggered.

[0088] According to the message sending device based on message middleware provided in this application, the message sending request submitted by the business party is format-validated. After the message sending request passes the validation, the message object of the message sending request is serialized and written to the message database table corresponding to the message middleware. The target message is extracted from the message database table through several preset consumer instances, and the target message is validated for business purposes. If the business validation passes, the corresponding downstream channel interface is called to send the message according to the message type of the target message. Through the implementation of this application, messages are uniformly written to the message middleware database table after format validation, and the large-volume message sending requirements are easily handled by separating processing through consumer instances, thereby improving the high-concurrency processing capability of message sending.

[0089] Figure 3, provided in this application, illustrates an electronic device according to an embodiment of this application. This electronic device can be used to implement the message sending method based on a message middleware in the foregoing embodiments, and mainly includes:

[0090] The system includes a memory 301, a processor 302, and a computer program 303 stored on the memory 301 and executable on the processor 302. The memory 301 and the processor 302 are communicatively connected. When the processor 302 executes the computer program 303, it implements the message sending method based on message middleware as described in the preceding embodiments. The number of processors can be one or more.

[0091] The memory 301 can be a high-speed random access memory (RAM) or a non-volatile memory, such as a disk storage device. The memory 301 is used to store executable program code, and the processor 302 is coupled to the memory 301.

[0092] Furthermore, this application embodiment also provides a computer-readable storage medium, which may be disposed in the electronic device in the above embodiments, and the computer-readable storage medium may be the memory in the embodiment shown in FIG3 above.

[0093] The computer-readable storage medium stores a computer program that, when executed by a processor, implements the message sending method based on message middleware in the aforementioned embodiments. Furthermore, the computer-readable storage medium can also be a USB flash drive, external hard drive, read-only memory (ROM), RAM, magnetic disk, or optical disk, or any other medium capable of storing program code.

[0094] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0095] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A message sending method based on message middleware, characterized in that, include: Perform format validation on message sending requests submitted by business parties; After the message sending request passes the verification, the message object of the message sending request is serialized and written into the message database table corresponding to the message middleware; The system extracts target messages from the message database table using several preset consumer instances and performs business verification on the target messages. If the business verification passes, the system calls the corresponding downstream channel interface to send the message according to the message type of the target message. After the step of calling the corresponding downstream channel interface to send the message according to the message type of the target message, the system further includes: receiving a sending receipt asynchronously pushed by the downstream channel interface; parsing the receipt content of the sending receipt to extract the target message identifier and corresponding status parameters; comparing the status parameters with a preset status mapping relationship to generate a corresponding receipt result; locating the log record of the target message in the log storage according to the target message identifier and updating the log record according to the receipt result. Before the step of parsing the receipt content of the sending receipt to extract the target message identifier and corresponding status parameters, the system further includes: assigning a unique identifier to the target message during the generation stage, obtaining the target message identifier, and setting the target message identifier... The system binds the original request parameters of the target message to generate an initial tracking record; it collects the corresponding processing events of the target message in the message middleware and the consumer instance according to the target message identifier to generate an intermediate tracking record; it aggregates the initial tracking record and intermediate tracking record associated with the target message identifier to generate a tracking dataset, which is then merged and written into the log storage; it constructs historical processing samples based on the tracking dataset and sending receipts, and trains a prediction model using these samples; it uses the prediction model to predict the message throughput trend, failure rate trend, and retry success rate trend within a future preset time window, generating predictive performance results; if the predictive performance results indicate that the message throughput will be lower than the threshold and the failure rate will increase within the future time window, then a joint optimization of consumer instance concurrency expansion, message batch merging, and backup channel pre-switching is triggered before the problem occurs; if the predictive performance results indicate that the message will reach high throughput and the failure rate will decrease within the future time window, then a joint optimization of consumer instance concurrency contraction and priority parameter adjustment is triggered.

2. The message sending method based on message middleware according to claim 1, characterized in that, The step of performing format validation on the message sending request submitted by the business party includes: parsing the field parameters in the message sending request submitted by the business party item by item to obtain a set of target parameters to be validated; performing an integrity comparison on the required fields according to the set of target parameters to generate a first validation result; performing a data type comparison on the legal fields in the first validation result to obtain a second validation result; and performing a consistency comparison on the logical relationships between the fields according to the second validation result to determine the final validation result.

3. The message sending method based on message middleware according to claim 1, characterized in that, The steps of extracting target messages from the message database table using a preset number of consumer instances and performing business verification on the target messages include: retrieving the message identifier of the target message to obtain a first verification data set; comparing whether the target message already exists in historical sending records based on the first verification data set to generate a duplicate verification result; extracting the corresponding receiver identifier for messages that still need to be processed based on the duplicate verification result, and comparing the receiver identifier with a preset limit parameter to obtain a limit verification result; extracting the timestamp parameter of valid messages in the limit verification result, and comparing the timestamp parameter with the current system time to generate a timeliness verification result; and determining whether the business verification of the target message passes based on the timeliness verification result.

4. The message sending method based on message middleware according to claim 1, characterized in that, If the business verification passes, the step of calling the corresponding downstream channel interface to send the message according to the message type of the target message further includes: parsing the sending result of the target message to obtain a first processing result; statistically analyzing the message processing time based on the first processing result to generate time consumption data; updating the log records based on the time consumption data and the first processing result to obtain a second processing result; extracting the message object of the failed message in the second processing result, and obtaining a dynamic retry parameter set based on the historical failure records associated with the message object; comparing the preset retry count threshold and retry interval threshold based on the dynamic retry parameter set to generate new retry conditions; and determining whether to rewrite the message object into the message database table of the corresponding message middleware based on the new retry conditions.

5. The message sending method based on message middleware according to claim 1, characterized in that, The method further includes: constructing real-time performance monitoring indicators based on the tracking data set; dynamically analyzing the real-time performance monitoring indicators to generate performance evaluation results; if the performance evaluation results indicate that the message throughput is lower than a preset threshold and the failure rate is higher than a preset threshold, then triggering a joint optimization of consumer instance concurrency expansion and retry parameter reduction; if the performance evaluation results indicate that the message throughput is higher than a preset threshold and the retry success rate is stable, then triggering a joint optimization of consumer instance concurrency contraction and quota parameter increase.

6. A message sending device based on message middleware, characterized in that, The message sending device based on message middleware is used to implement the message sending method based on message middleware as described in claim 1. The message sending device based on message middleware includes: a first verification module, used to perform format verification on the message sending request submitted by the business party; a writing module, used to serialize the message object of the message sending request and write it into the message database table corresponding to the message middleware after the message sending request passes verification; a second verification module, used to extract the target message from the message database table through a preset number of consumer instances and perform business verification on the target message; and a sending module, used to call the corresponding downstream channel interface to send the message according to the message type of the target message if the business verification passes.

7. An electronic device, characterized in that, The system includes a memory and a processor, wherein: the processor is used to execute a computer program stored in the memory; when the processor executes the computer program, it implements the steps of the message sending method based on message middleware according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the message sending method based on message middleware as described in any one of claims 1 to 5.

Images