An annotation-driven idempotency processing method and system

Abstract

This invention relates to the field of idempotency processing technology and discloses an annotation-driven idempotency processing method and system, comprising the following steps: Step 1, collecting historical business request records and performance data, optimizing the strategy parameter combination using a particle swarm optimization algorithm, and generating a final strategy vector; Step 2, intercepting method calls marked with annotations, parsing the annotations and method parameters, and generating request metadata; Step 3, loading the final strategy vector based on the business identifier and strategy version number, and generating an idempotency configuration object; Step 4, generating an idempotency key based on business parameters, prioritizing searching in the local cache, returning directly if a match is found, otherwise proceeding to distributed deduplication; Step 5, calling the original method during the first processing, encapsulating the idempotency result payload, writing it to the cache, and releasing the lock; Step 6, constructing a processing event, sending it to a message queue, and returning the business result from the idempotency result. This invention achieves intelligent configuration and efficient execution of idempotency processing in multiple scenarios.

Description

Technical Field

[0001] This invention belongs to the field of idempotency processing technology, specifically relating to an annotation-driven idempotency processing method and system. Background Technology

[0002] As internet business system architectures become increasingly complex, distributed deployment and microservices have become mainstream. Business systems face increasingly serious issues with duplicate requests in complex scenarios such as high concurrency, cross-node operations, and network jitter. For example, user requests may time out due to network jitter, triggering retries, or service node failures may cause duplicate message delivery. If the system lacks an effective idempotency guarantee mechanism, this could lead to serious consequences such as duplicate order creation, duplicate deductions from account balances, and abnormal inventory reductions. Therefore, idempotency processing capabilities have become a key technical means to ensure business data consistency and system stability.

[0003] In existing technologies, idempotency processing typically relies on fixed parameters as idempotency keys for request deduplication, caching the results locally or in a distributed manner. Subsequent requests then use the idempotency key to determine if they are duplicate calls. Some solutions integrate idempotency logic into business code using annotation configuration, but this approach lacks configuration flexibility and adaptability to different business scenarios, potentially leading to resource waste or failures. Furthermore, traditional idempotency strategies are mostly statically configured, making it difficult to dynamically adjust parameter combinations based on actual business request characteristics. This hinders the ability to balance multiple performance metrics such as throughput, conflict rate, and response latency, limiting the widespread adoption and application of idempotency solutions in complex systems. Summary of the Invention

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

[0005] This invention provides an annotation-driven idempotency processing method, comprising the following steps:

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

[0007] Step 2: Intercept method calls marked with the @MethodIdempotent annotation using AOP aspects, parse the annotation configuration and method parameters, and generate request metadata;

[0008] 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 to generate 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] Based on the local priority strategy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a match is found, the idempotency result in the cache is returned directly; otherwise, the distributed deduplication step is initiated.

[0011] Step 5: During the initial processing, call the original business method to obtain the normal return result or the exception information, encapsulate it into an idempotent result payload, write the idempotent result payload to the distributed cache and set its time-to-live, write it to the local cache and set its expiration time, and release the lock resources.

[0012] Step 6: Construct a processing event containing an idempotent key, processing status, timestamp, and performance metrics, send it to the message queue, and return the business result from the idempotent result.

[0013] Furthermore, the strategy parameter combinations include: time to live, cache type, lock mode, local cache priority switch, and maximum number of retries;

[0014] The particle swarm optimization algorithm is used to iteratively optimize the combination of policy parameters, generating the final policy vector, including:

[0015] Step 11: Collect historical business request records and performance data, and encode the strategy parameter combinations into unified numerical values ​​to form training samples;

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

[0017] Step 13: Update the position and velocity using the standard particle swarm update formula for the survival time, and update the cache type, lock mode, local cache priority switch and maximum number of retries using the probability voting method.

[0018] Step 14: Construct a fitness function by weighting the throughput, conflict rate and timeout rate, and calculate the fitness for 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 highest global fitness is taken as the final policy vector and stored in the policy configuration center.

[0020] Furthermore, the domain heuristic rules include:

[0021] The initial value for the lifetime is set to three times the time taken by the 99th percentile of the target business requests 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 to local cache; otherwise, it is initialized to distributed cache.

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

[0024] When the available memory percentage of a node is higher than the memory threshold, the local cache priority switch is initialized to the enabled state; otherwise, it is initialized to the disabled state.

[0025] 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.

[0026] Furthermore, by intercepting method calls annotated with `@MethodIdempotent` through AOP aspects, the annotation configuration and method arguments are parsed to generate request metadata, including:

[0027] Step 21: The annotated method is woven into the proxy chain when the application starts, capturing the join point information and thread context at the time of the call;

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

[0029] Step 23: Collect method arguments and serialize them into a parameter set. Generate a business identifier by concatenating the scope, target class name and method name in the annotation parameter set. Determine the version identifier by combining the annotation version number. Merge the business identifier, version identifier, parameter set and call timestamp to obtain request metadata.

[0030] Furthermore, 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 to generate an idempotent configuration object, including:

[0031] 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;

[0032] Step 32: Perform integrity checks on the fields of the final strategy vector in sequence. If any field is missing, a rollback will be triggered and an alarm will be recorded.

[0033] Step 33: Based on the field mapping relationship, inject the time to live, cache type, lock mode, local cache priority switch and maximum number of retries into the corresponding properties of the idempotent configuration object to obtain an immutable idempotent configuration object, and write it into the call context.

[0034] Furthermore, a business key is generated based on the business parameters in the request metadata, and then hashed 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 SHA-256 hash operation on the business key to obtain the hash value, and concatenate the fixed prefix with the hash value to obtain the idempotent key;

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

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

[0039] Furthermore, based on the local priority strategy and cache type set in the idempotent configuration object, deduplication is performed in the local cache and the results are returned, including:

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

[0041] Step 52: If an idempotent result is found, compare the remaining lifetime of the idempotent result with the lifetime threshold. If the remaining lifetime is greater than the lifetime threshold, return the idempotent result directly to the caller and report the local hit index.

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

[0043] Furthermore, the distributed deduplication step includes:

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

[0045] Step 62: If the lock is successfully acquired, check if the historical idempotent result has been stored in the distributed cache. If found, return the historical idempotent result to the caller.

[0046] Step 63: If no historical idempotent result is found, execute the business method, write the business result to the distributed cache, and then release the distributed lock.

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

[0048] Furthermore, step 5 specifically includes:

[0049] Step 71: Write the idempotent result payload into the distributed cache with an idempotent key, and set the expiration time according to the time-to-live 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 complete, delete the corresponding distributed lock key, release the lock resource, and allow subsequent concurrent requests to read the written idempotent result.

[0052] This invention provides an annotation-driven idempotency processing system, comprising:

[0053] The strategy training module 81 is used to collect historical business request records and performance data, use the particle swarm algorithm to iteratively optimize the combination of strategy parameters, generate the final strategy vector, and store it in the strategy configuration center.

[0054] Metadata generation module 82 is used to intercept method calls marked with the @MethodIdempotent annotation through AOP aspects, parse the annotation configuration and method parameters, and generate request metadata;

[0055] The strategy injection module 83 is used to load the corresponding final strategy vector from the strategy configuration center based on the business identifier and strategy version number in the request metadata, and inject it to generate an idempotent configuration object.

[0056] The cache deduplication module 84 is used to generate business keys based on business parameters in the request metadata and to perform hash processing to form idempotent keys.

[0057] Based on the local priority strategy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a match is found, the idempotency result in the cache is returned directly; otherwise, the distributed deduplication step is initiated.

[0058] The business processing module 85 is used to call the original business method during the first processing, obtain the normal return result or the exception information, encapsulate it into an idempotent result payload, write the idempotent result payload to the distributed cache and set the time-to-live, write it to the local cache and set the expiration time, and release the lock resources.

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

[0060] The beneficial effects of this invention are as follows: This invention combines particle swarm optimization (PSO) to adaptively optimize idempotency policy parameters, significantly improving the flexibility and intelligence of idempotency processing. By introducing request feature awareness and performance data feedback mechanisms, it can dynamically adjust key parameters such as lifetime, cache type, and lock mode, achieving optimal policy matching for different business scenarios and effectively reducing the risk of repeated calls and system resource consumption. The idempotency logic is integrated using AOP aspects combined with annotations, possessing good versatility and developer friendliness without intruding on business code logic. Simultaneously, it combines local and distributed dual-layer caching mechanisms and introduces deduplication granularity control and policy center configuration capabilities, ensuring processing consistency while improving response efficiency. Furthermore, continuous observation of the idempotency execution effect is achieved through event reporting, providing data support for subsequent policy retraining. Overall, this invention possesses advantages such as policy self-optimization capabilities, high operational efficiency, and strong adaptability, making it suitable for idempotency guarantee requirements in large-scale distributed services. Attached Figure Description

[0061] Figure 1 This is a flowchart of an annotation-driven idempotency processing method according to the present invention;

[0062] Figure 2 This is a schematic diagram of a module of an annotation-driven idempotent processing system according to the present invention. Detailed Implementation

[0063] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

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

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

[0066] Step 2: Intercept method calls marked with the @MethodIdempotent annotation using AOP aspects, 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 to generate an 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] Based on the local priority strategy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a match is found, the idempotency result in the cache is returned directly; otherwise, the distributed deduplication step is initiated.

[0070] Step 5: During the initial processing, call the original business method to obtain the normal return result or the exception information, encapsulate it into an idempotent result payload, write the idempotent result payload to the distributed cache and set its time-to-live, write it to the local cache and set its expiration time, and release the lock resources.

[0071] Step 6: Construct a processing event containing an idempotent key, processing status, timestamp, and performance metrics, send it to the message queue, and return the business result from the idempotent result.

[0072] In one embodiment of the present invention, the business request record mainly includes original request information such as the business identifier, parameter structure, call time, and response status corresponding to each call; the performance data includes performance indicators such as response latency, processing success rate, concurrency conflict rate, timeout retries, and cache hit rate; the collection process can be implemented by setting a unified data listening and recording module in the service gateway, method call chain, or idempotent processing component. The above indicators are captured in real time through instrumentation or by using distributed tracing tools such as Zipkin and SkyWalking, and then stored in a structured and persistent database for strategy training for subsequent modeling and optimization.

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

[0074] The particle swarm optimization algorithm is used to iteratively optimize the combination of policy parameters, generating the final policy vector, including:

[0075] Step 11: Collect historical business request records and performance data, and encode the strategy parameter combinations into unified numerical values ​​to form training samples;

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

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

[0078] The initial value of the time-to-live (TTL) is set to three times the time taken by the 99th percentile of the target business requests in the most recent statistical period; this ensures the effectiveness of idempotency determination under occasional long-running requests and avoids wasting cache resources due to excessively long TTLs.

[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 choice of cache type and can reduce the overhead of invalid cache queries.

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

[0081] When the available memory percentage of a node is higher than 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 aforementioned domain-inspired rules, this invention can provide an initial parameter vector for the particle swarm optimization algorithm that closely resembles the actual scenario based on business request records, significantly reducing the number of iterations in the particle swarm optimization algorithm and improving the convergence speed of the strategy parameter combination.

[0084] Step 13: Update the position and velocity using the standard particle swarm update formula for the survival time, and update the cache type, lock mode, local cache priority switch and maximum number of retries using the probability voting method.

[0085] Specifically, for continuous parameters such as survival time, the standard particle swarm optimization (PSO) update formula is used for updating. The standard PSO update formula is as follows: , ,in, This represents the velocity of the i-th particle in the (t+1)-th iteration, in the dimension of its survival time. This represents the velocity of the i-th particle in the survival time dimension during the t-th iteration. This represents the inertia weighting coefficient, with a value ranging from 0.4 to 0.9. This represents the optimal position reached by the i-th particle in the dimension of its historical survival time. This represents the globally optimal position of all particles in the lifetime dimension. and These represent the positions of the i-th particle in the survival time dimension at the t-th and t+1-th iterations, respectively. and These represent the first and second learning coefficients, which control the degree to which particles approach their individual and group optimum. and This represents a random number in the range of 0 to 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 number of retries, since they are not continuous, a probabilistic voting mechanism is used for updating. Specifically, after each iteration, the distribution probability of the top K% of the particles in the particle swarm in terms of fitness is calculated as the probability basis for selecting the parameter in the next round, thereby improving the adaptability to the discrete strategy space while retaining the characteristics of heuristic search.

[0087] Step 14: Construct a fitness function based on a weighted average of throughput, collision rate, and timeout rate; calculate the fitness for each particle; and determine the particle with the highest fitness in the current iteration and the particle with the highest global fitness. The fitness function is: F represents the particle's fitness, T represents the system throughput, and C represents the request collision rate. Indicates the timeout rate. , and These represent the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient, respectively.

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

[0089] Through the above process, this invention achieves automated optimization of strategy parameter combinations, generating optimal parameter configurations suitable for business scenarios without manual intervention; by distinguishing between continuous and discrete parameter update methods, it improves optimization accuracy and efficiency; and by training based on actual business data and designing a fitness function with multi-dimensional performance indicators, it ensures that the final strategy vector can effectively improve the system's throughput, reduce lock conflict rate and timeout rate, thereby significantly enhancing the overall performance of idempotent processing.

[0090] In one embodiment of the present invention, method calls marked with the @MethodIdempotent annotation are intercepted through AOP aspects, the annotation configuration and method arguments are parsed, and request metadata is generated, including:

[0091] Step 21 involves weaving the annotated methods into a proxy chain during application startup to capture join point information and thread context during invocation. Specifically, during application startup, bytecode enhancement technology is used to weave all methods annotated with `@MethodIdempotent` into a pre-defined proxy chain. The proxy chain triggers interception logic before the target method is actually executed, capturing join point information and the current thread context during method invocation in real time, providing basic data support for subsequent metadata generation. Join point information includes the target class name, method name, parameter type list, etc., while the current thread context includes the call chain identifier, user identity information, etc.

[0092] Step 22: Parse the annotation configuration to obtain the annotation parameter set, and extract the SpEL expression, version number, and scope information. Among them, the SpEL expression is used to dynamically generate identification information that is strongly associated with the business; the version number is used to specify the strategy vector version applicable to the current method, supporting parallel management of multiple version strategies; the scope information is used to distinguish different business scenarios and avoid idempotent key conflicts across scenarios.

[0093] Step 23: Collect method arguments and serialize them into a parameter set. Generate a business identifier by concatenating the scope, target class name, and method name from the annotation parameter set. Determine the version identifier by combining this with the annotation version number. Merge the business identifier, version identifier, parameter set, and call timestamp to obtain request metadata. The method arguments include basic type parameters and object type parameters. A serialization tool converts the arguments into a structured parameter set, ensuring that the parameter information can be parsed and reused in subsequent steps. Simultaneously, based on the scope information, target class name, and method name from the annotation parameter set, a business identifier is generated by concatenating them using a fixed separator. Combined with the version number extracted from the annotation, a version identifier is generated for accurate matching of the corresponding strategy vector.

[0094] Through the above process, this invention achieves non-intrusive interception of business method calls, extracting and integrating key information without modifying business code, thus ensuring the purity of business logic. A standardized request metadata generation process ensures consistency in information format across different business scenarios and version strategies, laying the foundation for standardized execution of subsequent idempotency processing. Furthermore, by combining SpEL expressions and dynamic parameter parsing, metadata accurately reflects business characteristics, effectively improving the accuracy and flexibility of idempotency determination.

[0095] In one embodiment of the present invention, 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 to generate an 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 this index key. The configuration center stores the final policy vector optimized by the particle swarm algorithm in key-value pairs, where the key is the concatenated index key and the value is structured data containing time to live, cache type, lock mode, local cache priority switch and maximum number of retries.

[0097] 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. Triggering a rollback means loading the pre-configured default policy vector corresponding to the service identifier.

[0098] Step 33: Based on the field mapping relationship, inject the time-to-live, cache type, lock mode, local cache priority switch, and maximum retry count into the corresponding attributes of the idempotent configuration object to obtain an immutable idempotent configuration object, and write it into the call context. Here, the field mapping relationship refers to the fixed matching rule that corresponds one-to-one between the five parameter dimensions in the final policy vector and the five attribute fields in the idempotent configuration object. After injecting the field values ​​of the final policy vector into the corresponding attributes of the idempotent configuration object in sequence, the system will call the object's freeze method to generate an immutable idempotent configuration object to prevent the parameters from being accidentally tampered with in subsequent processes. Finally, write it into the current calling thread context so that the configuration can be directly accessed in subsequent steps such as local deduplication, distributed lock acquisition, and result persistence.

[0099] Through the above process, this invention achieves precise matching between policy vectors and business calls, ensuring that policy parameters for different business scenarios and versions can be correctly applied; the combination of field integrity verification and rollback mechanism effectively reduces the risk of system failure caused by abnormal policy configuration; and 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 business parameters in the request metadata, and then hashed to form an idempotent key, including:

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

[0102] Step 42: Perform SHA-256 hash operation on the business key to obtain a hash value, and concatenate the fixed prefix with the hash value to obtain an idempotent key; the hash value is unique, which can effectively avoid storage efficiency problems caused by excessively long business keys, and at the same time reduce the probability of key-value conflicts; the fixed prefix is ​​used to distinguish different types of key-values ​​in the cache and avoid conflicts with cache keys of other businesses.

[0103] Step 43: Calculate the CRC32 checksum for the idempotent key and record it to the monitoring event stream; the CRC32 checksum is a 32-bit integer, which 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, a degradation strategy is triggered and an alarm is output. Specifically, the system will monitor the length of the business key in real time. When the length of the business key exceeds the preset threshold, a degradation strategy will be triggered immediately: stop using the current business key to generate idempotent keys, and instead use the method of generating alternative business keys by retaining only the core parameters, and output alarm information through the monitoring interface.

[0105] Through the above process, this invention achieves a standardized mapping of business parameters to idempotent keys, ensuring that the same business request can be accurately identified as a duplicate request in different calling scenarios; SHA-256 hash operation not only guarantees the uniqueness of idempotent keys, but also optimizes 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, deduplication in the local cache based on the local priority strategy and cache type set in the idempotent configuration object and returning the result includes:

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

[0108] Step 52: If an idempotent result is found, compare the remaining lifetime of the idempotent result with the lifetime threshold. If the remaining lifetime is greater than the lifetime threshold, return the idempotent result directly to the caller and report the local hit index. The remaining lifetime is obtained by adding the lifetime to the idempotent result generation time and subtracting the current time, representing the duration the result is still valid in the cache. The local hit index includes the idempotent key, hit time, and remaining lifetime.

[0109] Step 53: If no idempotent result is found, or the remaining lifetime is not greater than the lifetime threshold, output a miss signal and proceed to the distributed deduplication step; the specific steps include:

[0110] Step 61: According to the lock mode specified by the idempotent configuration object, acquire a distributed lock in the distributed cache system using the idempotent key. Specifically, if the lock mode is a reentrant lock, attempt to acquire an exclusive lock with automatic expiration using the "SET key value NX PX timeout" command. The "NX" parameter ensures that the lock will only be created if it does not exist, and the "PXtimeout" parameter sets the lock's timeout to avoid lock resource leakage. If the lock mode is a spin read-write lock, implement a read-write separation lock mechanism using Redis's hash structure. Read requests share the lock, while write requests acquire an exclusive lock, reducing lock contention overhead in high-concurrency read scenarios.

[0111] Step 62: If the lock is successfully acquired, check if the historical idempotent result is stored in the distributed cache. 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] Step 63: If no historical idempotent results are found, the business method is executed, and the business result is written to the distributed cache before the distributed lock is released. Specifically, if no historical idempotent results are found in the distributed cache, it indicates that the 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 is set to an expiration time consistent with the lifespan in the idempotent configuration object to ensure automatic cache cleanup. After writing, the system actively releases the distributed lock using the "DEL key" command to avoid concurrent blocking caused by excessive lock holding time.

[0113] Step 64: If lock acquisition fails, wait for the distributed lock to be released and return the idempotent result from the distributed cache. Specifically, if the distributed lock acquisition fails, it indicates that other nodes are processing business requests 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 fixed-interval spin retry strategy is used 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 keyspace notifications, reducing unnecessary spin overhead. After the lock is released, the system immediately queries the distributed cache for the generated idempotent result and returns it to the caller, ensuring that all concurrent requests eventually obtain consistent processing results.

[0114] Through the above process, this invention achieves fine-grained control of local cache deduplication, enabling local queries only in scenarios where the policy allows, which fully utilizes the low-latency characteristics of local cache and ensures the validity of the results through remaining lifetime verification; for cases of miss or expiration, it seamlessly connects to the distributed deduplication process to ensure the accuracy and completeness of idempotency determination.

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

[0116] Step 71: Write the idempotent result payload to the distributed cache with an idempotent key and set the expiration time according to the time-to-live in the idempotent configuration object; specifically, when neither the local cache nor the distributed cache finds a valid idempotent result, the current business request is determined to be the first processing, and the original business method is called to execute the core logic; during the execution, the system will capture the normal return result or exception information of the method and encapsulate this information into an idempotent result payload; the payload includes business result fields, call count, processing timestamp, etc.

[0117] 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. By using 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 the local cache can synchronize the latest data more quickly after the distributed cache result is updated.

[0118] Step 73: After writing is complete, delete the corresponding distributed lock key, release the lock resource, and allow subsequent concurrent requests to read the written idempotent result; avoid concurrent blocking caused by long-term lock occupation and improve the collaborative processing efficiency of the system.

[0119] In this embodiment, distributed caching ensures result consistency across nodes, while local caching improves the response speed for repeated requests on the same node. Differentiated expiration time settings ensure data freshness while also considering performance. Actively releasing 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 the release of lock resources, the system automatically triggers a process for constructing a processing event that includes an idempotent key, processing status, timestamp, and performance metrics. The idempotent key is used to associate the event with a specific processing object; the processing status specifies the type of the current request's processing result through an enumeration value; the timestamp accurately records the moment the event was generated; and the performance metrics cover key performance data such as the total time consumed from request interception to result caching, cache query time, and lock wait time. Subsequently, the system sends the processing event to a designated message queue topic through a 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 directly returns it to the caller. The above process achieves full observability of the idempotent processing chain.

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

[0122] The strategy training module 81 is used to collect historical business request records and performance data, use the particle swarm algorithm to iteratively optimize the combination of strategy parameters, generate the final strategy vector, and store it in the strategy configuration center.

[0123] Metadata generation module 82 is used to intercept method calls marked with the @MethodIdempotent annotation through AOP aspects, parse the annotation configuration and method parameters, and generate request metadata;

[0124] The strategy injection module 83 is used to load the corresponding final strategy vector from the strategy configuration center based on the business identifier and strategy version number in the request metadata, and inject it to generate an idempotent configuration object.

[0125] The cache deduplication module 84 is used to generate business keys based on business parameters in the request metadata and to perform hash processing to form idempotent keys.

[0126] Based on the local priority strategy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a match is found, the idempotency result in the cache is returned directly; otherwise, the distributed deduplication step is initiated.

[0127] The business processing module 85 is used to call the original business method during the first processing, obtain the normal return result or the exception information, encapsulate it into an idempotent result payload, write the idempotent result payload to the distributed cache and set the time-to-live, write it to the local cache and set the expiration time, and release the lock resources.

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

[0129] It should be noted that the interval and threshold sizes are set for ease of comparison. The size of the threshold depends on the amount of sample data and the base number 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 calculations, and the formulas are derived from software simulations using a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0130] The embodiments of the present invention have been described above, but the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of the present embodiments, all of which are within the protection scope of the present embodiments.

Claims

1. An annotation-driven idempotency processing method, characterized in that, Includes the following steps: Step 1: Collect historical business request records and performance data, use the particle swarm optimization algorithm to iteratively optimize the strategy parameter combination, generate the final strategy vector, and store it in the strategy configuration center. Specific steps include: Step 11: Collect historical business request records and performance data, and encode the strategy parameter combinations into unified numerical values ​​to form training samples; Step 12: Initialize the particle swarm based on training samples and domain-inspired rules to obtain initial particle parameter vectors and velocity vectors; wherein, the domain-inspired rules include: The initial value for the lifetime is set to three times the time taken by the 99th percentile of the target business requests 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 as a reentrant lock; when the peak concurrency is not less than the concurrency threshold, it is initialized as a spin read-write lock. When the available memory percentage of a node is higher than the memory threshold, the local cache priority switch is initialized to the enabled state; otherwise, it is initialized to the disabled 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. Step 13: Update the position and velocity using the standard particle swarm update formula for the survival time, and update the cache type, lock mode, local cache priority switch and maximum number of retries using the probability voting method. Step 14: Construct a fitness function by weighting the throughput, conflict rate and timeout rate, and calculate the fitness for 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 highest global fitness is taken as the final policy vector and stored in the policy configuration center; The strategy parameter combination includes: time to live, cache type, lock mode, local cache priority switch, and maximum number of retries; Step 2: Intercept method calls marked with the @MethodIdempotent annotation using AOP aspects, 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 to generate an 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; Based on the local priority strategy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a match is found, the idempotency result in the cache is returned directly; otherwise, the distributed deduplication step is initiated. Step 5: During the initial processing, call the original business method to obtain the normal return result or the exception information, encapsulate it into an idempotent result payload, write the idempotent result payload to the distributed cache and set its time-to-live, write it to the local cache and set its expiration time, and release the lock resources. Step 6: Construct a processing event containing an idempotent key, processing status, timestamp, and performance metrics, send it to the message queue, and return the business result from the idempotent result.

2. The annotation-driven idempotency processing method according to claim 1, characterized in that, By intercepting method calls annotated with `@MethodIdempotent` through AOP aspects, parsing the annotation configuration and method parameters, and generating request metadata, including: Step 21: The annotated method is woven into the proxy chain when the application starts, capturing the join point information and thread context at the time of the call; Step 22: Parse the annotation configuration to obtain the annotation parameter set, and extract the SpEL expression, version number, and scope information; Step 23: Collect method arguments and serialize them into a parameter set. Generate a business identifier by concatenating the scope, target class name and method name in the annotation parameter set. Determine the version identifier by combining the annotation version number. Merge the business identifier, version identifier, parameter set and call timestamp to obtain request metadata.

3. The annotation-driven idempotency processing method according to claim 2, 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 to generate an idempotent configuration object, including: 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; Step 32: Perform integrity checks on the fields of the final strategy vector in sequence. If any field is missing, a rollback will be triggered and an alarm will be recorded. Step 33: Based on the field mapping relationship, inject the time to live, cache type, lock mode, local cache priority switch and maximum number of retries into the corresponding properties of the idempotent configuration object to obtain an immutable idempotent configuration object, and write it into the call context.

4. The annotation-driven idempotency processing method according to claim 1, characterized in that, A business key is generated based on the business parameters in the request metadata, and then hashed 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 SHA-256 hash operation on the business key to obtain the hash value, and concatenate the fixed prefix with the hash value to obtain the idempotent key; Step 43: Calculate the CRC32 checksum for the idempotent key and record it to the monitoring event stream; Step 44: When the length of the business key exceeds the preset threshold, a degradation strategy is triggered and an alarm is output.

5. The annotation-driven idempotency processing method according to claim 1, characterized in that, Based on the local priority strategy and cache type set in the idempotent configuration object, perform deduplication in the local cache and return the results, including: Step 51: When the local cache priority switch is on and the cache type is local cache, query the corresponding idempotent result in the local cache using the idempotent key; Step 52: If an idempotent result is found, compare the remaining lifetime of the idempotent result with the lifetime threshold. If the remaining lifetime is greater than the lifetime threshold, return the idempotent result directly to the caller and report the local hit index. Step 53: If no idempotent result is found, or the remaining lifetime is not greater than the lifetime threshold, output a miss signal and proceed to the distributed deduplication step.

6. The annotation-driven idempotency processing method according to claim 5, characterized in that, The distributed deduplication step includes: Step 61: Acquire a distributed lock in the distributed cache system using the idempotent key according to the lock mode specified by the idempotent configuration object; Step 62: If the lock is successfully acquired, check if the historical idempotent result has been stored in the distributed cache. If found, return the historical idempotent result to the caller. Step 63: If no historical idempotent result is found, execute the business method, write the business result to the distributed cache, and then release the distributed lock. Step 64: If lock acquisition fails, wait for the distributed lock to be released and return the idempotent result in the distributed cache.

7. The annotation-driven idempotency processing method according to claim 1, characterized in that, Step 5 specifically includes: Step 71: Write the idempotent result payload into the distributed cache with an idempotent key, and set the expiration time according to the time-to-live 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 complete, delete the corresponding distributed lock key, release the lock resource, and allow subsequent concurrent requests to read the written idempotent result.

8. An annotation-driven idempotent processing system, characterized in that, The annotation-driven idempotent processing method as described in any one of claims 1-7 includes: The strategy training module (81) is used to collect historical business request records and performance data, use particle swarm optimization to iteratively optimize the strategy parameter combination, generate the final strategy vector, and store it in the strategy configuration center. The metadata generation module (82) is used to intercept method calls marked with the @MethodIdempotent annotation through AOP aspects, parse the annotation configuration and method parameters, and generate request metadata; The strategy injection module (83) is used to load the corresponding final strategy vector from the strategy configuration center based on the business identifier and strategy version number in the request metadata and inject it to generate an idempotent configuration object. The cache deduplication module (84) is used to generate business keys based on business parameters in the request metadata and to perform hash processing to form idempotent keys; Based on the local priority strategy and cache type set in the idempotency configuration object, the corresponding idempotency key is searched in the local cache. If a match is found, the idempotency result in the cache is returned directly; otherwise, the distributed deduplication step is initiated. The business processing module (85) is used to call the original business method during the first processing, obtain the normal return result or the abnormal information, encapsulate it into an idempotent result payload, write the idempotent result payload into the distributed cache and set the time-to-live, write it into the local cache and set the expiration time, and release the lock resources. The result delivery module (86) is used to construct a processing event containing an idempotent key, processing status, timestamp and performance metrics, send it to the message queue, and return the business results in the idempotent result.

Images