Annotation-driven idempotent processing method and system

Abstract

The invention relates to the technical field of idempotent processing, and discloses an annotation-driven idempotent processing method and system, and the method comprises the following steps: 1, collecting historical business request records and performance data, optimizing a strategy parameter combination through a particle swarm algorithm, and generating a final strategy vector; step 2, intercepting the method call marked by the annotation, analyzing the annotation and the method actual parameter, and generating request metadata; 3, loading a final strategy vector according to the service identifier and the strategy version number, and generating an idempotent configuration object; step 4, generating an idempotent key based on the service parameters, preferentially searching in a local cache, directly returning if the search is hit, and otherwise, entering distributed duplicate judgment; 5, calling an original method during first-time processing, packaging an idempotent result load, writing the load into a cache, and releasing a lock; and step 6, constructing a processing event, sending the processing event to the message queue, and returning a service result in the idempotent result. According to the invention, intelligent configuration and efficient execution of idempotent processing in multiple scenes are realized.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of idempotent processing, and particularly relates to an annotation-driven idempotent processing method and system. BACKGROUND

[0002] With the increasing complexity of Internet business system architecture, distributed deployment and micro-service have become mainstream, and business systems are facing increasingly serious repeated request problems in complex scenarios such as high concurrency, cross-node and network jitter. For example, users trigger retries due to request timeout caused by network jitter, or message duplication caused by service node failure. If the system lacks effective idempotent guarantee mechanism, it may cause serious consequences such as repeated creation of orders, repeated deduction of account balance, and abnormal reduction of inventory. Therefore, the idempotent processing capability has become a key technical means to ensure the consistency of business data and the stability of the system.

[0003] In the prior art, idempotent processing usually relies on fixed parameters as idempotent keys to judge repeated requests, and the results are cached in local or distributed media. Subsequent requests are judged by idempotent keys to determine whether they are repeated calls. Some solutions integrate idempotent logic into business code through annotation configuration, but the configuration flexibility is poor, and there is a lack of strategy adaptive ability for different business scenarios, which easily causes resource waste or miss. In addition, traditional idempotent strategies are mostly statically configured, and it is difficult to dynamically adjust the parameter combination according to the actual business request characteristics, and it is difficult to balance the multi-dimensional performance indicators such as throughput, conflict rate and response time, which limits the promotion and application of idempotent solutions in complex systems. SUMMARY

[0004] The application provides an annotation-driven idempotent processing method and system, which solves the technical problems of rigid idempotent strategy configuration, weak parameter adaptation ability and difficulty in balancing performance and consistency in multiple business scenarios in related technologies.

[0005] The application provides an annotation-driven idempotent processing method, which comprises the following steps:

[0006] Step 1, collect the business request records and performance data of historical calls, use particle swarm algorithm to iteratively optimize the strategy parameter combination, generate the final strategy vector, and store it in the strategy configuration center;

[0007] Step 2, intercept the method call marked by the @MethodIdempotent annotation through the AOP aspect, parse the annotation configuration and method arguments, and generate request metadata;

[0008] Step 3, according to the business identifier and strategy version number in the request metadata, load the corresponding final strategy vector from the strategy configuration center, and inject an idempotent configuration object;

[0009] Step 4: Generate a business key based on the business parameters in the request metadata and hash it to form an idempotent key;

[0010] According to the local priority policy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a hit is found, the idempotency result in the cache is directly returned; if a hit is not found, the distributed duplicate detection step is entered;

[0011] Step 5: During the first processing, the original business method is called to obtain the normal return result or exception information, which is uniformly encapsulated into an idempotent result payload. The idempotent result payload is written to the distributed cache and a lifetime is set. The payload is also written to the local cache and an expiration time is set, and the lock resource is released.

[0012] Step 6: Build a processing event containing the idempotency key, processing status, timestamp, and performance indicators, send it to the message queue, and return the business results in the idempotency result.

[0013] Furthermore, the policy parameter combination includes: lifetime, cache type, lock mode, local cache priority switch and maximum number of retries;

[0014] The particle swarm algorithm is used to iteratively optimize the strategy parameter combination to generate the final strategy vector, including:

[0015] Step 11: Collect historical service request records and performance data, and combine policy parameters into a unified numerical code to form a training sample;

[0016] Step 12: Initialize the particle swarm based on the training samples and domain heuristic rules to obtain the initial particle parameter vector and velocity vector;

[0017] Step 13: Use the standard particle swarm update formula to update the position and speed of the survival time, and use the probabilistic voting method to update the cache type, lock mode, local cache priority switch, and maximum retry times;

[0018] Step 14: construct a fitness function based on the weighted throughput rate, conflict rate, and timeout rate, and calculate the fitness of each particle to determine the particle with the highest fitness in the current iteration and the particle with the highest global fitness;

[0019] Step 15: When the number of iterations reaches the maximum number of iterations, the particle with the largest global fitness is used as the final strategy vector and stored in the strategy configuration center.

[0020] Furthermore, the domain heuristic rules include:

[0021] Set the initial lifetime value to three times the 99th percentile duration of the target service request in the most recent statistical period.

[0022] When the historical local cache hit rate is higher than the hit threshold, the cache type is initialized as local cache, otherwise, as distributed cache;

[0023] When the request concurrency peak is less than the concurrency threshold, the lock mode is initialized as reentrant lock, and when the concurrency peak is not less than the concurrency threshold, it is initialized as spin read-write lock;

[0024] When the node available memory ratio is higher than the memory threshold, the local cache priority switch is initialized as an open state, otherwise, as a closed state;

[0025] When the historical idempotent conflict rate is greater than the conflict threshold, the maximum retry count is initialized to one, otherwise, to zero.

[0026] Further, the method call marked by the @MethodIdempotent annotation is intercepted by the AOP aspect, the annotation configuration and the method argument are parsed, and the request metadata is generated, including:

[0027] Step 21, the annotated method is woven into the proxy chain at application startup, and the connection point information and thread context at the time of calling are captured;

[0028] Step 22, parse the annotation configuration to get the annotation parameter set, extract the SpEL expression, version number and scope information;

[0029] Step 23, collect the method argument and serialize it into a parameter set, generate a business identifier based on the scope, target class name and method name in the annotation parameter set, and determine the version identifier combined with the annotation version number, merge the business identifier, version identifier, parameter set and call timestamp to get the request metadata.

[0030] Further, according to the business identifier and policy version number in the request metadata, the corresponding final policy vector is loaded from the policy configuration center, and the idempotent configuration object is generated by injection, including:

[0031] Step 31, concatenate the business identifier and policy version number into an index key to access the policy configuration center, and get the matching final policy vector;

[0032] Step 32, integrity check is performed on the fields of the final policy vector in turn, and if any field is missing, fallback is triggered and an alarm is recorded;

[0033] Step 33, according to the field mapping relationship, the time to live, cache type, lock mode, local cache priority switch and maximum retry count are injected into the corresponding attributes of the idempotent configuration object to get the immutable idempotent configuration object, and written into the call context.

[0034] Further, a business key is generated based on the business parameter in the request metadata, and a hash processing is performed to form an idempotent key, including:

[0035] Step 41: Evaluate the parameter set in the request metadata according to the expression specified in the annotation to obtain the original business parameter string and perform unified encoding and normalization to generate a business key;

[0036] Step 42: Perform a SHA-256 hash operation on the business key to obtain a hash value, and concatenate the fixed prefix and the hash value to obtain an idempotent key;

[0037] Step 43: Calculate the CRC32 checksum for the idempotent key and record it in the monitoring event stream;

[0038] Step 44: When the service key length exceeds a preset threshold, a degradation strategy is triggered and an alarm is output.

[0039] Furthermore, duplicates are detected in the local cache and the results are returned based on the local priority policy and cache type set in the idempotence configuration object, including:

[0040] Step 51: When the local cache priority switch is on and the cache type is local cache, query the local cache for the corresponding idempotent result using the idempotent key;

[0041] Step 52: If an idempotent result is found, the remaining lifetime of the idempotent result is compared with the lifetime threshold. If the remaining lifetime is greater than the lifetime threshold, the idempotent result is directly returned to the caller and a local hit indicator is reported.

[0042] Step 53: If no idempotent result is found, or the remaining lifetime is not greater than the lifetime threshold, a miss signal is output and the distributed duplicate detection step is entered.

[0043] Furthermore, the distributed duplicate detection step includes:

[0044] Step 61: Acquire a distributed lock with the idempotent key in the distributed cache system according to the lock mode specified by the idempotent configuration object;

[0045] Step 62: If the lock is acquired successfully, query whether the distributed cache has stored the historical idempotency result. If found, return the historical idempotency result to the caller.

[0046] Step 63: If no historical idempotent result is found, the business method is executed and the business result is written to the distributed cache, and then the distributed lock is released;

[0047] Step 64: If the lock acquisition fails, wait for the distributed lock to be released and return the idempotent result in the distributed cache.

[0048] Furthermore, the step 5 specifically includes:

[0049] Step 71: Write the idempotent result payload into the distributed cache with the idempotent key, and set the expiration time according to the lifetime in the idempotent configuration object;

[0050] Step 72: synchronously write the idempotent result payload into the local cache, and set the expiration time of the local cache to half of the lifetime;

[0051] Step 73: After writing is completed, the corresponding distributed lock key is deleted, the lock resource is released, and subsequent concurrent requests are allowed to read the written idempotent result.

[0052] The present invention provides an annotation-driven idempotent processing system, comprising:

[0053] The policy training module 81 is used to collect historical service request records and performance data, iteratively optimize the policy parameter combination using the particle swarm algorithm, generate the final policy vector, and store it in the policy configuration center;

[0054] The metadata generation module 82 is used to intercept the method call marked by the @MethodIdempotent annotation through the AOP aspect, parse the annotation configuration and method parameters, and generate request metadata;

[0055] The policy injection module 83 is used to load the corresponding final policy vector from the policy configuration center according to the business identifier and policy version number in the request metadata, and inject it into the generated idempotent configuration object;

[0056] The cache duplicate detection module 84 is used to generate a business key based on the business parameters in the request metadata and perform hashing on the business key to form an idempotent key;

[0057] According to the local priority policy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a hit is found, the idempotency result in the cache is directly returned; if a hit is not found, the distributed duplicate detection step is entered;

[0058] Business processing module 85 is used to call the original business method during the first processing, obtain the normal return result or exception information, uniformly encapsulate it into an idempotent result payload, write the idempotent result payload into the distributed cache and set a survival time, write it into the local cache and set an expiration time, and release the lock resource;

[0059] The result delivery module 86 is used to construct a processing event including an idempotent key, a processing status, a timestamp, and a performance indicator, send it to a message queue, and return the business result in the idempotent result.

[0060] The beneficial effects of the present invention are as follows: the present invention combines the particle swarm algorithm to adaptively optimize the idempotent policy parameters, significantly improving the flexibility and intelligence level of idempotent processing; by introducing request feature perception and performance data feedback mechanism, it can dynamically adjust key parameters such as lifetime, cache type, lock mode, etc., to achieve optimal policy matching for different business scenarios, effectively reducing the risk of repeated calls and system resource consumption. The idempotent logic is integrated using AOP aspects combined with annotations, which has good versatility and development friendliness, and does not invade the business code logic; at the same time, it combines local and distributed two-layer caching mechanisms, and introduces duplicate judgment granularity control and policy center configuration capabilities, which not only ensures processing consistency but also improves response efficiency. In addition, continuous observation of the idempotent execution effect is achieved through event reporting, providing data support for subsequent policy retraining. Overall, the present invention has the advantages of policy self-optimization capability, efficient operation, strong adaptability, etc., and is suitable for idempotent protection requirements in large-scale distributed services. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 It is a flowchart of an annotation-driven idempotent processing method of the present invention;

[0062] Figure 2 This is a module diagram of an annotation-driven idempotent processing system of the present invention. DETAILED DESCRIPTION

[0063] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed solely to enable those skilled in the art to better understand and implement the subject matter described herein, and that the functions and arrangements of the elements discussed may be varied without departing from the scope of this specification. Various examples may omit, substitute, or add various processes or components as needed. In addition, features described with respect to some examples may also be combined in other examples.

[0064] like Figure 1 As shown in FIG, an annotation-driven idempotent processing method includes the following steps:

[0065] Step 1: Collect historical service request records and performance data, use the particle swarm algorithm to iteratively optimize the policy parameter combination, generate the final policy vector, and store it in the policy configuration center;

[0066] Step 2: intercept the method call marked by the @MethodIdempotent annotation through the AOP aspect, parse the annotation configuration and method parameters, and generate request metadata;

[0067] Step 3: Based on the business identifier and policy version number in the request metadata, load the corresponding final policy vector from the policy configuration center and inject it into the generated idempotent configuration object;

[0068] Step 4: Generate a business key based on the business parameters in the request metadata and hash it to form an idempotent key;

[0069] According to the local priority policy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a hit is found, the idempotency result in the cache is directly returned; if a hit is not found, the distributed duplicate detection step is entered;

[0070] Step 5: During the first processing, the original business method is called to obtain the normal return result or exception information, which is uniformly encapsulated into an idempotent result payload. The idempotent result payload is written to the distributed cache and a lifetime is set. The payload is also written to the local cache and an expiration time is set, and the lock resource is released.

[0071] Step 6: Build a processing event containing the idempotency key, processing status, timestamp, and performance indicators, send it to the message queue, and return the business results in the idempotency result.

[0072] In one embodiment of the present invention, the business request record mainly includes the original request information such as the business identifier, parameter structure, call time, response status, etc. corresponding to each call; the performance data includes performance indicators such as the response delay of request processing, processing success rate, concurrent conflict rate, timeout retry times, cache hit status, etc.; the collection process can be achieved by setting a unified data monitoring and recording module in the service gateway, method call chain or idempotent processing component. The above indicators are captured in real time through the burial method or by using distributed link tracking tools such as Zipkin and SkyWalking, and their structured and persistent storage is in a dedicated database for strategy training for subsequent modeling and optimization.

[0073] In one embodiment of the present invention, the policy parameter combination includes: lifetime, cache type, lock mode, local cache priority switch and maximum retry number; among them, the lifetime is used to control the effective retention time of the idempotent result in the cache; the cache type is used to specify the cache carrier of the idempotent result, including local cache and distributed cache; the lock mode defines how to obtain distributed lock resources during the processing of the first request, including fair lock, unfair lock, spin lock, etc.; the local cache priority switch is used to control whether to prioritize searching for idempotent keys in the local cache; the maximum retry number limits the maximum retry tolerance threshold for the original business method in cases of request conflict or timeout.

[0074] The particle swarm algorithm is used to iteratively optimize the strategy parameter combination to generate the final strategy vector, including:

[0075] Step 11: Collect historical service request records and performance data, and combine policy parameters into a unified numerical code to form a training sample;

[0076] Step 12: Initialize the particle swarm based on the training samples and domain heuristic rules to obtain the initial particle parameter vector and velocity vector;

[0077] Among them, the domain heuristic rules include:

[0078] Set the initial lifetime value to three times the 99th percentile duration of the target business request in the most recent statistical period. This ensures the effectiveness of idempotency judgments in the event of occasional long-duration requests and avoids cache resource waste caused by excessively long lifetimes.

[0079] When the historical local cache hit rate is higher than the hit threshold, the cache type is initialized to local cache; otherwise, it is initialized to distributed cache. This rule directly guides the cache type selection and can reduce invalid cache query overhead.

[0080] When the peak concurrency of requests is less than the concurrency threshold, the lock mode is initialized to a reentrant lock, reducing the performance loss of the locking mechanism itself. When the peak concurrency is not less than the concurrency threshold, the lock mode is initialized to a spin read-write lock, improving the lock contention efficiency in high-concurrency scenarios.

[0081] When the available memory ratio of a node exceeds the memory threshold, the local cache priority switch is initialized to the on state, otherwise it is initialized to the off state, thus achieving a balance between resource utilization and system stability.

[0082] When the historical idempotent conflict rate is greater than the conflict threshold, the maximum number of retries is initialized to one, otherwise it is initialized to zero to reduce unnecessary retry overhead; the above threshold is preset according to the business scenario.

[0083] By applying the above-mentioned domain heuristic rules, the present invention can provide the particle swarm algorithm with an initial parameter vector close to the actual scenario based on business request records, significantly reducing the number of iterative optimization times of the particle swarm algorithm and improving the convergence speed of the strategy parameter combination.

[0084] Step 13: Use the standard particle swarm update formula to update the position and speed of the survival time, and use the probabilistic voting method to update the cache type, lock mode, local cache priority switch, and maximum retry times;

[0085] Specifically, the continuous parameter such as survival time is updated using the standard particle swarm update formula, which is: , ,in, represents the speed of the survival time dimension of the i-th particle at the t+1th iteration, represents the speed of the survival time dimension of the i-th particle at the t-th iteration, Indicates the inertia weight coefficient, ranging from 0.4 to 0.9. represents the optimal position that the i-th particle has reached in the history of the survival time dimension, represents the global optimal position of all particles in the dimension of survival time, and Respectively represent the position of the survival time dimension of the i-th particle at the t-th and t+1-th iterations, and Represents the first learning coefficient and the second learning coefficient, which control the degree to which particles approach the individual optimum and the group optimum. and Indicates a random number between 0 and 1, used to increase the randomness of the search.

[0086] For discrete parameters such as cache type, lock mode, local cache priority switch, and maximum retry count, since they are not continuous, a probabilistic voting mechanism is used to update them. Specifically, after each round of iteration, the distribution probability of the top K% of particles in the particle swarm in terms of fitness in the parameter dimension is counted as the probability basis for selecting the parameter in the next round, thereby improving the adaptability to the discrete strategy space while retaining the heuristic search characteristics.

[0087] Step 14: construct a fitness function based on the weighted throughput rate, conflict rate, and timeout rate, and calculate the fitness of each particle to determine the particle with the highest fitness in the current iteration and the particle with the highest global fitness; wherein the fitness function is: , F represents the fitness of the particle, T represents the system throughput, C represents the request conflict rate, Indicates the timeout rate, 、 and Represent the first weight coefficient, the second weight coefficient and the third weight coefficient respectively.

[0088] Step 15: When the number of iterations reaches the maximum number of iterations, the particle with the largest global fitness is used as the final strategy vector and stored in the strategy configuration center.

[0089] Through the above process, the present invention realizes the automated optimization of policy parameter combinations and can generate the optimal parameter configuration adapted to the business scenario without human intervention. By distinguishing between the update methods of continuous and discrete parameters, the optimization accuracy and efficiency are improved. The fitness function design based on training of actual business data and multi-dimensional performance indicators ensures that the final policy vector can effectively improve the system throughput, reduce the lock conflict rate and timeout rate, and thus significantly enhance the overall performance of idempotent processing.

[0090] In an embodiment of the present application, the method call marked by the @MethodIdempotent annotation is intercepted by the AOP aspect, the annotation configuration and the method argument are parsed, the request metadata is generated, including:

[0091] In step 21, the annotated method is woven into the proxy chain at the application startup to capture the connection point information and thread context at the time of calling; specifically, in the application startup phase, all methods marked by the @MethodIdempotent annotation are woven into the preset proxy chain through bytecode enhancement technology. The proxy chain triggers the interception logic before the target method is actually executed, and captures the connection point information and the current thread context in real time at the time of method calling, providing basic data support for subsequent metadata generation; the connection point information includes target class name, method name, parameter type list, etc., and the current thread context includes calling link identifier, user identity information, etc.

[0092] In step 22, the annotation parameter set is obtained by parsing the annotation configuration, and the SpEL expression, version number and scope information are extracted; wherein the SpEL expression is used to dynamically generate the identification information closely related to the business; the version number is used to specify the policy vector version applicable to the current method, supporting parallel management of multiple version policies; the scope information is used to distinguish different business scenarios to avoid conflicts of idempotent keys across scenarios.

[0093] In step 23, the method argument is collected and serialized into a parameter set, the business identifier is generated by splicing the scope, target class name and method name in the annotation parameter set, and the version identifier is determined combined with the annotation version number, the business identifier, version identifier, parameter set and calling timestamp are merged to obtain the request metadata; wherein the method argument includes basic type parameters and object type parameters; the argument is converted into a structured parameter set through a serialization tool to ensure that the parameter information can be parsed and reused in subsequent steps; at the same time, based on the scope information, target class name and method name in the annotation parameter set, a fixed separator is used to splice and generate a business identifier; combined with the version number extracted in the annotation, a version identifier is generated for accurate matching of the corresponding policy vector.

[0094] Through the above process, the present application realizes non-intrusive interception of business method calls, and completes the extraction and integration of key information without modifying the business code, ensuring the purity of the business logic; through the standardized request metadata generation process, the consistency of information format in different business scenarios and different version policies is ensured, laying a foundation for the standardized execution of subsequent idempotent processing; at the same time, combined with the SpEL expression and dynamic parameter parsing, the metadata can accurately reflect the business characteristics, effectively improving the accuracy and flexibility of idempotent determination.

[0095] In one embodiment of the present invention, based on the service identifier and policy version number in the request metadata, the corresponding final policy vector is loaded from the policy configuration center and injected into the generated idempotent configuration object, including:

[0096] Step 31, concatenate the business identifier and the policy version number into an index key to access the policy configuration center and obtain the matching final policy vector; specifically, use a preset delimiter to concatenate the business identifier and the policy version number into a unique index key, and access the policy configuration center through the index key. The configuration center stores the final policy vector optimized by the particle swarm algorithm in the form of a key-value pair, where the key is the concatenated index key and the value is structured data including the lifetime, cache type, lock mode, local cache priority switch, and maximum number of retries.

[0097] Step 32 , integrity checks are performed on the fields of the final policy vector in sequence. If any field is missing, a fallback is triggered and an alarm is recorded. Triggering the fallback means loading a pre-configured default policy vector corresponding to the service identifier.

[0098] In step 33, according to the field mapping relationship, the lifetime, cache type, lock mode, local cache priority switch and maximum number of retries are respectively injected into the corresponding attributes of the idempotent configuration object to obtain an immutable idempotent configuration object and write it into the call context; wherein, the field mapping relationship refers to a fixed matching rule between the five parameter dimensions in the final strategy vector and the five attribute fields in the idempotent configuration object. After the field values ​​of the final strategy vector are injected into the corresponding attributes of the idempotent configuration object in sequence, the system will call the freeze method of the object to generate an immutable idempotent configuration object to prevent the parameters from being accidentally tampered with in subsequent processes; finally, the thread context of the current call is written so that the configuration can be directly accessed in subsequent steps such as local duplicate detection, distributed lock acquisition, and result persistence.

[0099] Through the above process, the present invention achieves precise matching of policy vectors and business calls, ensuring that policy parameters in different business scenarios and different versions can be correctly applied; the combination of field integrity verification and fallback mechanism effectively reduces the risk of system failure caused by abnormal policy configuration; the design of immutable configuration objects ensures the consistency and security of parameters in the execution chain.

[0100] In one embodiment of the present invention, a business key is generated based on the business parameters in the request metadata, and hashed to form an idempotent key, including:

[0101] Step 41, evaluate the parameter set in the request metadata according to the expression specified in the annotation to obtain the original business parameter string and perform unified coding and normalization to generate a business key; specifically, for the parameter set contained in the request metadata, dynamically evaluate according to the SpEL expression specified in the @MethodIdempotent annotation. For example, when the expression configured by the annotation is "#orderId+':'+ #userId", the system will extract the actual values ​​corresponding to "orderId" and "userId" from the parameter set and splice them into the original business parameter string. Subsequently, the original business parameter string is subjected to unified coding and normalization processing, including removing the leading and trailing spaces, converting to lowercase letters, standardizing the date format, etc., and finally generating a business key with a unified format to ensure that parameter combinations with the same business meaning can be mapped to the same business key.

[0102] In step 42, a SHA-256 hash operation is performed on the business key to obtain a hash value, and the fixed prefix is ​​concatenated with the hash value to obtain an idempotent key. The hash value is unique, which can effectively avoid storage efficiency problems caused by overly long business keys and reduce the probability of key value conflicts. The fixed prefix is ​​used to distinguish different types of key values ​​in the cache to avoid conflicts with cache keys of other businesses.

[0103] Step 43, calculate the CRC32 check code for the idempotent key and record it in the monitoring event stream; the CRC32 check code is a 32-bit integer that can quickly verify whether the idempotent key has been tampered with during transmission or storage.

[0104] Step 44: When the length of the business key exceeds the preset threshold, the downgrade strategy is triggered and an alarm is output. Specifically, the system monitors the length of the business key in real time. When the length of the business key exceeds the preset threshold, the downgrade strategy is immediately triggered: stop using the current business key to generate the idempotent key, and instead use only core parameters to generate an alternative business key, and output an alarm message through the monitoring interface.

[0105] Through the above process, the present invention realizes the standardized mapping of business parameters to idempotence keys, ensuring that the same business request can be accurately identified as a duplicate request in different calling scenarios; the SHA-256 hash operation not only guarantees the uniqueness of the idempotence key, but also optimizes the cache storage efficiency; the combination of CRC32 checksum and monitoring event stream improves the observability and fault tolerance of the system; and the degradation strategy provides a guarantee for system stability in extreme scenarios.

[0106] In one embodiment of the present invention, duplicate detection in the local cache and returning the result according to the local priority policy and cache type set in the idempotent configuration object include:

[0107] Step 51: When the local cache priority switch is on and the cache type is local cache, the idempotent key is used to query the corresponding idempotent result in the local cache; the idempotent result includes the business processing result, call count, generation time, etc.

[0108] Step 52: If an idempotent result is found, the remaining lifetime of the idempotent result is compared with the lifetime threshold. When the remaining lifetime is greater than the lifetime threshold, the idempotent result is directly returned to the caller, and the local hit index is reported; wherein, the remaining lifetime is obtained by adding the idempotent result generation time to the lifetime time minus the current time, representing the length of time that the result is still valid in the cache; the local hit index includes the idempotent key, hit time, remaining lifetime, etc.

[0109] Step 53: If no idempotent result is found, or the remaining lifetime is not greater than the lifetime threshold, a miss signal is output and the distributed duplicate detection step is entered. The specific steps include:

[0110] Step 61, according to the lock mode specified by the idempotent configuration object, obtain a distributed lock with the idempotent key in the distributed cache system; specifically, if the lock mode is a reentrant lock, try to obtain an exclusive lock with automatic expiration characteristics through the "SET key value NX PX timeout" command, where the "NX" parameter ensures that the lock will be created only when it does not exist, and the "PXtimeout" parameter sets the lock timeout time to avoid lock resource leakage; if the lock mode is a spin read-write lock, the read-write separation lock mechanism is implemented through the Redis Hash structure, read requests share the lock, and write requests obtain exclusive locks, reducing the lock competition overhead in high-concurrency read scenarios.

[0111] Step 62: If the lock is acquired successfully, query whether the distributed cache has stored the historical idempotent result. If found, return the historical idempotent result to the caller. The query operation is implemented through the "GET key" command of the distributed cache.

[0112] In step 63, if no historical idempotent result is found, the business method is executed, the business result is written to the distributed cache, and the distributed lock is released. Specifically, if no historical idempotent result is found in the distributed cache, indicating that this business request is being processed for the first time, the system will call the original business method to execute the core logic, obtain the business processing result, and encapsulate it as an idempotent result. Subsequently, the idempotent result is written to the distributed cache using the "SET key value EX ttl" command. The "EX ttl" parameter sets an expiration time that is consistent with the lifetime in the idempotent configuration object to ensure automatic cache cleanup. After writing is complete, the system actively releases the distributed lock using the "DEL key" command to avoid concurrent blocking caused by holding the lock for too long.

[0113] Step 64: If the lock acquisition fails, wait for the distributed lock to be released and return the idempotent result in the distributed cache. Specifically, if the distributed lock acquisition fails, it indicates that other nodes are processing the business request corresponding to the same idempotent key, and the system enters a waiting state. The waiting mechanism is dynamically adjusted according to the lock mode: for reentrant locks, a spin-retry strategy with a fixed interval is adopted until the lock is released or the maximum number of retries is reached; for spin read-write locks, a callback notification is triggered when the lock is released by subscribing to Redis's key space notification, reducing invalid spin overhead. When the lock is released, the system immediately queries the idempotent result generated in the distributed cache and returns it to the caller to ensure that all concurrent requests ultimately obtain consistent processing results.

[0114] Through the above process, the present invention realizes the refined control of local cache duplicate detection, and enables local query only in scenarios permitted by the policy. It fully utilizes the low latency characteristics of the local cache and ensures the validity of the results through the remaining lifetime verification; for misses or expiration cases, the distributed duplicate detection process is seamlessly connected to ensure the accuracy and completeness of idempotent judgments.

[0115] In one embodiment of the present invention, step 5 specifically includes:

[0116] Step 71, write the idempotent result payload into the distributed cache with the idempotent key, and set the expiration time according to the lifetime in the idempotent configuration object; specifically, when neither the local cache nor the distributed cache hits a valid idempotent result, it is determined that the current business request is processed for the first time, and the original business method is called to execute the core logic; during the execution process, the system will capture the normal return result or exception information of the method, and uniformly encapsulate this information into an idempotent result payload; the payload contains the business result field, call count, processing timestamp, etc.

[0117] In step 72, the idempotent result payload is synchronously written to the local cache, and the expiration time of the local cache is set to half of the lifetime; through a shorter local cache expiration time, the risk of dirty data caused by the local cache not being updated in time is reduced, ensuring that after the distributed cache result is updated, the local cache can synchronize the latest data faster.

[0118] Step 73: After writing is completed, the corresponding distributed lock key is deleted, the lock resource is released, and subsequent concurrent requests are allowed to read the written idempotent result; thereby avoiding concurrent blocking caused by long-term lock occupation and improving the collaborative processing efficiency of the system.

[0119] In this embodiment, distributed caching ensures the consistency of results across nodes, and local caching improves the response speed of repeated requests to the same node; differentiated expiration time settings ensure data freshness while taking performance into account; and active release of lock resources minimizes concurrent blocking and improves system throughput.

[0120] In one embodiment of the present invention, after completing the cache writing of the idempotent result and releasing the lock resources, the system automatically triggers the construction process of the processing event including the idempotent key, processing status, timestamp and performance indicators; wherein, the idempotent key is used to associate the event with the specific processing object; the processing status clarifies the processing result type of the current request through the enumeration value; the timestamp is used to accurately record the moment when the event is generated; the performance indicators cover key performance data such as the full link time from request interception to result cache, cache query time, lock waiting time, etc. Subsequently, the system sends the processing event to the specified message queue topic through the preset message queue client; after the event is sent, the system extracts the business result field from the idempotent result payload, converts it according to the return value format of the original business method, and returns it directly to the caller; the above process realizes the full observability of the idempotent processing link.

[0121] like Figure 2 As shown, this embodiment also provides an annotation-driven idempotent processing system, including:

[0122] The policy training module 81 is used to collect historical service request records and performance data, iteratively optimize the policy parameter combination using the particle swarm algorithm, generate the final policy vector, and store it in the policy configuration center;

[0123] The metadata generation module 82 is used to intercept the method call marked by the @MethodIdempotent annotation through the AOP aspect, parse the annotation configuration and method parameters, and generate request metadata;

[0124] The policy injection module 83 is used to load the corresponding final policy vector from the policy configuration center according to the business identifier and policy version number in the request metadata, and inject it into the generated idempotent configuration object;

[0125] The cache duplicate detection module 84 is used to generate a business key based on the business parameters in the request metadata and perform hashing on the business key to form an idempotent key;

[0126] According to the local priority policy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a hit is found, the idempotency result in the cache is directly returned; if a hit is not found, the distributed duplicate detection step is entered;

[0127] Business processing module 85 is used to call the original business method during the first processing, obtain the normal return result or exception information, uniformly encapsulate it into an idempotent result payload, write the idempotent result payload into the distributed cache and set a survival time, write it into the local cache and set an expiration time, and release the lock resource;

[0128] The result delivery module 86 is used to construct a processing event including an idempotent key, a processing status, a timestamp, and a performance indicator, send it to a message queue, and return the business result in the idempotent result.

[0129] It should be noted that the intervals and thresholds are set for ease of comparison. The threshold size depends on the amount of sample data and the cardinality set by those skilled in the art for each set of sample data, as long as it does not affect the proportional relationship between the parameter and the quantized value. Furthermore, the above formulas are all dimensionless numerical calculations. These formulas are derived from software simulations of the most recent real-world conditions using large amounts of data. The preset parameters in these formulas are set by those skilled in the art based on actual conditions.

[0130] The above describes the embodiments of the present invention, but the present invention is not limited to the above specific implementation methods. The above specific implementation methods are merely illustrative and not restrictive. Ordinary technicians in this field can also make many forms based on the inspiration of this embodiment, all of which are protected by this embodiment.

Claims

1. An annotation-driven idempotent processing method, characterized in that: The following steps are involved: Step 1: Collect historical service request records and performance data, use the particle swarm algorithm to iteratively optimize the policy parameter combination, generate the final policy vector, and store it in the policy configuration center; Step 2: intercept the method call marked by the @MethodIdempotent annotation through the AOP aspect, parse the annotation configuration and method parameters, and generate request metadata; Step 3: Based on the business identifier and policy version number in the request metadata, load the corresponding final policy vector from the policy configuration center and inject it into the generated idempotent configuration object; Step 4: Generate a business key based on the business parameters in the request metadata and hash it to form an idempotent key; According to the local priority policy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a hit is found, the idempotency result in the cache is directly returned; if a hit is not found, the distributed duplicate detection step is entered; Step 5: During the first processing, the original business method is called to obtain the normal return result or exception information, which is uniformly encapsulated into an idempotent result payload. The idempotent result payload is written to the distributed cache and a lifetime is set. The payload is also written to the local cache and an expiration time is set, and the lock resource is released. Step 6: Build a processing event containing the idempotency key, processing status, timestamp, and performance indicators, send it to the message queue, and return the business results in the idempotency result.

2. The annotation-driven idempotent processing method according to claim 1, characterized in that: The policy parameter combination includes: lifetime, cache type, lock mode, local cache priority switch, and maximum number of retries; The particle swarm algorithm is used to iteratively optimize the strategy parameter combination to generate the final strategy vector, including: Step 11: Collect historical service request records and performance data, and combine policy parameters into a unified numerical code to form a training sample; Step 12: Initialize the particle swarm based on the training samples and domain heuristic rules to obtain the initial particle parameter vector and velocity vector; Step 13: Use the standard particle swarm update formula to update the position and speed of the survival time, and use the probabilistic voting method to update the cache type, lock mode, local cache priority switch, and maximum retry times; Step 14: construct a fitness function based on the weighted throughput rate, conflict rate, and timeout rate, and calculate the fitness of each particle to determine the particle with the highest fitness in the current iteration and the particle with the highest global fitness; Step 15: When the number of iterations reaches the maximum number of iterations, the particle with the largest global fitness is used as the final strategy vector and stored in the strategy configuration center.

3. The annotation-driven idempotent processing method according to claim 2, characterized in that: The domain heuristic rules include: Set the initial lifetime value to three times the 99th percentile duration of the target service request in the most recent statistical period. When the historical local cache hit rate is higher than the hit threshold, the cache type is initialized to local cache, otherwise it is initialized to distributed cache; When the peak concurrency of requests is less than the concurrency threshold, the lock mode is initialized to a reentrant lock. When the peak concurrency is not less than the concurrency threshold, it is initialized to a spin read-write lock. When the available memory ratio of the node exceeds the memory threshold, the local cache priority switch is initialized to the on state, otherwise it is initialized to the off state; When the historical idempotent conflict rate is greater than the conflict threshold, the maximum number of retries is initialized to one, otherwise it is initialized to zero.

4. The annotation-driven idempotent processing method according to claim 1, characterized in that: The AOP aspect intercepts method calls marked with the @MethodIdempotent annotation, parses the annotation configuration and method arguments, and generates request metadata, including: Step 21: Weave the annotated method into the proxy chain when the application starts, and capture the connection point information and thread context during the call; Step 22: Parse the annotation configuration to obtain the annotation parameter set, extract the SpEL expression, version number, and scope information; Step 23: Collect method parameters and serialize them into a parameter set. Generate a business identifier based on the scope, target class name, and method name in the annotation parameter set. Determine the version identifier in combination with the annotation version number. Merge the business identifier, version identifier, parameter set, and call timestamp to obtain request metadata.

5. The annotation-driven idempotent processing method according to claim 4, characterized in that: Based on the business identifier and policy version number in the request metadata, the corresponding final policy vector is loaded from the policy configuration center and injected into the generated idempotent configuration object, including: Step 31: Concatenate the service identifier and the policy version number as an index key to access the policy configuration center and obtain the matching final policy vector; Step 32: perform integrity checks on the fields of the final policy vector in sequence. If any field is missing, a rollback is triggered and an alarm is recorded. In step 33, based on the field mapping relationship, the lifetime, cache type, lock mode, local cache priority switch, and maximum number of retries are injected into the corresponding attributes of the idempotent configuration object to obtain an immutable idempotent configuration object and write it into the call context.

6. The annotation-driven idempotent processing method according to claim 1, characterized in that: Generate a business key based on the business parameters in the request metadata and hash it to form an idempotent key, including: Step 41: Evaluate the parameter set in the request metadata according to the expression specified in the annotation to obtain the original business parameter string and perform unified encoding and normalization to generate a business key; Step 42: Perform a SHA-256 hash operation on the business key to obtain a hash value, and concatenate the fixed prefix and the hash value to obtain an idempotent key; Step 43: Calculate the CRC32 checksum for the idempotent key and record it in the monitoring event stream; Step 44: When the service key length exceeds a preset threshold, a degradation strategy is triggered and an alarm is output.

7. The annotation-driven idempotent processing method according to claim 1, characterized in that: The local cache is checked for duplicates based on the local priority policy and cache type specified in the idempotence configuration object and the results are returned, including: Step 51: When the local cache priority switch is on and the cache type is local cache, query the local cache for the corresponding idempotent result using the idempotent key; Step 52: If an idempotent result is found, the remaining lifetime of the idempotent result is compared with the lifetime threshold. If the remaining lifetime is greater than the lifetime threshold, the idempotent result is directly returned to the caller and a local hit indicator is reported. Step 53: If no idempotent result is found, or the remaining lifetime is not greater than the lifetime threshold, a miss signal is output and the distributed duplicate detection step is entered.

8. The annotation-driven idempotent processing method according to claim 7, characterized in that: The distributed duplicate checking step includes: Step 61: Acquire a distributed lock with the idempotent key in the distributed cache system according to the lock mode specified by the idempotent configuration object; Step 62: If the lock is acquired successfully, query whether the distributed cache has stored the historical idempotency result. If found, return the historical idempotency result to the caller. Step 63: If no historical idempotent result is found, the business method is executed and the business result is written into the distributed cache, and then the distributed lock is released; Step 64: If the lock acquisition fails, wait for the distributed lock to be released and return the idempotent result in the distributed cache.

9. The annotation-driven idempotent processing method according to claim 1, characterized in that: The step 5 specifically includes: Step 71: Write the idempotent result payload into the distributed cache with the idempotent key, and set the expiration time according to the lifetime in the idempotent configuration object; Step 72: synchronously write the idempotent result payload into the local cache, and set the expiration time of the local cache to half of the lifetime; Step 73: After writing is completed, the corresponding distributed lock key is deleted, the lock resource is released, and subsequent concurrent requests are allowed to read the written idempotent result.

10. An annotation-driven idempotent processing system, characterized in that: An annotation-driven idempotent processing method according to any one of claims 1 to 9 is adopted, comprising: A strategy training module (81) is used to collect business request records and performance data of historical calls, iteratively optimize the strategy parameter combination using a particle swarm algorithm, generate a final strategy vector, and store it in a strategy configuration center; Metadata generation module (82), used to intercept method calls marked by @MethodIdempotent annotation through AOP aspect, parse annotation configuration and method parameters, and generate request metadata; A policy injection module (83) is used to load the corresponding final policy vector from the policy configuration center according to the business identifier and policy version number in the request metadata, and inject it to generate an idempotent configuration object; A cache duplicate detection module (84) is used to generate a business key based on the business parameters in the request metadata and perform hashing on the business key to form an idempotent key; According to the local priority policy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a hit is found, the idempotency result in the cache is directly returned; if a hit is not found, the distributed duplicate detection step is entered; The business processing module (85) is used to call the original business method during the first processing, obtain the normal return result or exception information, uniformly encapsulate it into an idempotent result payload, write the idempotent result payload into the distributed cache and set the survival time, write it into the local cache and set the expiration time, and release the lock resource; The result delivery module (86) is used to construct a processing event containing an idempotent key, a processing status, a timestamp, and a performance indicator, send it to a message queue, and return the business result in the idempotent result.

Images