如何实现分布式幂等性设计？

一、分布式幂等性核心概念解析

1.1 什么是幂等性

幂等性(Idempotence)最初是一个数学概念，指一个运算在相同条件下多次执行所产生的结果与一次执行的结果相同。在计算机科学领域，特别是分布式系统中，幂等性被定义为：对于同一个接口或业务操作，无论执行多少次，最终产生的业务结果和系统状态都保持一致。

关键点说明：

1. 结果一致性：幂等性关注的是"结果一致"而非"过程一致"。例如：

   • 幂等操作示例：DELETE FROM users WHERE id=1，无论执行多少次，最终结果都是id=1的用户被删除
   • 非幂等操作示例：INSERT INTO users(name) VALUES('张三')，每次执行都会新增一条记录

2. 操作类型分析：

   • 查询操作(GET)：天然幂等
   • 删除操作(DELETE)：通常幂等（即使资源不存在也返回相同结果）
   • 更新操作(PUT)：需要设计为幂等（如使用绝对值而非增量更新）
   • 创建操作(POST)：通常非幂等

3. 实际业务场景示例：

   • 支付场景：同一笔支付请求处理多次不应导致多次扣款
   • 订单创建：重复提交订单请求不应生成多个相同订单
   • 库存扣减：防止超卖情况下重复扣减库存

1.2 分布式系统中幂等性的必要性

在分布式系统架构下，由于系统组件分布在不同的网络节点上，通过不可靠的网络进行通信，使得以下问题成为常态：

主要触发场景分析：

1. 网络重试机制：

   • 典型场景：客户端请求超时(Timeout)后的自动重试
   • 根本原因：TCP层重传、应用层重试策略
   • 后果示例：支付系统可能收到重复的支付请求

2. 消息队列重发：

   • 常见情况：消费者处理失败时的消息重投递
   • 典型系统：RabbitMQ的NACK机制、Kafka的消费者位移管理
   • 问题示例：订单处理消息被重复消费，导致同一订单被多次处理

3. 微服务调用重试：

   • 典型模式：服务网格(Service Mesh)中的retry策略
   • 常见框架：Spring Cloud的RetryTemplate、gRPC的retry配置
   • 风险示例：库存服务在调用扣减接口超时后重试，可能导致库存被多次扣减

4. 前端重复提交：

   • 用户行为：页面响应延迟导致用户多次点击提交按钮
   • 技术原因：缺乏防重复提交机制或按钮未及时禁用
   • 业务影响：电商系统中可能产生多个相同订单

缺乏幂等性的后果：

1. 财务风险：

   • 重复扣款：用户一次操作被多次扣款
   • 重复退款：同一笔退款被多次执行

2. 数据一致性问题：

   • 重复订单：同一购物车生成多个相同订单
   • 库存异常：超卖或库存数据不准确

3. 系统可靠性下降：

   • 统计指标失真：如UV/PV数据虚高
   • 业务流程中断：如审批流程出现重复记录

4. 用户体验受损：

   • 用户看到重复的订单或交易记录
   • 需要人工介入处理重复数据

典型业务影响案例：

1. 支付系统：用户充值100元，由于网络问题导致请求重试，若系统未做幂等处理，可能导致用户账户被多次充值

2. 订单系统：用户提交订单后因页面卡顿重复点击，若后端未做防重处理，会生成多个相同订单

3. 库存系统：秒杀场景下，由于并发请求和高延迟，可能导致库存被多次扣减，出现超卖现象

这些场景都突显了在分布式系统中实现业务操作幂等性的必要性和重要性。

二、分布式幂等性设计原则

2.1 最小影响原则

幂等性设计应尽量减少对原有业务逻辑的侵入，避免过度设计导致系统复杂度大幅增加。具体实施时可采用以下策略：

1. 中间件层实现：优先考虑在网关层或RPC框架层实现通用幂等性控制，例如通过Spring AOP拦截器或API网关过滤器实现，这样业务代码几乎不需要修改。

2. 标识存储选择：使用Redis等轻量级存储来维护幂等标识，而非直接修改业务数据库表结构。例如电商下单场景，可以在Redis中存储"order:user123:tx456"这样的键值对，而非在订单表中新增字段。

3. 无侵入设计：采用"标记-校验"模式，业务处理前先检查标记，处理完成后才设置标记，避免将幂等逻辑与业务逻辑深度耦合。

2.2 高性能原则

高并发场景下的性能优化策略：

1. 存储介质选择：

   • Redis集群：读写性能可达10万+ QPS，适合高频幂等校验
   • 本地缓存：对时效性要求不高的场景可使用Guava Cache等本地缓存
   • 对比测试：某支付平台实测，MySQL幂等校验平均延迟12ms，Redis仅0.5ms

2. 算法优化：

   • 采用轻量级锁替代分布式锁，如Redis的SETNX命令
   • 批量处理：对批量请求生成批处理ID而非单个ID
   • 短时效：设置合理的过期时间（如金融交易设30分钟，普通请求设5分钟）

3. 架构设计：

   • 多级缓存：本地缓存+分布式缓存分层设计
   • 异步处理：非核心链路可异步校验幂等性

2.3 高可用原则

保障幂等性基础设施可靠性的具体措施：

1. Redis高可用方案：

   • 集群模式：至少3主3从配置，使用CRC16算法分片
   • 持久化配置：AOF和RDB同时开启
   • 容灾演练：定期模拟节点故障测试自动切换

2. 数据库高可用：

   • 主从复制+读写分离
   • 使用GTID防止数据不一致
   • 配置监控告警，如主从延迟超过阈值自动告警

3. 降级方案：

   • 熔断机制：当Redis不可用时降级到本地缓存
   • 限流保护：幂等服务不可用时启用请求限流
   • 应急开关：可临时关闭非关键业务的幂等校验

2.4 数据一致性原则

确保数据一致性的关键技术：

1. 数据库方案：

   • 唯一索引：为业务表添加UNIQUE KEY约束
   • 事务隔离：使用SELECT FOR UPDATE防止并发更新
   • 乐观锁：通过version字段实现CAS操作

2. 分布式锁实现：

   • Redlock算法：多节点Redis实现分布式锁
   • 锁续期：通过守护线程定期延长锁有效期
   • 锁释放：必须保证finally块中释放锁

3. 异常处理：

   • 网络分区：实现quorum机制防止脑裂
   • 重试策略：采用指数退避算法控制重试频率
   • 最终一致性：对账系统定期核对数据

2.5 可扩展性原则

适应业务发展的扩展方案：

1. 水平扩展：

   • Redis集群：通过增加节点实现读写能力扩展
   • 数据库分库分表：如按照用户ID哈希分片

2. 架构演进：

   • 初期：单Redis节点+数据库唯一索引
   • 中期：Redis集群+分布式锁
   • 长期：引入消息队列实现异步幂等控制

3. 配置化设计：

   • 可调整的幂等时效：通过配置中心动态修改
   • 多策略支持：同时支持Token、参数指纹等多种校验方式
   • 热加载：在不重启服务的情况下更新校验规则

4. 监控体系：

   • 指标采集：成功率、耗时、异常率等
   • 容量规划：基于历史数据预测资源需求
   • 自动扩缩容：基于监控指标自动调整集群规模

三、分布式幂等性常见实现方案详解

3.1 基于唯一标识（Token）的幂等性方案

基于唯一标识（Token）的方案是最常用的幂等性实现方案之一，其核心思想是：在客户端发送请求前，先向服务端申请一个唯一的 Token，客户端携带该 Token 发送请求，服务端收到请求后，先校验 Token 的有效性（是否存在、是否已使用），若有效则处理业务逻辑并标记 Token 为已使用，若无效则直接返回结果，不处理业务逻辑。

3.1.1 实现步骤

1. Token 生成：

   • 客户端在执行业务操作前，调用服务端的 "Token 生成接口"。
   • 服务端生成一个全局唯一的 Token（可以使用 UUID、雪花算法等生成）。
   • 将 Token 存储到 Redis 或数据库中（Key 为 Token，Value 为 Token 状态，如 "未使用""已使用"），同时设置过期时间（通常为5-30分钟，视业务需求而定）。
   • 将 Token 返回给客户端。

2. Token 携带请求：

   • 客户端收到 Token 后，在发送业务请求时，将 Token 放入请求头（Header）或请求参数中。
   • 推荐使用请求头（如 Idempotent-Token: xxxxx）以避免污染业务参数。

3. Token 校验与业务处理：

   • 服务端收到请求后，首先从请求中提取 Token。
   • 查询 Redis 或数据库，校验 Token 是否存在且状态为 "未使用"。
     • 若校验通过：
       • 将 Token 状态更新为 "已使用"（使用原子操作确保并发安全）。
       • 执行后续的业务逻辑（如创建订单、扣款等）。
     • 若校验失败（Token 不存在或已使用）：
       • 直接返回 "请求已处理" 或相应的错误信息（HTTP 状态码可设为409 Conflict）。
       • 不执行业务逻辑。

4. Token 过期处理：

   • 为避免 Token 长期占用存储资源，设置合理的过期时间（如30分钟）。
   • 过期的 Token 会被自动清理（Redis 可自动过期，数据库需定时任务清理）。
   • 客户端若使用过期的 Token 发送请求，服务端会校验失败，此时客户端需重新申请 Token。

3.1.2 代码示例（基于 Redis）

Token 服务实现

@Service
public class TokenService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    // 生成Token，过期时间设为30分钟
    public String generateToken() {
        String token = UUID.randomUUID().toString().replace("-", "");
        // 存储Token到Redis，Key为token，Value为"UN_USED"（未使用），过期时间30分钟
        redisTemplate.opsForValue().set(token, "UN_USED", 30, TimeUnit.MINUTES);
        return token;
    }

    // 校验Token并标记为已使用（原子操作）
    public boolean validateAndMarkToken(String token) {
        // 使用Redis的setIfAbsent操作，确保线程安全
        Boolean success = redisTemplate.opsForValue().setIfAbsent(token + ":USED", "1", 30, TimeUnit.MINUTES);
        if (success != null && success) {
            // 若setIfAbsent返回true，说明Token未使用，校验通过
            return true;
        }
        // 若返回false，说明Token已使用或不存在，校验失败
        return false;
    }
}

业务接口示例（订单创建）

@RestController
@RequestMapping("/order")
public class OrderController {
    @Autowired
    private TokenService tokenService;
    @Autowired
    private OrderService orderService;

    // 生成创建订单的Token
    @GetMapping("/generate-token")
    public ResponseEntity<String> generateOrderToken() {
        String token = tokenService.generateToken();
        return ResponseEntity.ok(token);
    }

    // 创建订单接口（幂等性控制）
    @PostMapping("/create")
    public ResponseEntity<?> createOrder(
            @RequestHeader("Idempotent-Token") String token,
            @RequestBody OrderDTO orderDTO) {
        // 1. 校验Token
        if (!tokenService.validateAndMarkToken(token)) {
            return ResponseEntity.status(HttpStatus.CONFLICT)
                    .body(Map.of("code": 409, "message": "请求已处理，请勿重复提交"));
        }

        // 2. 处理业务逻辑
        try {
            OrderVO order = orderService.createOrder(orderDTO);
            return ResponseEntity.ok(order);
        } catch (Exception e) {
            // 业务异常处理
            return ResponseEntity.internalServerError()
                    .body(Map.of("code": 500, "message": "创建订单失败"));
        }
    }
}

3.1.3 适用场景

1. 前端表单提交：

   • 订单创建：用户提交订单前，前端先获取Token，避免重复点击导致多次下单。
   • 用户注册：防止网络延迟时用户重复提交注册表单。

2. 重要业务操作：

   • 支付系统：确保每次支付请求唯一，避免重复扣款。
   • 资金转账：防止因重试或网络问题导致多次转账。

3. 分布式系统调用：

   • 微服务间调用：确保服务间调用的幂等性，如库存扣减、优惠券核销等。

3.1.4 优缺点

优点：

1. 逻辑清晰，易于理解和实现。
2. 对业务代码侵入性低，可通过切面（AOP）统一处理。
3. 支持高并发场景（依赖Redis的高性能和原子操作）。
4. Token可设置过期时间，避免长期占用存储资源。

缺点：

1. 增加了一次Token申请的网络交互（可通过预生成Token池优化）。
2. 依赖外部存储（如Redis），需保证其高可用性。
3. Token过期时间需权衡：
   • 过短：可能导致正常请求失败（如网络延迟）。
   • 过长：占用存储资源，增加安全风险（如Token泄漏）。
4. 分布式环境下需确保Redis或数据库的原子操作（如使用Lua脚本）。

3.2 基于数据库唯一索引的幂等性方案

3.2.1 实现步骤

数据库表设计

1. 表结构设计原则：

   • 建议创建专用的幂等性控制表（而非直接修改业务表），避免对业务表性能产生影响
   • 必须包含业务类型字段（biz_type）和业务ID字段（biz_id）的组合
   • 建议增加状态字段（status）以区分不同处理阶段
   • 应包含时间戳字段用于问题排查和记录清理

2. 索引设计优化：

   • 唯一索引应覆盖biz_type和biz_id两个字段
   • 可考虑添加普通索引提高查询效率（如create_time索引用于定期清理）
   • 根据业务量预估选择合适的存储引擎（如InnoDB）

3. 示例表结构增强版：

CREATE TABLE `idempotent_record` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `biz_type` varchar(50) NOT NULL COMMENT '业务类型（如ORDER_CREATE：创建订单，PAY：支付）',
  `biz_id` varchar(100) NOT NULL COMMENT '业务唯一标识（如订单号、支付流水号）',
  `request_params` text COMMENT '请求参数快照（用于问题排查）',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态（0：处理中，1：处理成功，2：处理失败）',
  `result_data` text COMMENT '处理结果缓存',
  `retry_count` int(11) DEFAULT '0' COMMENT '重试次数',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `expire_time` datetime DEFAULT NULL COMMENT '过期时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_biz_type_biz_id` (`biz_type`,`biz_id`) USING BTREE COMMENT '唯一索引：业务类型+业务唯一标识',
  KEY `idx_create_time` (`create_time`) COMMENT '创建时间索引',
  KEY `idx_expire_time` (`expire_time`) COMMENT '过期时间索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='幂等性记录表';

业务流程优化

1. 请求处理流程：

   • 客户端生成请求唯一标识（推荐使用雪花算法等分布式ID生成方案）
   • 服务端提取业务类型和业务ID时需要进行有效性校验
   • 建议在插入前先做一次查询（降低冲突概率，但非必须）

2. 状态处理增强：

   • 处理中状态（0）应设置超时机制（如30秒自动过期）
   • 处理成功状态（1）可缓存业务结果（减少后续查询开销）
   • 处理失败状态（2）应记录详细错误信息

3. 并发控制优化：

   • 对于"处理中"状态可增加乐观锁控制
   • 可设置最大重试次数（防止无限重试）
   • 建议添加处理超时机制（避免长期占用资源）

3.2.2 增强版代码实现

@Service
@Slf4j
public class OrderService {
    private static final String BIZ_TYPE_ORDER_CREATE = "ORDER_CREATE";
    private static final int MAX_RETRY_COUNT = 3;
    private static final long PROCESS_TIMEOUT = 30000; // 30秒超时
    
    @Autowired
    private IdempotentRecordMapper idempotentRecordMapper;
    
    @Autowired
    private OrderMapper orderMapper;
    
    @Autowired
    private PlatformTransactionManager transactionManager;
    
    @Value("${idempotent.enable:true}")
    private boolean idempotentEnabled;

    @Transactional(rollbackFor = Exception.class)
    public OrderVO createOrder(OrderDTO orderDTO) {
        // 参数校验
        validateOrderDTO(orderDTO);
        
        // 1. 准备幂等记录
        String bizId = StringUtils.isNotBlank(orderDTO.getOrderNo()) ? 
                      orderDTO.getOrderNo() : 
                      generateOrderNo(orderDTO.getUserId());
        
        // 2. 幂等控制处理
        if(idempotentEnabled) {
            return handleWithIdempotent(orderDTO, bizId);
        } else {
            return createNewOrder(orderDTO, bizId);
        }
    }

    private OrderVO handleWithIdempotent(OrderDTO orderDTO, String bizId) {
        // 检查已有记录
        IdempotentRecord existingRecord = idempotentRecordMapper
            .selectByBizTypeAndBizId(BIZ_TYPE_ORDER_CREATE, bizId);
            
        if(existingRecord != null) {
            return handleExistingRecord(orderDTO, bizId, existingRecord);
        }
        
        // 创建新记录
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
        TransactionStatus status = transactionManager.getTransaction(def);
        
        try {
            // 插入幂等记录
            IdempotentRecord record = new IdempotentRecord();
            record.setBizType(BIZ_TYPE_ORDER_CREATE);
            record.setBizId(bizId);
            record.setStatus(0);
            record.setRequestParams(JsonUtils.toJson(orderDTO));
            record.setExpireTime(new Date(System.currentTimeMillis() + PROCESS_TIMEOUT));
            
            if(idempotentRecordMapper.insert(record) <= 0) {
                throw new BusinessException("幂等记录创建失败");
            }
            
            // 创建订单
            OrderVO orderVO = createNewOrder(orderDTO, bizId);
            
            // 更新幂等记录
            record.setStatus(1);
            record.setResultData(JsonUtils.toJson(orderVO));
            record.setRetryCount(0);
            idempotentRecordMapper.updateByPrimaryKeySelective(record);
            
            transactionManager.commit(status);
            return orderVO;
        } catch (DuplicateKeyException e) {
            transactionManager.rollback(status);
            log.warn("幂等记录冲突，orderNo={}", bizId);
            return handleExistingRecord(orderDTO, bizId, 
                idempotentRecordMapper.selectByBizTypeAndBizId(BIZ_TYPE_ORDER_CREATE, bizId));
        } catch (Exception e) {
            transactionManager.rollback(status);
            log.error("订单创建失败", e);
            throw new BusinessException("订单创建失败：" + e.getMessage());
        }
    }

    private OrderVO handleExistingRecord(OrderDTO orderDTO, String bizId, IdempotentRecord record) {
        // 处理超时记录
        if(record.getStatus() == 0 && 
           System.currentTimeMillis() > record.getExpireTime().getTime()) {
            log.warn("处理超时记录，orderNo={}", bizId);
            record.setStatus(2);
            record.setResultData("处理超时");
            idempotentRecordMapper.updateByPrimaryKeySelective(record);
            throw new BusinessException("请求处理超时，请重试");
        }
        
        // 根据状态处理
        switch(record.getStatus()) {
            case 1: // 处理成功
                return JsonUtils.fromJson(record.getResultData(), OrderVO.class);
            case 0: // 处理中
                throw new BusinessException("请求处理中，请稍后查询");
            case 2: // 处理失败
                if(record.getRetryCount() < MAX_RETRY_COUNT) {
                    return retryCreateOrder(orderDTO, bizId, record);
                }
                throw new BusinessException("请求处理失败，请检查后重试");
            default:
                throw new BusinessException("未知状态");
        }
    }
    
    // 其他辅助方法...
}

3.2.3 适用场景分析

典型应用场景

1. 金融交易类业务：

   • 支付订单处理
   • 转账交易处理
   • 余额变动操作

2. 订单处理类业务：

   • 订单创建
   • 订单状态变更
   • 订单退款

3. 资源控制类业务：

   • 优惠券发放
   • 库存扣减
   • 会员积分变更

场景选择建议

• 适合读写比例低的业务（写操作不频繁）
• 适合事务性要求高的业务
• 适合业务标识容易生成的场景
• 不适合超高并发写入场景（如秒杀）

3.2.4 优缺点深入分析

优势详解

1. 数据强一致性：

   • 数据库唯一约束是ACID特性保障
   • 不受应用重启影响
   • 支持分布式环境

2. 实现简单：

   • 无需引入额外组件
   • 现有业务系统容易改造
   • 开发人员理解成本低

3. 维护方便：

   • 可通过SQL直接查询状态
   • 记录可长期保存用于审计
   • 问题排查方便

局限性及解决方案

1. 性能瓶颈：

   • 问题：高并发下数据库写入压力大
   • 方案：引入缓存层减轻数据库压力

2. 灵活性不足：

   • 问题：业务标识规则不易变更
   • 方案：设计可扩展的业务标识规则

3. 异常处理复杂：

   • 问题：需要处理各种冲突场景
   • 方案：封装统一的幂等处理框架

优化建议

1. 定期清理过期记录（建立定时任务）
2. 对热点业务做分库分表
3. 添加监控报警机制
4. 考虑读写分离架构

3.3 基于分布式锁的幂等性方案

3.3.1 实现原理

分布式锁的实现需要满足三个关键特性：

1. 互斥性：在任何时刻，只有一个客户端能够持有锁，确保同一业务操作不会被并发执行。
2. 安全性：锁必须能够被正确释放，避免死锁情况发生。即使客户端崩溃，锁也应该在合理时间内自动释放。
3. 可用性：锁服务本身需要具备高可用性，不能成为系统的单点故障。

实际应用中常用的分布式锁实现方式包括：

• Redis分布式锁：基于Redis的SETNX命令实现，性能高，实现简单
• ZooKeeper分布式锁：基于临时顺序节点实现，可靠性高但性能相对较低
• 数据库分布式锁：基于数据库唯一索引或乐观锁实现

Redis分布式锁实现示例

Redis分布式锁通常使用以下命令实现：

SET lockKey lockValue NX EX expireTime

其中：

• NX：表示"只有key不存在时才设置"，确保互斥性
• EX：设置key的过期时间，单位为秒
• expireTime：锁的自动过期时间，防止死锁

典型的工作流程如下：

1. 客户端生成基于业务唯一标识的锁Key，如：

   • 订单创建："LOCK_ORDER_CREATE_20240520123456789"
   • 支付处理："LOCK_PAYMENT_PROCESS_20240520123456789"

2. 客户端向Redis发送SET命令尝试获取锁：

   • 成功（返回OK）：获取到锁，可以执行业务逻辑
   • 失败（返回nil）：锁已被其他客户端持有

3. 业务逻辑执行完成后，客户端通过DEL命令释放锁

3.3.2 关键问题处理

锁过期问题

问题场景：

• 业务逻辑执行时间超过锁的过期时间
• 其他请求在此期间获取到锁并执行
• 导致同一业务操作被重复执行

解决方案：

1. 锁续期机制：

   • 启动后台线程定期延长锁的过期时间（如每隔10秒续期一次）
   • 使用Redis的PEXPIRE命令进行续期
   • 确保业务逻辑执行期间锁始终有效

2. 合理设置过期时间：

   • 根据业务逻辑的平均执行时间设置足够长的过期时间
   • 一般建议设置为平均执行时间的3-5倍

锁释放问题

问题场景：

1. 客户端获取锁后崩溃，无法正常释放锁
2. 锁被长时间占用，其他请求无法获取锁

解决方案：

1. 设置自动过期时间：

   • 即使客户端崩溃，锁也会在过期后自动释放
   • 过期时间应足够业务逻辑完成，但又不能过长

2. 锁值校验机制：

   • 为每个锁设置唯一值（如UUID）
   • 释放锁时先校验当前锁值是否匹配
   • 防止误删其他客户端获取的锁

3.3.3 代码示例（基于Redis分布式锁）

@Service
public class OrderService {
    @Autowired
    private StringRedisTemplate redisTemplate;
    @Autowired
    private OrderMapper orderMapper;
    
    // 锁过期时间（30秒）
    private static final long LOCK_EXPIRE_TIME = 30 * 1000;
    // 锁续期间隔（10秒）
    private static final long LOCK_RENEW_INTERVAL = 10 * 1000;

    public OrderVO createOrder(OrderDTO orderDTO) {
        // 1. 生成基于业务唯一标识的锁Key
        String orderNo = orderDTO.getOrderNo();
        String lockKey = "LOCK_ORDER_CREATE_" + orderNo;
        // 生成唯一的锁Value（用于释放锁时校验）
        String lockValue = UUID.randomUUID().toString();

        // 2. 尝试获取分布式锁
        Boolean lockAcquired = redisTemplate.opsForValue()
            .setIfAbsent(lockKey, lockValue, LOCK_EXPIRE_TIME, TimeUnit.MILLISECONDS);
        if (lockAcquired == null || !lockAcquired) {
            throw new BusinessException("请求处理中，请稍后再试");
        }

        // 3. 启动锁续期线程
        ScheduledExecutorService renewExecutor = Executors.newSingleThreadScheduledExecutor();
        renewExecutor.scheduleAtFixedRate(() -> {
            String currentValue = redisTemplate.opsForValue().get(lockKey);
            if (lockValue.equals(currentValue)) {
                redisTemplate.expire(lockKey, LOCK_EXPIRE_TIME, TimeUnit.MILLISECONDS);
            }
        }, 0, LOCK_RENEW_INTERVAL, TimeUnit.MILLISECONDS);

        try {
            // 4. 校验订单是否已存在
            Order existingOrder = orderMapper.selectByOrderNo(orderNo);
            if (existingOrder != null) {
                return convertToOrderVO(existingOrder);
            }

            // 5. 执行创建订单业务逻辑
            Order order = new Order();
            order.setOrderNo(orderNo);
            order.setUserId(orderDTO.getUserId());
            order.setAmount(orderDTO.getAmount());
            order.setStatus(1);
            orderMapper.insert(order);
            
            return convertToOrderVO(order);
        } finally {
            // 6. 停止锁续期线程并释放锁
            renewExecutor.shutdown();
            String currentValue = redisTemplate.opsForValue().get(lockKey);
            if (lockValue.equals(currentValue)) {
                redisTemplate.delete(lockKey);
            }
        }
    }

    private OrderVO convertToOrderVO(Order order) {
        // 转换逻辑实现
    }
}

3.3.4 适用场景

1. 高并发业务场景：

   • 秒杀系统中的订单创建
   • 库存扣减操作
   • 支付处理等核心业务

2. 分布式系统环境：

   • 跨服务节点的业务操作
   • 微服务架构中的关键业务处理
   • 需要保证全局唯一性的操作

3. 短时高频操作：

   • 需要快速响应和释放的场景
   • 对性能要求较高的业务处理

3.3.5 优缺点

优点

1. 高性能：

   • 基于Redis等内存数据库实现，响应速度快
   • 适合高并发场景，TPS可达万级

2. 灵活性：

   • 可自定义锁的过期时间和续期策略
   • 支持复杂的业务场景需求

3. 减轻数据库压力：

   • 幂等性控制在缓存层完成
   • 减少对数据库的直接访问

缺点

1. 系统复杂度增加：

   • 需要引入Redis等中间件
   • 增加了锁管理的复杂性

2. 实现难度较高：

   • 需要处理锁续期、锁释放等边界情况
   • 错误处理逻辑复杂

3. 依赖中间件可用性：

   • Redis集群故障会影响幂等性控制
   • 需要保证锁服务的高可用性

4. 网络延迟影响：

   • 网络不稳定可能导致锁操作失败
   • 需要合理的重试机制

3.4 基于乐观锁的幂等性方案

基于乐观锁的方案核心思想是：假设业务操作不会发生并发冲突，在执行业务更新操作时，通过版本号或时间戳等字段校验数据是否被修改过；若未被修改，则执行更新操作；若已被修改，则说明存在并发请求，放弃更新操作或重试，从而实现幂等性。

3.4.1 实现原理

乐观锁通常通过在数据库表中增加一个版本号字段（如version）或时间戳字段（如update_time）来实现。以版本号为例，具体流程如下：

1. 表结构设计： 在业务表中增加version字段，默认值为1。例如，订单表结构：

   CREATE TABLE `order` (
     `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
     `order_no` varchar(50) NOT NULL COMMENT '订单号',
     `user_id` bigint(20) NOT NULL COMMENT '用户ID',
     `amount` decimal(10,2) NOT NULL COMMENT '订单金额',
     `status` tinyint(4) NOT NULL COMMENT '订单状态（1：待支付，2：已支付，3：已取消）',
     `version` int(11) NOT NULL DEFAULT '1' COMMENT '版本号',
     `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
     `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
     PRIMARY KEY (`id`),
     UNIQUE KEY `uk_order_no` (`order_no`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT '订单表';
   

2. 查询数据： 执行业务更新操作前，查询数据并获取当前版本号。例如，查询订单状态：

   SELECT id, order_no, status, version FROM `order` WHERE order_no = '20240520123456789';
   

3. 更新数据： 执行更新操作时，在WHERE条件中加入版本号校验，确保只有版本号匹配的数据才会被更新，同时将版本号加1。例如，更新订单状态为"已支付"：

   UPDATE `order`
   SET status = 2, version = version + 1
   WHERE order_no = '20240520123456789' AND version = 1;
   

4. 校验结果： 判断更新操作影响的行数（affectedRows）：

   • 若affectedRows > 0，说明更新成功（数据未被其他请求修改）；
   • 若affectedRows = 0，说明数据已被其他请求修改，当前请求为重复请求或并发请求，放弃更新或重试。

3.4.2 代码示例

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;

    // 支付订单（更新订单状态）
    public boolean payOrder(String orderNo) {
        // 1. 循环重试（可选，根据业务需求决定是否重试）
        int retryCount = 3;
        while (retryCount > 0) {
            // 2. 查询订单当前信息（包含版本号）
            Order order = orderMapper.selectByOrderNoWithVersion(orderNo);
            if (order == null) {
                throw new BusinessException("订单不存在");
            }
            if (order.getStatus() == 2) {
                // 订单已支付，直接返回成功（幂等性处理）
                return true;
            }

            // 3. 执行更新操作（版本号校验）
            int affectedRows = orderMapper.updateOrderStatusByVersion(
                orderNo, 2, order.getVersion() // 目标状态：2（已支付），当前版本号
            );

            if (affectedRows > 0) {
                // 更新成功，返回true
                return true;
            } else {
                // 更新失败（版本号不匹配），重试
                retryCount--;
                try {
                    // 重试前休眠，避免频繁重试
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        }
        // 重试次数耗尽，返回失败
        throw new BusinessException("支付失败，请稍后重试");
    }
}

// Mapper接口
public interface OrderMapper {
    // 查询订单（包含版本号）
    Order selectByOrderNoWithVersion(@Param("orderNo") String orderNo);

    // 基于版本号更新订单状态
    int updateOrderStatusByVersion(
        @Param("orderNo") String orderNo,
        @Param("targetStatus") int targetStatus,
        @Param("currentVersion") int currentVersion
    );
}

// Mapper XML
<select id="selectByOrderNoWithVersion" resultType="com.example.entity.Order">
    SELECT id, order_no, user_id, amount, status, version
    FROM `order`
    WHERE order_no = #{orderNo}
</select>

<update id="updateOrderStatusByVersion">
    UPDATE `order`
    SET status = #{targetStatus}, version = version + 1
    WHERE order_no = #{orderNo} AND version = #{currentVersion}
</update>

3.4.3 适用场景

• 并发更新场景（如订单状态更新、商品库存扣减）：乐观锁能有效处理并发更新时的数据一致性问题，避免重复更新。
• 对性能要求较高，且并发冲突概率较低的场景：乐观锁无需提前获取锁，只有在更新时才校验数据，性能优于悲观锁和分布式锁，适合冲突概率低的场景。

3.4.4 优缺点

• 优点：

  • 无需引入额外中间件，实现成本低；
  • 无锁竞争，性能高，适合高并发且冲突概率低的场景；
  • 代码侵入性低，只需在表中增加版本号字段和修改更新SQL。

• 缺点：

  • 若并发冲突概率高，会导致大量重试，增加系统开销；
  • 不适合写密集型场景（冲突概率高）；
  • 需要处理重试逻辑，若重试次数设置不合理，可能导致请求失败。

四、分布式幂等性方案对比与选型建议

方案对比表

方案类型	基于唯一标识（Token）	基于数据库唯一索引	基于分布式锁	基于乐观锁
核心依赖	Redis / 数据库	关系型数据库	Redis/ZooKeeper	关系型数据库
适用场景	前端表单提交、重要业务操作（支付、转账）	数据库强绑定场景、数据一致性要求高的业务	高并发核心业务（秒杀、库存扣减）	并发更新场景、冲突概率低的写操作
优点	1. 逻辑清晰<br>2. 业务侵入性低<br>3. 支持高并发	1. 无需额外中间件<br>2. 一致性强<br>3. 实现成本低	1. 响应快<br>2. 适合跨服务场景<br>3. 灵活性高	1. 无锁竞争<br>2. 性能高<br>3. 实现成本低
缺点	1. 增加Token申请请求<br>2. 依赖中间件高可用	1. 依赖数据库性能<br>2. 高并发下可能成为瓶颈	1. 依赖中间件<br>2. 需处理锁过期、续期等问题	1. 冲突概率高时重试频繁<br>2. 不适合写密集场景
并发性能	高（1000+ TPS）	中（500-1000 TPS）	高（1000+ TPS）	高（1000+ TPS）
实现复杂度	低（1-2天）	低（1-2天）	中（3-5天）	低（1-2天）

典型应用场景示例

1. Token方案：

   • 电商支付系统：用户提交订单时生成支付Token，防止重复支付
   • 银行转账系统：每笔转账请求需先获取唯一交易ID

2. 数据库唯一索引：

   • 用户注册系统：用户名使用唯一索引防止重复注册
   • 订单系统：订单号设置唯一索引保证订单唯一性

3. 分布式锁：

   • 秒杀系统：使用Redis分布式锁控制库存扣减
   • 优惠券发放：防止超发

4. 乐观锁：

   • 订单状态更新：通过version字段控制并发更新
   • 账户余额变更：CAS操作更新余额

选型建议

1. 优先考虑业务场景匹配度

• 前端重复提交/跨服务重要业务：优先选择Token方案
  • 典型场景：支付系统、财务系统
  • 实现示例：前端提交前先调用/api/token接口获取Token，提交时携带Token
• 数据库强绑定/高一致性要求：选择数据库唯一索引
  • 典型场景：用户中心、基础数据管理
  • 实现示例：ALTER TABLE orders ADD UNIQUE INDEX idx_order_no (order_no)
• 高并发核心业务：选择分布式锁
  • 典型场景：秒杀、库存管理
  • 实现示例：SET lock_key 1 NX EX 30
• 并发更新/低冲突场景：选择乐观锁
  • 典型场景：状态更新、计数器
  • 实现示例：UPDATE account SET balance=balance-100, version=version+1 WHERE id=123 AND version=1

2. 兼顾性能与复杂度

• 高并发场景（>1000TPS）：
  • 优先选择Redis方案（Token或分布式锁）
  • 避免数据库方案成为瓶颈
• 技术储备有限：
  • 优先选择简单方案（乐观锁/唯一索引）
  • 分布式锁需要处理：锁续期、死锁、锁丢失等问题

3. 系统依赖考量

• 已有Redis：
  • 优先使用Redis方案
  • 避免引入新中间件
  • 注意Redis集群模式和持久化配置
• 仅用数据库：
  • 选择数据库方案
  • 需要考虑：
    • 数据库分库分表时唯一索引的实现
    • 主从延迟对一致性的影响

4. 混合方案选择

对于复杂业务场景，可考虑组合使用多种方案：

• 支付系统示例：
  • 对外API：Token方案防止重复提交
  • 核心交易：分布式锁保证处理原子性
  • 数据落库：唯一索引保证最终一致性
• 订单系统示例：
  • 创建订单：Token+唯一索引
  • 修改订单：乐观锁控制并发更新

特别提醒：任何方案选择都需要通过压力测试验证，建议在测试环境模拟200%的预期流量进行验证。

五、分布式幂等性落地实践注意事项

5.1 唯一标识的设计至关重要

在设计唯一标识时，需要考虑以下几个关键方面：

1. 全局唯一性实现方案：

   • UUID：如550e8400-e29b-41d4-a716-446655440000，简单但无序
   • 雪花算法(Snowflake)：如4123456789012345678，包含时间戳、机器ID和序列号
   • 业务字段组合：如订单号ORD20230501123456（前缀+日期+序列）

2. 防篡改机制：

   • 使用HMAC-SHA256等算法签名标识
   • 示例：token=base64(header.claims.signature)
   • 传输时配合HTTPS加密

3. 业务关联设计模式：

   • 支付场景：PAY-{userId}-{timestamp}
   • 订单创建：CREATE-{productId}-{sessionId}
   • 建议采用三段式：[业务类型]-[主体标识]-[时间特征]

5.2 异常处理需全面覆盖

中间件异常应对方案

1. Redis故障处理：

   • 降级方案：本地缓存+Zookeeper监听
   • 重试策略：指数退避（1s, 2s, 4s...）
   • 示例代码：

     try {
         redis.set(key, value, "NX", "EX", 30);
     } catch (RedisException e) {
         localCache.put(key, value);
     }
     

2. 数据库熔断机制：

   • 配置Hystrix熔断阈值（如50%错误率）
   • 熔断后返回503状态码
   • 记录幂等标识到消息队列异步处理

业务异常处理策略

异常类型	处理方式	后续动作
参数错误	标记Token已使用	返回400错误
库存不足	保留幂等记录	通知补货系统
系统异常	设置中间状态	触发告警

并发控制实施方案

1. Redis原子操作：

   SET order:1234 "processing" NX EX 60
   

2. 数据库乐观锁：

   UPDATE orders SET status='paid' 
   WHERE order_id=1234 AND version=5
   

5.3 合理设置过期时间

过期时间计算矩阵

业务类型	平均耗时	建议过期时间	续约机制
支付订单	3s	30s	心跳检测
物流跟踪	2m	10m	任务轮询
报表生成	30m	2h	进度回调

清理策略对比

数据库清理方案：

-- MySQL示例
DELETE FROM idempotent_records 
WHERE create_time < NOW() - INTERVAL 7 DAY
AND status = 'SUCCESS';

Redis清理方案：

• 自动过期（推荐）
• 手动SCAN+DEL（性能差）

过期风险案例：

• 支付场景：设置10s过期，但银行回调需要15s→导致重复支付
• 解决方案：根据业务最长链路时间×2设置

5.4 与业务逻辑的解耦

AOP实现方案示例

1. 注解定义：

   @Target(ElementType.METHOD)
   @Retention(RetentionPolicy.RUNTIME)
   public @interface Idempotent {
       String key() default "";
       int expire() default 30;
   }
   

2. 切面逻辑：

   @Around("@annotation(idempotent)")
   public Object checkIdempotent(ProceedingJoinPoint joinPoint, Idempotent idempotent) {
       String key = generateKey(joinPoint, idempotent);
       if (!redisLock.tryLock(key)) {
           throw new IdempotentException("重复请求");
       }
       return joinPoint.proceed();
   }
   

工具类设计要点

IdempotentUtils功能清单：

1. Token生成（含有效期）
2. 分布式锁获取/释放
3. 幂等记录查询
4. 异常统一处理

使用示例：

public void createOrder(OrderDTO dto) {
    IdempotentUtils.checkRequest(dto.getRequestId());
    // 业务逻辑
    orderService.create(dto);
    IdempotentUtils.markComplete(dto.getRequestId());
}

5.5 充分测试验证

测试用例矩阵

测试类型	工具	验证指标	通过标准
重复提交	Postman	数据库记录数	=1
并发压测	JMeter	错误率	<0.1%
网络分区	ChaosMesh	数据一致性	最终一致

异常测试场景

1. Redis宕机测试：

   • 步骤：kill -9 redis进程
   • 预期：降级到本地缓存
   • 监控：恢复后数据同步

2. 分布式锁续期测试：

   // 模拟业务阻塞
   Thread.sleep(lockTime+10s);
   // 验证锁是否自动续期
   

3. 时钟漂移测试：

   • 修改服务器时间+1h
   • 验证时间相关唯一标识

性能测试建议

1. 基准测试：

   • 无幂等控制时的TPS
   • 添加幂等后的性能损耗（建议<5%）

2. 混合场景测试：

   • 新请求+重试请求按比例混合
   • 典型比例：80%新请求+20%重试

3. 长期运行测试：

   • 持续运行24h
   • 检查内存泄漏（如未清理的幂等记录）