JAVA REST 接口幂等性设计？利用 Redis + 唯一请求 ID 防重复提交 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

JAVA REST 接口幂等性设计：Redis + 唯一请求 ID 防重复提交

各位好，今天我们来聊聊一个在构建健壮、可靠的 RESTful API 中至关重要的话题：接口的幂等性。尤其是在分布式系统环境下，网络波动、服务重启等因素都可能导致客户端发起重复请求。如果接口没有做幂等性处理，可能会产生意想不到的后果，比如重复下单、重复支付等，造成数据不一致。

今天我会重点讲解如何利用 Redis 和唯一请求 ID 来实现 REST 接口的幂等性，并提供详细的代码示例和逻辑分析。

什么是幂等性？

首先，我们来明确一下幂等性的概念。一个操作被称为幂等的，如果多次执行所产生的结果与执行一次的结果相同。用数学公式表达就是：

f(f(x)) = f(x)

简单来说，无论调用多少次，结果都应该一致。

例如：

GET 请求： 天然具有幂等性，多次获取同一资源，结果相同。
PUT 请求： 通常是幂等的，用请求中的数据完全替换指定资源，多次执行结果一致。
DELETE 请求： 通常也是幂等的，删除指定资源，多次删除效果相同（虽然可能返回 404）。
POST 请求： 往往不具备幂等性，因为每次 POST 请求都可能创建新的资源。

为什么需要幂等性？

在分布式系统中，由于网络不可靠，可能会出现以下情况：

请求超时： 客户端发起请求，但由于网络问题，服务端没有及时响应，客户端可能会重试。
消息丢失： 客户端发送的请求在传输过程中丢失，客户端可能会重发。
服务端处理失败： 服务端接收到请求，但在处理过程中出现异常，客户端可能会重试。

如果没有幂等性保证，这些重试操作可能会导致数据重复或错误，破坏系统的正确性。

Redis + 唯一请求 ID 的幂等性方案

我们的方案核心思想是：

生成唯一请求 ID： 客户端在发起请求时，生成一个全局唯一的 ID，例如 UUID。
携带请求 ID： 将该 ID 放在 HTTP 请求头中，传递给服务端。
Redis 校验： 服务端接收到请求后，先从 Redis 中查询是否存在该 ID。
- 如果存在，说明是重复请求，直接返回上次的处理结果。
- 如果不存在，说明是首次请求，执行业务逻辑，并将请求 ID 存入 Redis，设置过期时间，防止 Redis 数据无限增长。
执行业务逻辑： 如果是首次请求，则执行相应的业务逻辑。
存储请求 ID： 将请求 ID 存入 Redis，并设置一个合理的过期时间。
返回结果： 返回业务处理结果。

接下来，我们通过代码示例来详细说明这个方案。

代码示例

1. 客户端生成唯一请求 ID

客户端可以使用 UUID 来生成唯一请求 ID。

import java.util.UUID;

public class RequestIdGenerator {

    public static String generateRequestId() {
        return UUID.randomUUID().toString();
    }

    public static void main(String[] args) {
        String requestId = generateRequestId();
        System.out.println("Generated Request ID: " + requestId);
    }
}

在发起 HTTP 请求时，将该 ID 放入请求头中。例如，使用 Spring 的 RestTemplate：

import org.springframework.http.HttpEntity;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.http.ResponseEntity;
import org.springframework.web.client.RestTemplate;

public class ApiClient {

    public static void main(String[] args) {
        RestTemplate restTemplate = new RestTemplate();
        String url = "http://localhost:8080/api/order";
        String requestId = RequestIdGenerator.generateRequestId();

        HttpHeaders headers = new HttpHeaders();
        headers.set("Request-Id", requestId);

        HttpEntity<String> requestEntity = new HttpEntity<>(headers);

        ResponseEntity<String> response = restTemplate.exchange(url, HttpMethod.POST, requestEntity, String.class);

        System.out.println("Response: " + response.getBody());
    }
}

2. 服务端 Controller

服务端接收请求，并从请求头中获取请求 ID。

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class OrderController {

    @Autowired
    private OrderService orderService;

    @PostMapping("/api/order")
    public ResponseEntity<String> createOrder(@RequestHeader("Request-Id") String requestId) {
        try {
            String result = orderService.createOrder(requestId);
            return ResponseEntity.ok(result);
        } catch (DuplicateRequestException e) {
            return ResponseEntity.status(HttpStatus.CONFLICT).body(e.getMessage()); // 返回 409 Conflict
        } catch (Exception e) {
            return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Internal Server Error");
        }
    }
}

这里使用 @RequestHeader 注解来获取请求头中的 Request-Id。如果 OrderService 抛出 DuplicateRequestException 异常，说明是重复请求，返回 HTTP 状态码 409 Conflict。

3. OrderService

OrderService 负责处理业务逻辑，并使用 Redis 进行幂等性校验。

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

@Service
public class OrderService {

    @Autowired
    private StringRedisTemplate redisTemplate;

    private static final String REQUEST_ID_PREFIX = "request_id:";
    private static final long REQUEST_ID_EXPIRATION = 60; // 过期时间，单位：秒

    public String createOrder(String requestId) {
        String redisKey = REQUEST_ID_PREFIX + requestId;

        // 检查 Redis 中是否存在该请求 ID
        Boolean isPresent = redisTemplate.hasKey(redisKey);
        if (isPresent != null && isPresent) {
            throw new DuplicateRequestException("Duplicate request");
        }

        // 设置请求 ID 到 Redis，并设置过期时间
        Boolean isSet = redisTemplate.opsForValue().setIfAbsent(redisKey, "processed", REQUEST_ID_EXPIRATION, TimeUnit.SECONDS);

        if(isSet == null || !isSet){
             throw new DuplicateRequestException("Duplicate request");
        }

        // 执行创建订单的业务逻辑
        String orderId = processOrderCreation();

        return "Order created successfully with ID: " + orderId;
    }

    private String processOrderCreation() {
        // 模拟创建订单
        try {
            Thread.sleep(100); // Simulate some processing time
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        return "ORDER-" + System.currentTimeMillis(); // 简单生成一个订单 ID
    }
}

在这个例子中：

REQUEST_ID_PREFIX 是 Redis Key 的前缀，用于区分不同的 Key。
REQUEST_ID_EXPIRATION 是请求 ID 在 Redis 中的过期时间，设置为 60 秒。
redisTemplate.hasKey(redisKey) 检查 Redis 中是否存在该请求 ID。
redisTemplate.opsForValue().setIfAbsent(redisKey, "processed", REQUEST_ID_EXPIRATION, TimeUnit.SECONDS) 使用 setIfAbsent 方法，只有当 Key 不存在时才设置值，保证只有一个请求能够成功设置，其他请求会返回 false，从而避免重复处理。值设置为 "processed"，只是一个占位符，表明该请求已经处理过了。
processOrderCreation() 模拟创建订单的业务逻辑。

4. DuplicateRequestException

自定义异常，用于表示重复请求。

public class DuplicateRequestException extends RuntimeException {

    public DuplicateRequestException(String message) {
        super(message);
    }
}

5. Redis 配置

需要配置 Redis 连接。这里以Spring Boot 整合Redis为例：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.StringRedisTemplate;

@Configuration
public class RedisConfig {

    @Bean
    public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
        StringRedisTemplate template = new StringRedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }
}

同时，需要在 application.properties 或 application.yml 中配置 Redis 连接信息：

spring.redis.host=localhost
spring.redis.port=6379
# spring.redis.password=your_password

逻辑分析

这个方案的核心在于利用 Redis 的原子性操作 setIfAbsent 来保证只有一个请求能够成功写入请求 ID。

首次请求： 当请求 ID 不存在于 Redis 中时，setIfAbsent 方法会成功写入该 ID，并返回 true。业务逻辑继续执行，创建订单。
重复请求： 当请求 ID 已经存在于 Redis 中时，setIfAbsent 方法不会覆盖已有的值，返回 false。 OrderService 抛出 DuplicateRequestException 异常，Controller 返回 409 Conflict，告知客户端该请求已经处理过了。

通过设置过期时间，可以防止 Redis 中存储过多的请求 ID，避免内存溢出。

优缺点分析

优点：

简单易懂： 实现逻辑清晰，易于理解和维护。
高性能： Redis 的读写速度非常快，对性能影响较小。
适用性广： 适用于各种需要保证幂等性的场景。

缺点：

依赖 Redis： 需要引入 Redis 作为依赖，增加了系统的复杂性。
过期时间： 需要合理设置过期时间，过短可能导致误判，过长可能导致 Redis 占用过多内存。
数据一致性： 在极端情况下，如果 Redis 写入成功，但后续业务逻辑失败，可能会导致数据不一致。需要结合事务或其他机制来保证数据一致性。

进一步优化

分布式锁： 如果业务逻辑比较复杂，可以使用分布式锁来保证只有一个线程能够执行业务逻辑。可以使用 Redlock 算法来实现高可用的分布式锁。
数据库唯一约束： 在数据库中设置唯一约束，防止重复数据写入。如果业务逻辑涉及到数据库操作，可以利用数据库的唯一索引特性，当重复请求尝试插入相同的数据时，数据库会抛出异常，从而保证幂等性。
Token 机制： 客户端先向服务端请求一个 Token，服务端将 Token 存储在 Redis 中，并设置过期时间。客户端在发起请求时，携带该 Token。服务端验证 Token 的有效性，如果有效，则执行业务逻辑，并删除 Token。如果无效，则拒绝请求。

各种幂等性方案对比

为了更清晰的理解不同方案的特点，这里我们用一个表格来对比几种常见的幂等性实现方案：

方案	优点	缺点	适用场景
Redis + 请求 ID	实现简单，性能高，适用于大部分场景	依赖 Redis，需要合理设置过期时间，极端情况下可能出现数据不一致	需要保证幂等性的 REST API，例如创建订单、支付等
数据库唯一约束	简单易用，利用数据库自身的特性	只能防止重复数据写入，无法解决业务逻辑重复执行的问题，如果唯一键冲突，会抛出异常，需要捕获处理	涉及到数据库写入的场景，例如创建用户、创建商品等
乐观锁	无需引入额外的组件，利用版本号控制并发	只能解决更新操作的幂等性问题，需要额外的字段来记录版本号，在高并发场景下可能会出现大量的冲突，导致性能下降	涉及到数据更新的场景，例如更新库存、更新价格等
分布式锁	可以保证只有一个线程能够执行业务逻辑，适用于复杂的业务场景	实现复杂，性能相对较低，需要引入分布式锁服务，例如 ZooKeeper、Redis 等	需要保证严格幂等性的复杂业务场景，例如银行转账、金融交易等
Token 机制	可以有效防止重复提交，适用于需要用户交互的场景	需要客户端配合，实现相对复杂，需要管理 Token 的生成、存储和验证，需要考虑 Token 的过期时间	涉及到用户交互的场景，例如表单提交、注册登录等

选择哪种方案，需要根据具体的业务场景和需求进行权衡。一般来说，对于简单的 REST API 接口，使用 Redis + 请求 ID 方案就足够了。对于复杂的业务场景，可能需要结合多种方案来实现幂等性。

一些建议

接口设计： 在设计接口时，尽量考虑幂等性，避免使用不幂等的操作。
错误处理： 在出现错误时，要进行适当的重试，但要避免无限重试，防止死循环。
监控： 对接口的幂等性进行监控，及时发现和解决问题。

总结

今天我们详细讲解了如何利用 Redis 和唯一请求 ID 来实现 REST 接口的幂等性，并提供了详细的代码示例和逻辑分析。希望能够帮助大家更好地理解和应用幂等性技术，构建更加健壮、可靠的系统。幂等性是系统设计的关键一环，尤其是在分布式环境下。选择合适的方案并正确实施，可以有效避免数据不一致等问题。