WeChat message sending method, device, equipment, medium and program product

Abstract

The application is suitable for the technical field of WeChat message processing, and provides a WeChat message sending method, device, equipment, medium and program product. The method comprises the following steps: according to a starting instruction of a sending task, updating the state of the sending task to execution and generating batch data; performing concurrent calling on the batch data to obtain a sending result; performing merging and blocking waiting on a plurality of sending results to obtain summary data, and writing batch identification into a ticket checking set or a failure set according to the summary data; when the ticket checking set covers the ticket checking set, it is determined that the sending task is executed completely; according to the batch identification of the failure set, failure log data is written into a database, and the state of the sending task is updated to completed. While ensuring the large-scale message batch sending processing capacity, the traceability and maintainability of the sending task execution process are improved.

Description

Technical Field

[0001] This invention relates to the field of WeChat message processing technology, and in particular to a WeChat message sending method, apparatus, device, medium, and program product. Background Technology

[0002] Current WeChat template message batch push technology uses a synchronous traversal of user groups based on an OpenId list. This involves a single system calling WeChat APIs one message at a time to send messages. When the user base is large, this method consumes system connection and memory resources for extended periods, leading to significantly increased processing latency and a risk of system crashes. To mitigate these issues, existing technologies also employ message queues to buffer sending tasks, which are then consumed asynchronously by consumer services. However, such solutions require pre-deployment and long-term maintenance of a certain number of consumer services. Furthermore, the user base and peak sending volume for different tasks are difficult to estimate accurately in advance, often resulting in a mismatch between consumer resource configuration and actual sending pressure. Both single-system synchronous processing and message queue buffering solutions lack an effective mechanism for unified verification of the completion status of numerous concurrent execution units during batch task execution, making it difficult to accurately determine whether the batch sending tasks have been completed without relying on long connections or callback channels. Summary of the Invention

[0003] This invention provides a method, apparatus, device, medium, and program product for sending WeChat messages. This invention solves the problems of processing conflicts and data exposure caused by repeated refreshing of credentials or transmission in the request-response chain in concurrent scenarios.

[0004] In a first aspect, embodiments of this application provide a method for sending WeChat messages, including: According to the start command of the sending task, the status of the sending task is updated to "in execution" and batch data is generated; The batch data is processed concurrently to obtain the sending results; Multiple sending results are merged and blocked to obtain summary data, and the batch identifier is written into the ticket verification set or failure set according to the summary data. When the ticket verification set covers the invoice set, it is determined that the sending task has been completed; according to the batch identifier of the failure set, the failure log data is written to the database and the status of the sending task is updated to completed.

[0005] Optionally, in a first implementation of the first aspect of the present invention, updating the status of the sending task to "in execution" and generating batch data according to the start instruction of the sending task includes: Based on the task start command and the cursor position corresponding to the current first-level fragment, query the user identifier list; The batch identifier is obtained by concatenating the task identifier of the sending task with the sequence number of the current first-level segment; The batch identifier and the user identifier list are encapsulated into batch data.

[0006] Optionally, in a second implementation of the first aspect of the present invention, after encapsulating the batch identifier and the user identifier list into batch data, the method further includes: The batch identifier and the user identifier list are serialized to obtain batch data; Based on the batch identifier, the storage directory in the object storage service is concatenated to generate a storage path; The storage path is used as the sole input parameter to call the function workflow's startup interface, thus obtaining the execution instance corresponding to the function workflow.

[0007] Optionally, in a third implementation of the first aspect of the present invention, the step of concurrently calling the batch data to obtain the sending result includes: Create multiple asynchronous callback tasks corresponding to multiple sending objects for the current second-level shard, and each asynchronous callback task corresponds to a template message sending request for the sending object; Based on the batch interval, the multiple asynchronous callback tasks are submitted to the thread pool for concurrent invocation, resulting in multiple callback results. The multiple callback results are then aggregated to obtain the sending result.

[0008] Optionally, in a fourth implementation of the first aspect of the present invention, after aggregating the plurality of callback results to obtain the sending result, the method further includes: The error codes and expiration identifiers in the sending results are matched to determine the sending object that triggers the credential refresh request, and a credential refresh request is sent to the main system. Based on the successful feedback of the credential refresh request, the target credential is read from the cache component; Based on the target credential, the sending object that triggered the credential refresh request in the sending result is resent, and the updated sending result is obtained.

[0009] Optionally, in a fifth implementation of the first aspect of the present invention, the step of merging and blocking multiple sending results to obtain summary data, and writing a batch identifier into a ticket verification set or a failure set based on the summary data, includes: Obtain multiple sending results corresponding to the secondary fragment sequence, and merge the asynchronous callback tasks corresponding to the sending results to obtain the merged result; The merged result is blocked and waited for. The success and failure identifiers of all the sending results corresponding to the current first-level fragment are counted to obtain summary data, and the summary data is stored in the object storage service. If the failure identifier does not exist in the summary data, the batch identifier is written into the ticket verification set; if the failure identifier exists in the summary data, the batch identifier is written into the failure set.

[0010] Optionally, in a sixth implementation of the first aspect of the present invention, the step of writing the batch identifier into the ticket verification set if the summary data does not contain the failure identifier, and writing the batch identifier into the failure set if the summary data contains the failure identifier, includes: By concatenating the preset prefix with the task identifier of the sending task, the first cache key value corresponding to the ticket verification set and the second cache key value corresponding to the failure set are obtained. If the failure identifier does not exist in the summary data, the batch identifier is written into the ticket verification set based on the first cache key value; if the failure identifier exists in the summary data, the batch identifier is written into the failure set based on the second cache key value.

[0011] Optionally, in the seventh implementation of the first aspect of the present invention, the step of determining that the sending task is completed when the ticket verification set covers the invoice set; and writing failure log data into the database and updating the status of the sending task to complete according to the batch identifier of the failure set, includes: According to the preset scheduling period, query the sending task whose status is in execution to obtain the task to be verified, and read the invoice set and the verification set according to the task identifier of the task to be verified. The batch identifiers of the invoice set and the verification set are compared. When the verification set contains all the batch identifiers of the invoice set, it is determined that the verification task has been completed. Based on the batch identifier in the failure set, read failure log data from the object storage service, write the failure log data into the database, and update the status of the task to be verified to complete.

[0012] Optionally, in an eighth implementation of the first aspect of the present invention, the step of querying the sending task whose status is executing according to a preset scheduling period to obtain the task to be verified, and reading the invoice set and the verification set according to the task identifier of the task to be verified, includes: According to the preset scheduling period, query the sending task whose status is "in execution" to obtain the task to be verified; Obtain the task identifier of the task to be verified, and concatenate the preset prefix with the task identifier to obtain the first target key value corresponding to the invoice set and the second target key value corresponding to the invoice verification set, respectively; Based on the first target key value and the second target key value, the invoice set and the verification set are read from the cache component, respectively.

[0013] Secondly, embodiments of this application provide a WeChat message sending device, including: The task initiation module is used to update the status of the task to "in execution" and generate batch data according to the task initiation command. The concurrent call module is used to perform concurrent calls on the batch data to obtain the sending results; The result aggregation module is used to merge and block multiple sending results to obtain aggregated data, and write the batch identifier into the ticket verification set or the failure set according to the aggregated data. The status update module is used to determine that the sending task has been completed when the ticket verification set covers the invoice set; and to write failure log data into the database and update the status of the sending task to complete according to the batch identifier of the failure set.

[0014] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the WeChat message sending method described above.

[0015] Fourthly, embodiments of this application provide a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the WeChat message sending method described above.

[0016] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the WeChat message sending method described above.

[0017] In one solution provided by the aforementioned WeChat message sending method, device, equipment, medium, and program products, a first-level data sharding based on the total number of users, followed by paginated queries on the current shard, ensures that the size of a single query and the amount of data loaded into memory at any given time is always kept within the sharding threshold, avoiding the processing burden on the database and system memory caused by centralized queries and loading of large-scale data. By writing the batch data corresponding to the shards to the object storage service and using the storage path corresponding to the batch data instead of the batch data itself as the input parameter of the function workflow, the function workflow startup process no longer needs to directly transmit batch user data, reducing the data transmission load during the function workflow startup phase. Furthermore, by further performing second-level data sharding on the batch data within the function workflow and using asynchronous callback tasks to concurrently call the sending objects in the second-level shards, the functionality is optimized for efficiency. This processing enables the message sending process within a single shard to have concurrent processing capabilities adapted to the frequency of WeChat interface calls. By identifying expired identifiers in the sending results and initiating voucher refresh requests to the main system, and then retrieving the target voucher from the cache component, it solves the processing conflicts and data exposure problems caused by repeated voucher refreshes or transmission in the request-response chain under concurrent scenarios. By setting invoice sets, verification sets, and failure sets, and having the distributed task scheduling component periodically compare these sets, the batch asynchronous sending tasks composed of function workflows corresponding to multiple shards can be accurately verified for overall completion without relying on long connections or callback channels. It can also locate and log failed batches, thereby improving the traceability and maintainability of the sending task execution process while ensuring the large-scale batch message sending processing capability. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram of the structure of a WeChat message sending system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a WeChat message sending method according to an embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of the implementation process of step S10; Figure 4 yes Figure 2 A schematic diagram of the implementation process of step S20; Figure 5 yes Figure 2 A schematic diagram of the implementation process of step S30; Figure 6 yes Figure 2 A schematic diagram of the implementation process of step S40; Figure 7 This is a flowchart of the workflow for starting the sending task and the sending data fragmentation start function in one embodiment of the present invention; Figure 8 This is a flowchart of a function workflow for sending WeChat template messages in one embodiment of the present invention; Figure 9 This is a flowchart of the workflow task completion status of the timed task verification function in one embodiment of the present invention; Figure 10 This is a schematic diagram of a WeChat message sending device according to an embodiment of the present invention; Figure 11 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0021] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0024] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0025] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0026] To address the problems mentioned above in the background art, this application provides a WeChat message sending method, apparatus, device, medium, and program product. The WeChat message sending method provided by this invention can be applied to, for example... Figure 1 The WeChat message sending system shown includes a sending task management device 1, a concurrent message sending device 2, a WeChat service device 3, and a data management device 4.

[0027] In one embodiment, such as Figure 2 As shown, a method for sending WeChat messages is provided, which can be applied to... Figure 1 Taking the WeChat message sending system as an example, the following steps are included: S10: Based on the start command of the sending task, update the status of the sending task to "in execution" and generate batch data; S20: Perform concurrent calls on the batch data to obtain the sending results; S30: Merge and block multiple sending results to obtain summary data, and write the batch identifier into the ticket verification set or failure set according to the summary data; S40: When the ticket verification set covers the invoice set, determine that the sending task has been completed; write the failure log data to the database according to the batch identifier of the failure set and update the status of the sending task to complete.

[0028] In this embodiment, by performing primary data sharding on the total number of users and then performing paginated queries on the current shard, the size of a single query and the amount of data loaded into memory at any given time is always controlled within the sharding threshold, avoiding the processing burden on the database and system memory caused by centralized queries and loading of large-scale data. By writing the batch data corresponding to the shard to the object storage service and using the storage path corresponding to the batch data instead of the batch data itself as the input parameter of the function workflow, the function workflow startup process no longer needs to directly transmit batch user data, reducing the data transmission load in the function workflow startup stage. By further performing secondary data sharding on the batch data within the function workflow and using asynchronous callback tasks to concurrently call the sending objects in the secondary shards, the message within a single shard is processed more efficiently. The sending process possesses concurrent processing capabilities adapted to the frequency of WeChat interface calls. By identifying expired identifiers in the sending results and initiating voucher refresh requests to the main system, and then retrieving the target voucher from the cache component, it resolves the processing conflicts and data exposure issues caused by repeated voucher refreshes or transmission in the request-response chain under concurrent scenarios. By setting invoice sets, verification sets, and failure sets, and having the distributed task scheduling component periodically compare these sets, the batch asynchronous sending tasks consisting of function workflows corresponding to multiple shards can be accurately verified for overall completion without relying on long connections or callback channels. It can also locate and log failed batches, thereby improving the traceability and maintainability of the sending task execution process while ensuring the large-scale batch message sending processing capability.

[0029] In one embodiment, such as Figure 3 As shown, step S10 specifically includes the following steps: S11: Based on the task start command and the cursor position corresponding to the current first-level fragment, query the user identifier list; S12: Concatenate the task identifier of the sending task with the sequence number of the current first-level segment to obtain the batch identifier; S13: Encapsulate the batch identifier and user identifier list into batch data.

[0030] In this embodiment, after a user triggers a WeChat template message sending task, the main system receives the start command and reads the task identifier, filtering conditions, current first-level segment number, and the cursor position corresponding to that segment. Then, it sets the sending task status to "in progress" to avoid the same task being repeatedly started. Simultaneously, it calculates the total number of target users (Total) based on the filtering conditions and determines the data boundary of the current first-level segment according to the principle of min(500, remaining users). Here, 500 represents the maximum number of user identifiers a first-level segment can handle, and the remaining users represent the number of target users not yet included in the batch starting from the current cursor position. When querying the user identifier list, the cursor position corresponding to the current first-level segment is used as the starting point, and a paginated query is generated based on the segment size. The query conditions are set, and only the user's OpenId or an equivalent user identifier field is retained in the query fields. This reduces the number of columns returned by the database and the size of objects loaded into memory at one time, avoiding OOM, frequent GC, or long-term blocking of task threads caused by a large number of OpenIds entering memory at once. During the query process, the cursor position can be maintained using an auto-incrementing primary key, creation time, sorted OpenId sequence number, or page offset. In order to ensure that there are no duplicates or omissions between shards, a fixed sorting rule is used, such as querying in ascending order by the user record primary key. At the same time, the position of the last user record returned by this query is updated to the cursor position of the next shard. If the number returned is less than 500, it means that the current task has reached the last first-level shard. The main system generates a batch identifier based on the task identifier of the sending task and the sequence number of the current first-level segment. The batch identifier is globally unique and traceable. It can be constructed using the concatenation method of "task ID_first-level segment sequence number". For example, the task identifier is used to distinguish different marketing sending tasks, and the first-level segment sequence number is used to distinguish different batches under the same task. After generating the batch identifier, the batch identifier is written into the invoice set, so that the invoice set becomes a list of all batches that should theoretically be completed in this sending task.The batch identifier and the retrieved user identifier list are encapsulated into batch data. The encapsulated content can include task identifier, batch identifier, current first-level segment sequence number, user OpenId list, template message parameter reference, creation time, and necessary idempotency control fields. The user OpenId list serves as the actual set of objects sent by the function workflow, the batch identifier serves as the tracking primary key for the entire batch, and the task identifier serves as the association primary key across sets, logs, and result summaries. The encapsulated batch data can be serialized and written to OBS or object storage service. Then, the object storage path is used as the unique input parameter of the function workflow startup interface, which can reduce the network transmission overhead during function startup and avoid startup failure or slow response due to excessively large request bodies. At the same time, necessary validation fields are retained in the batch data, such as the number of users, batch sequence number, and task status snapshot, so that the function instance can verify whether the input parameters match the current task after reading the object storage content. If the batch data is missing or the user identifier list is empty, an exception can be recorded and subsequent sending can be blocked.

[0031] In one embodiment, after encapsulating the batch identifier and user identifier list into batch data, the method further includes: The batch identifier and user identifier list are serialized to obtain batch data; The storage path is generated by concatenating the paths of the storage directories in the object storage service based on the batch identifier. By using the storage path as the sole input parameter to call the function workflow's startup interface, the execution instance corresponding to the function workflow can be obtained.

[0032] In this embodiment, after completing the first-level shard query and obtaining the batch identifier and user identifier list, the main system constructs a unified batch input parameter object. This batch input parameter object simultaneously includes the task identifier, batch identifier, current first-level shard sequence number, user OpenId list, template message parameter reference, creation time, data version number, and idempotency flag. Since a first-level shard can hold a maximum of 500 user sending objects, and the actual number of users in the current first-level shard is determined by a preset upper limit and the remaining number of users, the batch identifier and the actual user identifier list obtained from the query are serialized. The serialization format can be a JSON string, a compressed JSON byte stream, or a format supported by the platform. The object format maintains the original order of the user OpenId list, while the task identifier and batch identifier are stored as top-level fields. The template message content is not stored repeatedly in each user object and can be associated through template number, parameter reference, or task configuration snapshot, thereby reducing the data volume after serialization. After serialization, the main system calculates the digest value of the serialization result and records the number of users, so that the function workflow can verify whether the object is complete after reading it. If the serialization result is empty, the number of users is inconsistent with the first-level shard record, or the batch identifier is inconsistent with the identifier in the path, the batch can be marked as abnormal and the subsequent sending logic can be stopped to prevent dirty data from entering the concurrent sending process. When concatenating paths in the storage directory of the object storage service based on batch identifiers, hierarchical paths can be constructed according to task and batch dimensions. For example, a task directory can be created first using the task identifier of the task that sent the task, and then the input parameter object name corresponding to the current batch can be generated using the current batch identifier. This allows multiple batches of data under the same task to be centrally managed, while different tasks do not overwrite each other. After the path is generated, the main system uploads the serialized batch data to OBS or the object storage service and sets the necessary access permissions, content types, and expiration policies. After successful upload, the storage path is then associated with and saved with the batch identifier, task status, and invoice collection record. When the main system calls the function workflow's startup interface, it only passes the storage path as the sole input parameter, instead of transmitting the complete list of user-sent objects corresponding to the current first-level shard. This significantly reduces the network transmission burden on the startup interface, preventing function startup delays, interface overruns, or excessively long serialization / deserialization times caused by excessively large request bodies. After receiving the storage path, the function workflow generates a corresponding execution instance. Once the execution instance starts, it actively reads the batch data from the object storage service under that path and deserializes it locally to restore the batch identifier and user OpenId list. Then, it continues to perform second-level sharding and asynchronous transmission processing according to no more than 100 OpenIds per group.To ensure the idempotency of this process, the main system can check whether the batch identifier already exists as an execution instance record before calling the function workflow startup interface. If it exists and the status is "in execution", the system will not start it again. If the previous startup failed but the batch data in the object storage is complete, the system can re-initiate the call based on the same storage path. At the same time, after the function workflow startup interface returns the execution instance, it will bind and save the execution instance identifier with the batch identifier.

[0033] In one embodiment, such as Figure 4 As shown, step S20 specifically includes the following steps: S21: Create multiple asynchronous callback tasks corresponding to multiple sending objects for the current second-level shard, and each asynchronous callback task corresponds to a template message sending request for a sending object; S22: Based on the batch interval, submit multiple asynchronous callback tasks to the thread pool for concurrent invocation, obtain multiple callback results, and aggregate the multiple callback results to obtain the sending result.

[0034] In this embodiment, after the function workflow execution instance starts, it reads the batch data corresponding to the current first-level batch according to the object storage path in the unique input parameter, and deserializes it to obtain the batch identifier, task identifier, and user OpenId list. Since the first-level batch contains 500 user sending objects, the function instance does not directly and concurrently attack the WeChat interface with all 500 objects at once. Instead, it first performs secondary sharding according to 100 OpenIds as a group, so that each secondary shard forms a relatively controllable sending window. This can improve network IO utilization and avoid WeChat interface frequency limiting, connection pool exhaustion, or increased failure rate caused by excessive concurrency. After entering the current secondary shard, the function instance will traverse each sending object in the shard and, based on the OpenId of each sending object, perform secondary sharding. The template message sending request is constructed using enId, template message number, jump link, template parameters, task identifier, and batch identifier. Simultaneously, an asynchronous callback task is created for each sending request. This asynchronous callback task can be implemented using asynchronous execution methods such as CompletableFuture.supplyAsync, or it can be implemented using a thread pool task with callback result collection capabilities. Each task is responsible for completing one WeChat template message interface call and encapsulating the success identifier, failure identifier, error code, error description, sending object identifier, and batch identifier returned by the WeChat interface into a callback result. This allows the sending result of a single user to be recorded individually, and the failure of a single user's sending will not interrupt the sending of other users within the same second-level segment. To control the submission rhythm, when a function instance submits multiple asynchronous callback tasks, it performs rate limiting scheduling based on the batch interval and the global rate limiting token. The batch interval controls the submission interval of adjacent second-level shards within the same function instance, while the global rate limiting token controls the overall interface call rate under the same application identifier or task sending identifier. That is, before submitting an asynchronous task set corresponding to a second-level shard, the corresponding global rate limiting token is obtained first, and after submission, the next set of second-level shards is processed only after waiting for the batch interval. This reduces the probability of triggering WeChat interface frequency limits when multiple function instances execute in parallel. The thread pool itself is configured with the core thread count, maximum thread count, task queue length, and rejection policy to prevent the internal threads of the function instance from expanding indefinitely. At the same time, timeouts can be set at the task level or batch level. If an asynchronous task does not return after the preset waiting time, the sending object is recorded as a failure and a timeout flag is attached.After multiple asynchronous callback tasks are submitted, the function instance does not terminate immediately. Instead, it adds the Future objects generated by the current second-level shard and subsequent second-level shards to a collection to be aggregated. After all tasks are submitted, it aggregates the multiple Futures using `allOf`, a merge method, or an equivalent task merging mechanism, and then blocks until all callback results are returned or a timeout condition is met. After the blocking wait ends, the function instance reads the callback results of each asynchronous task one by one and categorizes them according to their status (success, failure, pending retry, abnormal interruption, etc.) to generate the sending result corresponding to the current first-level batch. The sending result contains the aggregated number of successful and failed tasks, and also retains the OpenId, error code, and error reason of the failed sending object. If the callback result contains an errcode=40001 or an expired accessToken, the object can be marked as a pending credential refresh retry object.

[0035] In one embodiment, after aggregating multiple callback results to obtain the sending result, the method further includes: Match the error codes and expiration identifiers in the sending results to determine the sending object that triggered the credential refresh request, and then send a credential refresh request to the main system; Based on the successful feedback of the credential refresh request, read the target credential from the cache component; Based on the target credential, the sending object that triggered the credential refresh request in the sending result is resent, and the updated sending result is obtained.

[0036] In this embodiment, after the function workflow aggregates the sending results of multiple asynchronous callbackable tasks within the current batch, each callback result is uniformly parsed, and fields such as the sending object identifier, OpenId, interface return status, error code, error description, and whether there is an expired credential identifier are extracted from the callback result. Then, the error code is matched with the preset credential expiration conditions, where error code 40001 is retained as the basis for determining accessToken expiration. If the callback result of a certain sending object shows that the template message failed to be sent and the error code is 40001, or if the returned content contains an expiration identifier such as accessToken invalid, expired, or unavailable, then the sending object is added to the pending refresh and retry list. The set of retry requests to be refreshed is not empty. The function instance does not refresh the credentials for each asynchronous task individually. Otherwise, in high-concurrency scenarios, multiple function instances or multiple threads will refresh the accessToken at the same time, which will cause credential overwriting, cache update conflicts or waste of interface call counts. Therefore, the function instance can initiate a credential refresh request to the main system at the batch level. The request only carries the task identifier, application identifier, batch identifier and trigger reason, and does not carry the plaintext content of the old accessToken and the new accessToken, so that the main system is responsible for executing the unified credential refresh logic. After receiving a refresh request, the main system uses a distributed lock or cache lock to determine if another instance is already refreshing the accessToken of the same application. If a refresh action is in progress, it waits for the refresh action to complete or directly reads the latest credential status from the cache. If no refresh action is in progress, it calls the WeChat credential interface to obtain a new accessToken and writes the new credential to Redis or other caching components, setting the corresponding validity period and version number. Then, it only returns a refresh success feedback, cached key-value pairs, or credential version information to the function workflow, without directly returning the plaintext accessToken in the response body, thus avoiding the credential being exposed in the request-response chain. After receiving a successful feedback from the credential refresh request, the function instance reads the target credential from the cache component according to the agreed cached key-value pairs and verifies whether the target credential is empty, still valid, and whether its version number is later than the credential used in the failed transmission. If the verification fails, the transmission object in the refresh retries set is marked as a credential refresh failure and written as a failure result. If the verification passes, the target credential replaces the credential field in the original transmission request, and the transmission object in the refresh retries set is retried.Retrying the sending process can reuse thread pools and asynchronous callback task mechanisms, but the number of retries is limited to prevent the same OpenId from being retried indefinitely due to long-term credential errors or WeChat interface exceptions. The retry result needs to overwrite or correct the original temporary failure result. If the retry is successful, the status of the sending object is updated to success and a retry success flag is recorded. If the retry fails again and the error code is no longer of the credential expiration type, it is recorded as a final failure according to the actual error code. If a 40001 error is still returned after the retry, it indicates that the cached credential may not have been updated successfully or there is an error in the application configuration. Refreshing should be stopped and the result should be classified as a failure to prevent circular refreshes. The function instance re-aggregates the original success result, the retry success result after credential refresh, and the final failure result to form an updated sending result. The sending result retains the batch identifier, the number of successes, the number of failures, the number of sending objects that triggered the credential refresh, the retry completion status, and the failure details.

[0037] In one embodiment, such as Figure 5 As shown, step S30 specifically includes the following steps: S31: Obtain multiple sending results corresponding to the secondary fragmentation sequence, and merge the asynchronous callback tasks corresponding to the sending results to obtain the merged result; S32: Block and wait for the merged result, count the success and failure flags in all the sending results corresponding to the current first-level fragment, obtain the summary data, and store the summary data in the object storage service. S33: If the summary data does not contain a failure identifier, then write the batch identifier into the ticket verification set; if the summary data contains a failure identifier, then write the batch identifier into the failure set.

[0038] In this embodiment, after the function workflow completes the sending of the second-level segments within the current first-level segment, it retrieves the set of asynchronous callback tasks corresponding to all second-level segments under the first-level segment from the task execution context. Since the first-level segment is preset to have 500 user sending objects, and the function further performs second-level segmentation based on 100 OpenIds, multiple second-level segment sequences are formed. Each second-level segment sequence contains several asynchronous tasks corresponding to template message sending requests. The function instance uniformly registers the future objects, callback handles, or task result references corresponding to these asynchronous tasks into the set to be merged in the current batch, using the batch identifier as the aggregation primary key to avoid mixing sending results from different batches into the same summary range. Multiple asynchronous callback tasks are merged using allOf, task barriers, or equivalent merging methods to obtain a merged result that represents the overall sending completion status of the current first-level segment. The function instance blocks and waits for the merged results, setting reasonable timeout and exception fallback logic during the waiting process. If a sending object returns a WeChat interface result normally, the success flag, failure flag, error code, and sending object flag are read. If an asynchronous task throws an exception or times out, the sending object is converted to a failure flag and the reason for the exception is recorded. After the results corresponding to all second-level shards are collected, the function instance counts the number of successes, failures, total number of sending, failure details, retry results after triggering voucher refresh, and batch flags according to the current first-level shard dimension, forming summary data. The summary data is then serialized and written to the result directory of the object storage service. The batch is written to the verification set based on whether there are failure indicators in the summary data. If all sending objects under the current first-level segment are in a successful state, or if a temporary failure has been recovered after a retrieval and voucher refresh, then the batch meets the conditions for passing the ticket verification and the batch indicator can be written to the ticket verification set. If there are still failure indicators such as sending failure, task timeout, request exception, or retry failure in the summary data, then the batch needs to be located and the failure log needs to be retained in the subsequent process. Therefore, the batch indicator is written to the failure set, and the subsequent verification process waits for the invoice set, ticket verification set, and failure set to complete the overall task status judgment.

[0039] In one embodiment, step S33 specifically includes the following steps: By concatenating the preset prefix with the task identifier of the sending task, we obtain the first cache key value corresponding to the ticket verification set and the second cache key value corresponding to the failure set. If the summary data does not contain a failure identifier, the batch identifier is written to the ticket verification set based on the first cache key value; if the summary data contains a failure identifier, the batch identifier is written to the failure set based on the second cache key value.

[0040] In this embodiment, the task identifier of the sending task is read, and two isolated set key values ​​are generated according to the unified key name rules agreed upon in the cache component. The ticket verification set is used to record batches that have been sent and passed the result summary, and the failure set is used to record batches that have failed to send, have execution exceptions, time out, or still fail after retries. The preset prefix of the ticket verification set is set to asyncTicketCheck, and the preset prefix of the failure set is set to asyncFail. The preset prefix is ​​concatenated with the task identifier of the sending task to obtain the first cache key value asyncTicketCheck: task ID and the second cache key value asyncFail: task ID. Since the task identifier is unique within a WeChat template message sending task, this concatenation method can ensure that the ticket verification set and failure set of different sending tasks are not confused, and at the same time, the timed verification process can reverse locate the corresponding set based on the task identifier alone.

[0041] The function workflow determines whether there is a failure flag based on the summary data of the current first-level shard. If all sent objects in the summary data have succeeded, or if some objects have been converted to success after the accessToken expires through credential refresh and retries, it means that although the batch is executed asynchronously, it has been completed and meets the ticket verification conditions from the result perspective. Therefore, the current batch flag can be written to the ticket verification set based on the first cache key value. When writing, a Set collection structure is used instead of a List structure because Set can naturally remove duplicates. Even if the function instance writes the same batch repeatedly due to network jitter, retry startup, or idempotent compensation, it will not cause duplicate counting. If failure markers still exist in the aggregated data, it indicates that at least one sending object in this batch ultimately failed, or that there were exceptions such as function execution errors, WeChat API call failures, thread pool task timeouts, or voucher refresh failures. In this case, the current batch marker is written to the failure set based on the second cache key value, enabling the scheduled task to quickly locate the batch that needs to read the failure log through the failure set. At the same time, to avoid the failure batch being unable to participate in the overall completion judgment, after the failure log has been written to the object storage and the execution process of this batch has indeed ended, the batch marker is synchronously included in the ticket verification set, or the scheduled verification logic treats the failure set as part of the completed batch. The failure set is responsible for failure location, and the ticket verification set is responsible for completion coverage verification. The two cannot be used interchangeably semantically.

[0042] In one embodiment, such as Figure 6 As shown, step S40 specifically includes the following steps: S41: According to the preset scheduling period, query the sending tasks with the status of execution, obtain the tasks to be verified, and read the invoice set and the verification set according to the task identifier of the tasks to be verified. S42: Compare the batch identifiers of the invoice set and the verification set. When the verification set contains all the batch identifiers in the invoice set, it is determined that the verification task has been completed. S43: Based on the batch identifier in the failure set, read the failure log data from the object storage service, write the failure log data to the database, and update the status of the task to be verified to completed.

[0043] In this embodiment, the verification task is periodically triggered by the xxl-job or distributed scheduling component according to a preset scheduling period. After the scheduling task is started, the sending tasks with the status of "in execution" in the task table are queried first, and these tasks that have not yet completed the closed-loop verification are taken as the tasks to be verified. Then, based on the task identifier of the task to be verified, the invoice set and the verification set corresponding to the task are read from the cache component. The invoice set represents all the first-level fragment batch identifiers that have been generated and should be executed in the task start phase, and the verification set represents the batch identifiers of the function workflow that have completed the sending result summary and returned the completion record. The scheduling task compares the batch identifiers of the invoice set and the verification set to determine if each batch identifier in the invoice set appears in the verification set. If a batch identifier still exists only in the invoice set but not in the verification set, it indicates that the function workflow corresponding to that batch may not have been completed, the result has not been written to the cache, the object storage result has not been persisted to disk, or the execution instance has encountered an exception and has not been archived. In this case, the "in execution" status is retained, and the verification continues in the next scheduling cycle. If the verification set contains all batch identifiers in the invoice set, it means that all first-level shards split from this sending task have returned verifiable results. The main system does not need to rely on function workflow callbacks or maintain long connections to confirm that the task to be verified has been completed. To avoid the inability to close the loop when there are failed batches, the failure set is used as a failure location set, not to replace the completion verification set. That is, for failed batches that have generated summary data, they can be identified as "executed and completed" in the coverage verification, and their failure attributes are marked by the failure set. The scheduling task reads the failure set corresponding to the task. If the failure set is empty, it means that all batches have been successfully completed, and the status of the task to be verified can be directly updated to "completed". If the failure set is not empty, the result path or failure log path in the object storage service is concatenated one by one according to the batch identifier in the failure set, and the corresponding failure log data is read from the object storage service. The failure log data may include task identifier, batch identifier, failure OpenId, error code, error description, whether voucher refresh was triggered, retry result, function execution instance identifier, and failure occurrence time. The failure log data is written to the database so that the operations side can view the failure details, the technical side can locate the cause of the anomaly, or compensation can be sent as needed by the business. After the failure log is written to the database, the scheduling task updates the status of the task to be verified to "completed" and records the completion time, number of successes, number of failures, and final summary status. This allows a WeChat template message sending task that is asynchronously processed by multiple function workflows to form a complete closed loop through the invoice set, verification set, and failure set, even without callbacks or long connections.

[0044] In one embodiment, step S41 specifically includes the following steps: Based on the preset scheduling period, query the sending tasks with the status of "in execution" to obtain the tasks to be verified; Obtain the task identifier of the task to be verified, and concatenate the preset prefix with the task identifier to obtain the first target key value corresponding to the invoice set and the second target key value corresponding to the invoice verification set, respectively; Based on the first target key and the second target key, the invoice set and the verification set are read from the cache component, respectively.

[0045] In this embodiment, the verification process is automatically triggered by the xxl-job or distributed scheduling component according to a preset scheduling cycle. After the scheduling thread starts, it accesses the task sending table and uses the task status field as a filter condition to query only the task records with the status of "in execution" to obtain the set of tasks to be verified. In order to avoid multiple scheduling nodes processing the same task repeatedly, a distributed lock can be added based on the task identifier after the query, or optimistic verification can be performed using the database status version number, so that only one scheduling instance compares the same set of task sending executions at the same time. The task identifier of the task to be verified is read and concatenated with a preset prefix according to the unified rules of cache key names. The invoice set is used to store all batch identifiers generated during the task startup phase, and the verification set is used to store the batch identifiers after the function workflow is completed, sent, and the results are written back. Therefore, the preset prefix of the invoice set can be set to asyncTicket:, and the preset prefix of the verification set can be set to asyncTicketCheck:. Then, they are concatenated with the task identifier to obtain the first target key value asyncTicket: task ID and the second target key value asyncTicketCheck: task ID. Since the task identifier is unique in a single sending task, the above key values ​​can isolate the batch sets of different tasks, avoiding mutual pollution of cached data when multiple marketing sending tasks are executed concurrently. The scheduling component accesses caching components such as Redis based on the first and second target key values, and reads all members of the invoice set and the verification set respectively. The reading is done using a Set collection because Sets can remove duplicates and are suitable for subsequent overwrite comparisons. If the first target key value does not exist or the invoice set is empty, it indicates that the task may not have completed batch initialization or the cache may have expired abnormally. In this case, the task is not directly considered complete, but a verification error is recorded and the process waits for the next scheduling cycle or triggers a compensation check. If the second target key value does not exist, the verification set can be considered empty, indicating that no batch has yet completed verification. If both sets can be read normally, they are taken as a snapshot of the sets for the current scheduling cycle and passed to subsequent steps to determine whether the verification set contains all batch identifiers from the invoice set.

[0046] In this embodiment, as Figure 7As shown, after a user triggers a user message sending task, the main system first saves the task status as "in execution," then queries the total number of users (Total) to be sent, and divides Total into shards of 500 users each. After obtaining the total number of first-level shards, it enters a batch loop. Each loop first checks if there is any unprocessed data. If no unprocessed data exists, the batch splitting process ends. If unprocessed data still exists, it queries the list of user OpenIds for this batch, paginated by the current first-level shard number. Then, it generates a unique batch identifier for this batch and writes it to the invoice Set collection. Next, it encapsulates the batch identifier and the user OpenId list into a batch input parameter object, serializes it, and stores it in the OBS object storage service. Finally, it uses this storage path as the unique input parameter to start the function workflow. After startup, it returns to the loop check node to process the next first-level shard, until all first-level shards have completed batch generation and function workflow startup.

[0047] In this embodiment, as Figure 8 As shown, after the function workflow execution instance starts, it retrieves the corresponding batch data from the OBS object storage service based on the storage path in the unique input parameter. It then deserializes the data to obtain the batch identifier and a list of user OpenIds, and performs secondary sharding according to 100 OpenIds per group. Upon entering the sharding loop, it checks if there are any unprocessed secondary shards. If so, it uses `CompletableFuture.supplyAsync()` to create asynchronous callback tasks for each sending object within that shard, concurrently calling the WeChat template message interface and collecting callback results. After completion, it returns to the loop check node to continue processing the next group. If all secondary shards have been submitted, it merges all futures under the current primary shard and blocks until all callback results are returned or a timeout condition is met. Subsequently, it calculates success and failure identifiers to form summary data, which is stored in the OBS object storage service. Finally, it writes the current batch identifier to the ticket verification Set. If the summary data contains sending failure or execution failure identifiers, it writes the batch identifier to the failure Set, and the function execution ends.

[0048] In this embodiment, as Figure 9As shown, the scheduling component triggers the verification process according to a preset scheduling cycle. First, it queries the task table for tasks in execution as those to be verified. Then, based on the task identifier of the task to be verified, it reads the invoice set and the verification set respectively, and verifies the overall completion status of the asynchronous task by comparing the batch identifiers. If the verification set does not yet cover all batch identifiers in the invoice set, the task is determined not to be fully completed, the execution status is retained, and the current scheduling ends, waiting for the next scheduling cycle to continue verification. If the verification set contains all batch identifiers in the invoice set, the task to be verified is determined to be fully completed. Subsequently, based on the batch identifiers in the failure set, it retrieves relevant return parameters and failure log data from the OBS object storage service, saves the failure log data into the database, updates the status of the sending task to completed, and the current scheduling ends.

[0049] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0050] In one embodiment, a WeChat message sending device is provided, which corresponds one-to-one with the WeChat message sending method described in the above embodiments. For example... Figure 10 As shown, the WeChat message sending device includes: The task initiation module 701 is used to update the status of the task to "in execution" and generate batch data according to the task initiation command. The concurrent call module 702 is used to perform concurrent calls on batch data and obtain the sending results; The result aggregation module 703 is used to merge and block multiple sending results to obtain aggregated data, and write the batch identifier into the ticket verification set or the failure set according to the aggregated data. The status update module 704 is used to determine that the sending task has been completed when the ticket verification set covers the invoice set; based on the batch identifier of the failure set, it writes the failure log data to the database and updates the status of the sending task to complete.

[0051] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0052] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0053] This application also provides a computer device, such as... Figure 11 As shown, the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor. When the processor executes the computer program, it implements the steps in any of the above method embodiments, or when the processor executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0054] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.

[0055] Those skilled in the art will understand that Figure 11 The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0056] The aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), or field-programmable gate arrays (FPGAs). Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0057] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.

[0058] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0059] This application provides a computer program product that, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.

[0060] 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0061] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0062] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0063] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0064] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0065] 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, and should all be included within the protection scope of this application.

Claims

1. A method for sending WeChat messages, characterized in that, include: According to the start command of the sending task, the status of the sending task is updated to "in execution" and batch data is generated; The batch data is processed concurrently to obtain the sending results; Multiple sending results are merged and blocked to obtain summary data, and the batch identifier is written into the ticket verification set or failure set according to the summary data. When the ticket verification set covers the invoice set, it is determined that the sending task has been completed; according to the batch identifier of the failure set, the failure log data is written to the database and the status of the sending task is updated to complete; specifically, according to a preset scheduling period, the sending task with the status of execution is queried to obtain the task to be verified; Obtain the task identifier of the task to be verified, and concatenate the task identifier with a preset prefix to obtain the first target key value corresponding to the invoice set and the second target key value corresponding to the verification set; based on the first target key value and the second target key value, read the invoice set and the verification set from the cache component respectively; compare the batch identifiers of the invoice set and the verification set, and determine that the task to be verified is completed when the verification set contains all the batch identifiers in the invoice set; based on the batch identifiers in the failure set, read the failure log data from the object storage service, write the failure log data into the database, and update the status of the task to be verified to complete.

2. The WeChat message sending method as described in claim 1, characterized in that, The step of updating the status of the sending task to "in execution" and generating batch data according to the start command of the sending task includes: Based on the task start command and the cursor position corresponding to the current first-level fragment, query the user identifier list; The batch identifier is obtained by concatenating the task identifier of the sending task with the sequence number of the current first-level segment; The batch identifier and the user identifier list are encapsulated into batch data.

3. The WeChat message sending method as described in claim 2, characterized in that, After encapsulating the batch identifier and the user identifier list into batch data, the method further includes: The batch identifier and the user identifier list are serialized to obtain batch data; Based on the batch identifier, the storage directory in the object storage service is concatenated to generate a storage path; The storage path is used as the sole input parameter to call the function workflow's startup interface, thus obtaining the execution instance corresponding to the function workflow.

4. The WeChat message sending method as described in claim 3, characterized in that, The concurrent calls to the batch data to obtain the sending results include: Create multiple asynchronous callback tasks corresponding to multiple sending objects for the current second-level shard, and each asynchronous callback task corresponds to a template message sending request for the sending object; Based on the batch interval, the multiple asynchronous callback tasks are submitted to the thread pool for concurrent invocation, resulting in multiple callback results. The multiple callback results are then aggregated to obtain the sending result.

5. The WeChat message sending method as described in claim 4, characterized in that, After aggregating the multiple callback results to obtain the sending result, the process also includes: The error codes and expiration identifiers in the sending results are matched to determine the sending object that triggers the credential refresh request, and a credential refresh request is sent to the main system. Based on the successful feedback of the credential refresh request, the target credential is read from the cache component; Based on the target credential, the sending object that triggered the credential refresh request in the sending result is resent, and the updated sending result is obtained.

6. The WeChat message sending method as described in claim 5, characterized in that, The process of merging and blocking multiple sending results to obtain aggregated data, and then writing the batch identifier into the ticket verification set or failure set based on the aggregated data, includes: Obtain multiple sending results corresponding to the secondary fragment sequence, and merge the asynchronous callback tasks corresponding to the sending results to obtain the merged result; The merged result is blocked and waited for. The success and failure identifiers of all the sending results corresponding to the current first-level fragment are counted to obtain summary data, and the summary data is stored in the object storage service. If the failure identifier does not exist in the summary data, the batch identifier is written into the ticket verification set; if the failure identifier exists in the summary data, the batch identifier is written into the failure set.

7. The WeChat message sending method as described in claim 6, characterized in that, If the failure identifier is not present in the aggregated data, then the batch identifier is written into the ticket verification set. If the failure identifier exists in the summarized data, then the batch identifier is written into the failure set, including: By concatenating the preset prefix with the task identifier of the sending task, the first cache key value corresponding to the ticket verification set and the second cache key value corresponding to the failure set are obtained. If the failure identifier does not exist in the summary data, the batch identifier is written into the ticket verification set based on the first cache key value; if the failure identifier exists in the summary data, the batch identifier is written into the failure set based on the second cache key value.

8. A WeChat message sending device, characterized in that, The steps for implementing the WeChat message sending method as described in any one of claims 1 to 7 include: The task initiation module is used to update the status of the task to "in execution" and generate batch data according to the task initiation command. The concurrent call module is used to perform concurrent calls on the batch data to obtain the sending results; The result aggregation module is used to merge and block multiple sending results to obtain aggregated data, and write the batch identifier into the ticket verification set or the failure set according to the aggregated data. The status update module is used to determine that the sending task is completed when the verification set covers the invoice set; write failure log data to the database and update the status of the sending task to complete according to the batch identifier of the failure set; the status update module is specifically used to: query the sending tasks with the status of execution according to a preset scheduling period to obtain the tasks to be verified; obtain the task identifier of the task to be verified, and concatenate the task identifier with a preset prefix to obtain the first target key value corresponding to the invoice set and the second target key value corresponding to the verification set; read the invoice set and the verification set from the cache component according to the first target key value and the second target key value; compare the batch identifiers of the invoice set and the verification set, and determine that the task to be verified is completed when the verification set contains all the batch identifiers in the invoice set; read failure log data from the object storage service according to the batch identifier in the failure set, write the failure log data to the database, and update the status of the task to be verified to complete.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the WeChat message sending method as described in any one of claims 1 to 7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the WeChat message sending method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the WeChat message sending method as described in any one of claims 1 to 7.

Images