SoFunction
Updated on 2025-03-04

Idepotency of Java interface

1. Introduction

Introduction to the concept of idempotence

In computer science,Idepotencyis an important property, which refers to the same effect as an operation being executed multiple times and once. In other words, no matter how many times this operation is performed, the results should be consistent.

This concept is very important in a variety of programming scenarios, especially in distributed systems, network communications and database operations.

Note: The essential difference between idempotence and heavy-duty prevention is that heavy-duty prevention is that multiple requests return an error, while idempotence returns the same result.

For example, consider a simple HTTP GET request, which should be idempotent, which means that no matter how many times you request, the server returns the same result and does not change the server's state due to multiple requests. Relatively, a POST request is not traditionally idempotent, as it may create a new resource every time it requests.

Why do Idepotency need to be implemented in Java interface

In Java application development, especially applications involving network communication and database operations, it is particularly important to realize the idempotence of interfaces. This is mainly because:

  1. Prevent data duplication: In the case of unstable network or repeated operations by users, ensure that the data is not processed repeatedly, for example, avoid multiple deductions because the user clicks the "Pay" button multiple times.
  2. Improve system robustness: The system can handle duplicate requests without errors or inconsistent results, enhancing the system's fault tolerance for external operations.
  3. Simplify error recovery: When the operation fails or the system is abnormal, the operation can be safely re-execute without worrying about causing state errors or data inconsistencies.
  4. Enhanced user experience: Users do not need to worry that multiple clicks or operations will lead to undesired results, thereby improving the user's operating experience.

2. Use idempotence tables to achieve idempotence

Implementation process:

  • During the database design stage, add idempotent tables.
  • Before the business logic begins, check whether there is a corresponding request record in the idempotent table.
  • Decide whether to continue processing the request based on the inspection results.
  • Update the status of the idempotent table after processing is completed.

What is an idempotent table

Impotent tables are a mechanism used in a database to track operations that have been performed to ensure that operations are executed only once even if the same request is received multiple times.

Such tables usually contain enough information to identify the request and its execution status, and are an effective means to achieve interface idempotence.

How to design an idempotent table

When designing an idempotent table, the key is to determine which fields are required to be able to uniquely identify each operation. A basic idempotent table design may include the following fields:

  • ID: A unique identifier, usually a primary key.
  • RequestID: Request identifier, used to identify specific requests from the client, it is best to add a unique key index here.
  • Status: Indicates the request processing status (such as processing, success, and failure).
  • Timestamp: Record the timestamp of the operation.
  • Payload(Optional): Stores some or all of the requested data for subsequent processing or auditing.

Example: Java code implementation uses idempotent tables

Here is a simple Java example showing how to use idempotent tables to ensure idempotence of an interface. Suppose we use Spring framework and JPA to operate the database.

First, define an idempotent entity:

import .*;
import ;

@Entity
@Table(name = "idempotency_control")
public class IdempotencyControl {
    @Id
    @GeneratedValue(strategy = )
    private Long id;

    @Column(nullable = false, unique = true)
    private String requestId;

    @Column(nullable = false)
    private String status;

    @Column(nullable = false)
    private LocalDateTime timestamp;

    // Constructors, getters and setters
}

Next, create a Repository for manipulating idempotent tables:

import ;
import ;

@Repository
public interface IdempotencyControlRepository extends JpaRepository<IdempotencyControl, Long> {
    IdempotencyControl findByRequestId(String requestId);
}

Finally, implement a service to handle the request, using an idempotence table to ensure the idempotence of the operation:

import ;
import ;
import ;

@Service
public class IdempotencyService {

    @Autowired
    private IdempotencyControlRepository repository;

    @Transactional
    public String processRequest(String requestId, String payload) {
        IdempotencyControl control = (requestId);
        if (control != null) {
            return "Request already processed"; // Determine the returned content through the control table results        }

        control = new IdempotencyControl();
        (requestId);
        ("PROCESSING");
        (());
        (control);

        // Process the request here


        // Assume processing is successful
        ("COMPLETED");
        (control);

        return "Request processed successfully";
    }
}

In this example, we first check whether the request ID already exists in the database. If it exists, we believe that the request has been processed and return it directlyCorresponding information。

If it does not exist, we mark its status as being processed, process the request, and then update the status to Complete.

This approach ensures that the operational effect is consistent even when the same request is received multiple times.

Idepotency is achieved using idempotence table

Key Code:

public boolean checkAndInsertIdempotentKey(String requestId) {
    String sql = "INSERT INTO idempotency_keys (request_id, status, created_at) VALUES (?, 'PENDING', NOW()) ON DUPLICATE KEY UPDATE request_id=request_id";
    try {
        int result = (sql, requestId);
        return result == 1;
    } catch (DuplicateKeyException e) {
        return false;
    }
}

Technical analysis:

  • This code attempts to insert a new request ID into the idempotent table. If the request ID already exists,ON DUPLICATE KEY UPDATEThe clause will be fired, but no records will be changed, and the result returned will be 0.
  • usejdbcTemplateTo handle database operations, this is a convenient tool provided by the Spring framework that can simplify JDBC operations.
  • By CaptureDuplicateKeyException,We can determine that the request ID already exists, thus preventing duplicate processing.

Important decisions and choices:

  • chooseON DUPLICATE KEY UPDATEThis is to ensure the atomicity of the operation and avoid additional database queries between checking whether the key exists and inserting the key, which can reduce the risk of race conditions.

3. Use Nginx + Lua and Redis to achieve idempotence

Implementation process:

  • Configure the Lua module on the Nginx server.
  • Write Lua scripts to check and set request flags using Redis's SETNX command.
  • Intercept duplicate requests or releases at the Nginx level based on the execution results of the Lua script.

Introduction to the role of Nginx and Lua

NginxIt is a high-performance HTTP and reverse proxy server, which is also commonly used for load balancing. Nginx is capable of handling a large number of concurrent connections through its lightweight and high scalability, making it an ideal choice for modern high-load applications.

LuaIt is a lightweight scripting language that can be embedded into Nginx through Nginx's module ngx_lua, allowing developers to directly write dynamic logic in Nginx configuration. This combination can greatly improve Nginx's flexibility and dynamic processing capabilities, especially during the preprocessing phase before processing HTTP requests.

Introducing Redis's SETNX command

SETNXis a command in Redis for "SET if Not eXists". Its basic function is: the key value will be set only when the specified key does not exist. This command is often used to implement locks or other synchronization mechanisms and is very suitable for ensuring idempotence of operations.

  • If SETNX succeeds (i.e., the previous key does not exist), it means that the current operation is the first execution;
  • If SETNX fails (the key already exists), it means that the operation has been executed.

Architecture design: How to combine Nginx, Lua and Redis to achieve idempotence

In a typical architecture, the request initiated by the client first reaches the Nginx server. Nginx uses Lua script to preprocess these requests, which checks whether the corresponding keys in Redis exist:

  • Receive request: Nginx receives a request from the client.
  • Lua script processing: Nginx calls the Lua script, which tries to set a unique key related to the request using SETNX in Redis.

Check results：

  • If the key does not exist, the Lua script sets the key and continues to process the request (forwards to the backend Java application);
  • If the key exists, the Lua script directly returns an error or prompt message, informing the operation that it has been executed and preventing duplicate processing.

Example: Configure Nginx and Lua scripts, as well as corresponding Java call code

Nginx configuration part：

http {
    lua_shared_dict locks 10m;  # Allocate 10MB of memory to store lock information
    server {
        location /api {
            default_type 'text/plain';
            content_by_lua_block {
                local redis = require ""
                local red = redis:new()
                red:set_timeout(1000)  -- 1Second timeout
                local ok, err = red:connect("127.0.0.1", 6379)
                if not ok then
                    ("Failed to connect to Redis: ", err)
                    return
                end

                local key = "unique_key_" .. .request_uri
                local res, err = red:setnx(key, .remote_addr)
                if res == 0 then
                    ("Duplicate request")
                    return
                end

                -- Set the expiration time of the key，Prevent permanent occupation
                red:expire(key, 60)  -- 60Automatically delete key after seconds

                -- Forwarding requests to backend applications
                ("@backend")
            }
        }

        location @backend {
            proxy_pass http://backend_servers;
        }
    }
}

Java call code：

The Java side does not require special processing, because the control of idempotence has been implemented at the Nginx+Lua level. Java applications only need to process requests forwarded from Nginx according to normal logic.

@RestController
@RequestMapping("/api")
public class ApiController {

    @PostMapping("/process")
    public ResponseEntity&lt;String&gt; processRequest(@RequestBody SomeData data) {
        // Process the request        return ("Processed successfully");
    }
}

This approach moves requested idempotence management from the application layer to the higher-level network layer, helping to reduce the burden on back-end applications and improve overall response speed and system scalability.

Idepotency with Nginx + Lua and Redis

Key configuration and code:

location /api {
    set_by_lua $token 'return .arg_token';
    access_by_lua '
        local res = ("/redis", { args = { key = , value = "EXISTS" } })
        if  == "EXISTS" then
            (ngx.HTTP_FORBIDDEN)
        end
    ';
    proxy_pass http://my_backend;
}

Technical analysis:

  • useset_by_luaExtract the token from the request and use the token in the Lua script.
  • access_by_luaIn the block, access the internal location/redisTo query the key value in Redis. If the key already exists, return 403 to prohibit access to the status code, preventing further processing of the request.
  • proxy_passForward the request to the backend service.

Important decisions and choices:

  • Using a combination of Nginx and Lua allows preprocessing before requests reach the application server, easing the burden on the backend.
  • Quick key-value checks with Redis, taking advantage of its performance benefits to ensure speed and efficiency of operations.

4. Use AOP to achieve idempotence

Implementation process:

  • Define a section that specifically deals with idempotence logic.
  • Idepotential checks are performed using pre-notations at appropriate entry points (such as service layer methods).
  • Depending on business needs, it may also be necessary to update the status with post-notification after the method is executed.

Introduction to the basic concepts of AOP (sectional-oriented programming)

Oriented Programming (AOP)is a programming paradigm designed to enhance modularity by separating application logic from system services. This method is mainly used to deal with cross-cutting concerns such as logging, transaction management, data verification, etc., which are usually scattered across multiple modules or components. AOP by definitionsection(aspects), so that the implementation of these concerns can be centrally managed and reused.

In Java, the Spring framework provides support for aspect-oriented programming through Spring AOP, allowing developers to define aspect, pointcuts, and notifications through simple annotations or XML configurations.

Strategy for Idepotency using Spring AOP

In the context of implementing interface idempotence, Spring AOP can be used to intercept interface calls and perform necessary idempotence checks. This usually involves the following steps:

  1. Define the point cut: Specify which methods require idempotence protection.
  2. Pre-Notice: Before the method is executed, check whether an identifier (such as the request ID) already exists in Redis. If it exists, the method is prevented from executing.
  3. Post-Notice: After the method is executed, add the request ID to Redis to mark that this operation has been completed.

Example: Define the section, write After notifications to update Redis state

Here is an example of using Spring AOP to achieve idempotence, including defining the slicing and writing post-notifications to update the Redis state.

Define the section:

First, you need to define a tangent and a tangent point, which matches all methods that require idempotence protection:

import ;
import ;
import ;
import ;
import ;
import ;

@Aspect
@Component
public class IdempotenceAspect {

    @Autowired
    private StringRedisTemplate redisTemplate;

    @Pointcut("@annotation(Idempotent)") // Assume that Idempotent is a custom annotation for marking methods that require idempotent protection    public void idempotentOperation() {}

    @AfterReturning("idempotentOperation()")
    public void afterReturning(JoinPoint joinPoint) {
        // Get the request identifier        String key = extractKeyFromJoinPoint(joinPoint);
        // Store the operation identifier in Redis and mark it as processed        ().set(key, "processed", 10, ); // In the example, the expiration is expired after 10 minutes.    }

    private String extractKeyFromJoinPoint(JoinPoint joinPoint) {
        // Here we implement the logic of obtaining keys from method parameters, etc.        return "SOME_KEY";
    }
}

In this example,IdempotentAnnotations are used to mark those methods that require idempotence protection.@AfterReturningNotifications ensure that the request ID is added to Redis only after the method is successfully executed. This prevents incorrectly marking the request as processed when an exception occurs during execution.

The advantage of this method is that it decouples idempotence logic from business code, making business logic clearer while centrally managing idempotence protection.

Ideotropy with AOP

Key Code:

@Aspect
@Component
public class IdempotencyAspect {
    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    @AfterReturning(pointcut = "execution(* .*.*(..)) && @annotation(Idempotent)", returning = "result")
    public void afterReturningAdvice(JoinPoint joinPoint, Object result) {
        String key = getKeyFromJoinPoint(joinPoint);
        ().set(key, "COMPLETED", 10, );
    }

    private String getKeyFromJoinPoint(JoinPoint joinPoint) {
        // Logic to extract key based on method arguments or annotations
    }
}

Technical analysis:

  • Define a sectionIdempotencyAspect, it is in the@IdempotentThe annotation method is executed successfully.
  • use@AfterReturningNotification to update the key status in Redis, marked as "COMPLETED".

Important decisions and choices:

  • Selecting AOP allows developers to achieve idempotence without intruding into business code, improving the maintainability and clarity of the code.
  • Use Redis to store operational states, and use its fast access and expiration mechanisms to automatically manage state data.

These parses and decisions show how to ensure the idempotence of Java interfaces through technical means at different levels, each method has its applicable scenarios and advantages.

5. Practical application and testing

Provide test examples and results

Test the idempotent table:

  • Scene: Simulates the user to submit a repeated order request.
  • operate: Send the same order creation request in succession.
  • Expected results: The first request to create an order successfully, and subsequent requests are intercepted, and the prompt message is returned such as "The operation has been processed".

Test code example：

// Suppose there is an interface for order submission@PostMapping("/submitOrder")
public ResponseEntity&lt;String&gt; submitOrder(@RequestBody Order order) {
    boolean isProcessed = (());
    if (!isProcessed) {
        return ("Order submitted successfully");
    } else {
        return ().body("Operation processed");
    }
}

Test Nginx + Lua + Redis

  • Scene: The user clicks the payment button multiple times in a short period of time.
  • operate: Simulate fast and continuous sending payment requests.
  • Expected results: The first request to process payment, and subsequent requests are intercepted at the Nginx level, returning error or prompt information.

Test Spring AOP

  • Scene: Call the API interface for resource creation.
  • operate: Continuously call the same API interface.
  • Expected results: Through the pre-notification of the AOP section, the first call executes resource creation, and the subsequent call returns the processed state.

Test code example：

// AOP facet processing@Aspect
@Component
public class IdempotencyAspect {

    @Autowired
    private IdempotencyService idempotencyService;

    @Before("@annotation(Idempotent) &amp;&amp; args(request,..)")
    public void checkIdempotency(JoinPoint joinPoint, IdempotentRequest request) throws Throwable {
        if (!(())) {
            throw new IdempotencyException("Duplicate request detected.");
        }
    }
}

Test resultsIt should be shown that idempotence logic effectively prevents repeated operations, thus ensuring system stability and data consistency. These tests not only validate the correctness of the functionality, but also evaluate the performance impact of idempotent solutions in system stress testing.

Summarize

The above is personal experience. I hope you can give you a reference and I hope you can support me more.