接口幂等性的一些思考

思考？

1. 如何保证提交订单按钮防止重复提交

2.表单录入页如何防止重复提交？

3. 微服务接口，客户端重试时候，会对业务数据产生影响吗？

什么是幂等性？

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

幂等性： 幂等元素运行多次， 还等于它原来的运算结果

在系统中，一个接口运行多次，与运行一次的效果是一致的

任意多次执行所产生的影响均与一次执行的影响相同，这是幂等性的核心特点。其实在我们编程中主要操作就是CURD，其中读取（Retrieve）操作和删除（Delete）操作是天然幂等的，受影响的就是创建（Create）、更新（Update）。

一. 什么时候要进行幂等性设计？

1. 重复提交，接口重试，前端操作抖动等

2. 业务场景，用户多次点击提交订单，后台只应生成一个订单

3. 支付时候，由于网络的抖动，应该只扣一次钱

4.消息重复消费：MQ消息中间件，消息重复消费

3.幂等性的实现方式

对于和web端交互的接口，我们可以在前端拦截一部分，例如防止表单重复提交，按钮置灰、隐藏、不可点击等方式。

但是前端做控制实际效益不是很高，懂点技术的都会模拟请求调用你的服务，所以安全的策略还是需要从后端的接口层来做。

那么后端要实现分布式接口的幂等性有哪些策略方式呢？主要可以从以下几个方面来考虑实现：

|1Token机制

针对前端重复连续多次点击的情况，例如用户购物提交订单，提交订单的接口就可以通过 Token 的机制实现防止重复提交。

主要流程就是：

1. 服务端提供了发送token的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。（微服务肯定是分布式了，如果单机就适用jvm缓存）。
2. 然后调用业务接口请求时，把token携带过去，一般放在请求头部。
3. 服务器判断token是否存在redis中，存在表示第一次请求，这时把redis中的token删除，继续执行业务。
4. 如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行。

2. 并发的情况下，整个操作过程加锁

1. 大量的并发请求，直接加锁处理（加分布式锁）注意：写操作

二：增删改查数据分析

1. select 操作：不会对业务数据有影响，天然幂等性

2. delete操作，第一次操作已经操作删除了，第二次也不会有影响

3.update操作更新操作传入数据版本号，通过乐观锁实现幂等性（比如更新的时候加1，更新5次，就加5次，所以要使用幂等保证）

4.insert操作，此时没有唯一业务单号，使用Token保证幂等性等。

混合操作：找到操作的唯一业务单号，有则使用分布式锁，没有可以通过Token保证幂等

Update操作的幂等性

1. 根据唯一业务号去更新数据的情况

2. 用户查询出要修改的数据，系统将数据返回页面，将数据版本号放入隐藏域中，

3.后台使用版本号作为更新条件

update set version = version+1 ,xxx = ${xxx} where id = xxx and version = ${version}

1. 当然：下面这样的更新操作不用去考虑幂等性：

例如： 我要更新用户表中一个数据名字为：张三，这时：上一个数据没返回，我再请求一次，最后的结果还是为张三，可以不用去考虑幂等性

2. 什么时候更新操作会考虑幂等性呢？

例如：我表中有个字段去记录优惠券的消费使用情况数据，每次更新＋1，这个时候，点一次没相应，我再点一次，点两次就加了两次（用户的目的就是加一次）通过使用乐观锁去保证

数据库去重表

往去重表里插入数据的时候，利用数据库的唯一索引特性，保证唯一的逻辑。唯一序列号可以是一个字段，例如订单的订单号，也可以是多字段的唯一性组合。例如设计如下的数据库表。

CREATE TABLE `t_idempotent` (
  `id` int(11) NOT NULL COMMENT 'ID',
  `serial_no` varchar(255)  NOT NULL COMMENT '唯一序列号',
  `source_type` varchar(255)  NOT NULL COMMENT '资源类型',
  `status` int(4) DEFAULT NULL COMMENT '状态',
  `remark` varchar(255)  NOT NULL COMMENT '备注',
  `create_by` bigint(20) DEFAULT NULL COMMENT '创建人',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `modify_by` bigint(20) DEFAULT NULL COMMENT '修改人',
  `modify_time` datetime DEFAULT NULL COMMENT '修改时间',
  PRIMARY KEY (`id`)
  UNIQUE KEY `key_s` (`serial_no`,`source_type`, `remark`)  COMMENT '保证业务唯一性'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='幂等性校验表';

我们注意看如下这几个关键性字段，

• serial_no：唯一序列号的值，在这里我设置的是通过注解@IdempotentKey来标识请求对象中的字段，通过对他们 MD5 加密获取对应的值。
• source_type：业务类型，区分不同的业务，订单，支付等。
• remark：是由标识字段的拼接成的字符串，拼接符为 “|”。

由于数据建立了 serial_no,source_type, remark 三个字段组合构成的唯一索引，所以可以通过这个来去重达到接口的幂等性，具体的代码设计如下，

public class PaymentOrderReq {

    /**
     * 支付宝流水号
     */
    @IdempotentKey(order=1)
    private String alipayNo;

    /**
     * 支付订单ID
     */
    @IdempotentKey(order=2)
    private String paymentOrderNo;

    /**
     * 支付金额
     */
    private Long amount;
}

因为支付宝流水号和订单号在系统中是唯一的，所以唯一序列号可由他们组合 MD5 生成，具体的生成方式如下：

private void getIdempotentKeys(Object keySource, Idempotent idempotent) {
    TreeMap<Integer, Object> keyMap = new TreeMap<Integer, Object>();
    for (Field field : keySource.getClass().getDeclaredFields()) {
        if (field.isAnnotationPresent(IdempotentKey.class)) {
            try {
                field.setAccessible(true);
                keyMap.put(field.getAnnotation(IdempotentKey.class).order(),
                        field.get(keySource));
            } catch (IllegalArgumentException | IllegalAccessException e) {
                logger.error("", e);
                return;
            }
        }
    }
    generateIdempotentKey(idempotent, keyMap.values().toArray());
}

生成幂等Key，如果有多个key可以通过分隔符 "|" 连接，

private void generateIdempotentKey(Idempotent idempotent, Object... keyObj) {
     if (keyObj.length == 0) {
         logger.info("idempotentkey is empty,{}", keyObj);
         return;
     }
     StringBuilder serialNo= new StringBuilder();
     for (Object key : keyObj) {
         serialNo.append(key.toString()).append("|");
     }
     idempotent.setRemark(serialNo.toString());
     idempotent.setSerialNo(md5(serialNo));
 }

一切准备就绪，则可对外提供幂等性校验的接口方法，接口方法为：

public <T> void idempotentCheck(IdempotentTypeEnum idempotentType, T keyObj) throws IdempotentException {
    Idempotent idempotent = new Idempotent();
    getIdempotentKeys(keyObj, idempotent );
    if (StringUtils.isBlank(idempotent.getSerialNo())) {
        throw new ServiceException("fail to get idempotentkey");
    }
    idempotentEvent.setSourceType(idempotentType.name());
    try {
        idempotentMapper.saveIdempotent(idempotent);
    } catch (DuplicateKeyException e) {
        logger.error("idempotent check fail", e);
        throw new IdempotentException(idempotent);
    }
}

当然这个接口的方法具体在项目中合理的使用就看项目要求了，可以通过@Autowire注解注入到需要使用的地方，但是缺点就是每个地方都需要调用。我个人推荐的是自定义一个注解，在需要幂等性保证的接口上加上该注解，然后通过拦截器方法拦截使用。这样简单便不会造成代码侵入和污染。

另外，使用数据库防重表的方式它有个严重的缺点，那就是系统容错性不高，如果幂等表所在的数据库连接异常或所在的服务器异常，则会导致整个系统幂等性校验出问题。如果做数据库备份来防止这种情况，又需要额外忙碌一通了啊。

3|3Redis实现

 

上面介绍过防重表的设计方式和伪代码，也说过它的一个很明显的缺点。所以我们另外介绍一个Redis的实现方式。

Redis实现的方式就是将唯一序列号作为Key，唯一序列号的生成方式和上面介绍的防重表的一样，value可以是你想填的任何信息。唯一序列号也可以是一个字段，例如订单的订单号，也可以是多字段的唯一性组合。当然这里需要设置一个 key 的过期时间，否则 Redis 中会存在过多的 key。具体校验流程如下图所示，实现代码也很简单这里就不写了。

由于企业如果考虑在项目中使用 Redis，因为大部分会拿它作为缓存来使用，那么一般都会是集群的方式出现，至少肯定也会部署两台Redis服务器。所以我们使用Redis来实现接口的幂等性是最适合不过的了。

3|4状态机

对于很多业务是有一个业务流转状态的，每个状态都有前置状态和后置状态，以及最后的结束状态。例如流程的待审批，审批中，驳回，重新发起，审批通过，审批拒绝。订单的待提交，待支付，已支付，取消。

以订单为例，已支付的状态的前置状态只能是待支付，而取消状态的前置状态只能是待支付，通过这种状态机的流转我们就可以控制请求的幂等。

public enum OrderStatusEnum {

    UN_SUBMIT(0, 0, "待提交"),
    UN_PADING(0, 1, "待支付"),
    PAYED(1, 2, "已支付待发货"),
    DELIVERING(2, 3, "已发货"),
    COMPLETE(3, 4, "已完成"),
    CANCEL(0, 5, "已取消"),
    ;

    //前置状态
    private int preStatus;

    //状态值
    private int status;

    //状态描述
    private String desc;

    OrderStatusEnum(int preStatus, int status, String desc) {
        this.preStatus = preStatus;
        this.status = status;
        this.desc = desc;
    }

    //...
}

假设当前状态是已支付，这时候如果支付接口又接收到了支付请求，则会抛异常或拒绝此次处理。

4|0总结

 

通过以上的了解我们可以知道，针对不同的业务场景我们需要灵活的选择幂等性的实现方式。

例如防止类似于前端重复提交、重复下单的场景就可以通过 Token 的机制实现，而那些有状态前置和后置转换的场景则可以通过状态机的方式实现幂等性，对于那些重复消费和接口重试的场景则使用数据库唯一索引的方式实现更合理。