幂等性实践操作，基于业务讲解幂等性

之前面试也提到过关于幂等的问题，自己百度查了关于它的概念倒是很简单，但就一直不是很理解，今天和人讨论一下，然后再自己结合实际理解了一下。

• 幂等概念来自数学，表示N次变换和1次变换的结果是相同的。这里讨论在某些场景下，客户端在调用服务没有达到预期结果时，会进行多次调用，为避免多次重复的调用对服务资源产生副作用，服务提供者会承诺满足幂等。

• HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的副作用（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

• 简单来说就是：多次调用同一个接口，返回的结果是同样的。

其实我们在实际代码中可能已经做过了幂等但是因为不知道这个概念导致我们不清楚（其实这样的情况还挺多）

单说概念可能大家并不是很理解，下面举两个例子，一个是我同事给我讲的，一个是我之前的实际例子。

一、

在工单系统里面有一个接单的操作，一个工单可以派发给多个人，每个人都可以接单，规则是谁先接到就算谁的。

如果我们不对其进行幂等处理那就会发生第二个人覆盖了第一个人的接单。

错误操作如下：
工单下派给A、B两个人，然后A、B同时进入接单界面，这时候A接单了，但是B来电话了，他去接电话，接完电话他还停留在接单界面，然后他也接单了。

改造如下：

1. 每次进来先获取Redis里面的 key，判断是否存在，如果不存在就继续往下走
2. 判断当前工单的状态，是否等于待接收，如果是继续往下走
3. 使用工单id作为 key 存入Redis里面去（分布式锁实现）
4. 执行一系列的业务逻辑
5. 删除Redis里面的key

伪代码实现：

public String fun(String id) {
    if (RedisUtils.get(id) != null) {
        return "该工单已被接收";
    }
    RedisUtils.put(id,id);
    if (testDao.getStateById(id) != 3) {
        return "该工单已被接收";
    }
    // 执行具体的业务逻辑
    //......

    if (RedisUtils.get(id) != null) {
        RedisUtils.delete(id);
    }
    return "操作成功";
}

二、

这是一个典型的支付场景：用户支付下单场景，理论上一个订单用户只能支付一次，但是如果不做幂等处理就可能支付多次。

错误操作如下：

因为网络或者各种原因卡住了，用户刷新页面再次点击支付，这样会造成支付两次的情况

改造如下：

1. 每次点击支付后锁住按钮。（但是刷新页面会导致解开锁）
2. 支付完成后返回给前端，前端跳到支付成功页面。
3. 每次进来先获取Redis里面的 key，判断是否存在，如果不存在就继续往下走
4. 判断当前订单的状态，是否等于待支付，如果是继续往下走
5. 使用订单id作为 key 存入Redis里面去（分布式锁实现）
6. 执行一系列的业务逻辑
7. 删除Redis里面的key

这个和上面的代码实现如出一辙就不再写了。