一文搞定接口幂等性架构设计方案

Posted 2023-04-20 博学谷狂野架构师

幂等性介绍

现如今很多系统都会基于分布式或微服务思想完成对系统的架构设计。那么在这一个系统中，就会存在若干个微服务，而且服务间也会产生相互通信调用。那么既然产生了服务调用，就必然会存在服务调用延迟或失败的问题。当出现这种问题，服务端会进行重试等操作或客户端有可能会进行多次点击提交。如果这样请求多次的话，那最终处理的数据结果就一定要保证统一，如支付场景。此时就需要通过保证业务幂等性方案来完成。

什么是幂等性

幂等是一个数学与计算机学概念，即f(n) = 1^n，无论n为多少，f(n)的值永远为1，在数学中某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同。

在编程开发中，对于幂等的定义为：无论对某一个资源操作了多少次，其影响都应是相同的。 换句话说就是：在接口重复调用的情况下，对系统产生的影响是一样的，但是返回值允许不同，如查询。

幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

幂等性不仅仅只是一次或多次操作对资源没有产生影响，还包括第一次操作产生影响后，以后多次操作不会再产生影响。并且幂等关注的是是否对资源产生影响，而不关注结果。

幂等性维度

幂等性设计主要从两个维度进行考虑：空间、时间。

• 空间：定义了幂等的范围，如生成订单的话，不允许出现重复下单。
• 时间：定义幂等的有效期。有些业务需要永久性保证幂等，如下单、支付等。而部分业务只要保证一段时间幂等即可。

同时对于幂等的使用一般都会伴随着出现锁的概念，用于解决并发安全问题。

以SQL为例

• select * from table where id=1。此SQL无论执行多少次，虽然结果有可能出现不同，都不会对数据产生改变，具备幂等性。
• insert into table(id,name) values(1,\'heima\')。此SQL如果id或name有唯一性约束，多次操作只允许插入一条记录，则具备幂等性。如果不是，则不具备幂等性，多次操作会产生多条数据。
• update table set score=100 where id = 1。此SQL无论执行多少次，对数据产生的影响都是相同的。具备幂等性。
• update table set score=50+score where id = 1。此SQL涉及到了计算，每次操作对数据都会产生影响。不具备幂等性。
• delete from table where id = 1。此SQL多次操作，产生的结果相同，具备幂等性。

什么是接口幂等性

在HTTP/1.1中，对幂等性进行了定义。

它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。

这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

为什么需要实现幂等性

使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。

在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题：

前端重复提交表单

在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。

用户恶意进行刷单

例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。

接口超时重复提交

很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。

消息进行重复消费

当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

引入幂等性后对系统有什么影响

幂等性是为了简化客户端逻辑处理，能放置重复提交等操作，但却增加了服务端的逻辑复杂性和成本，其主要是：

1. 把并行执行的功能改为串行执行，降低了执行效率。
2. 增加了额外控制幂等的业务逻辑，复杂化了业务功能；

所以在使用时候需要考虑是否引入幂等性的必要性，根据实际业务场景具体分析，除了业务上的特殊要求外，一般情况下不需要引入的接口幂等性。

Restful API 接口幂等

现在流行的 Restful 推荐的几种 HTTP 接口方法中，分别存在幂等行与不能保证幂等的方法，如下：

HTTP协议语义幂等性

HTTP协议有两种方式：RESTFUL、SOA。现在对于WEB API，更多的会使用RESTFUL风格定义。为了更好的完成接口语义定义，HTTP对于常用的四种请求方式也定义了幂等性的语义。

• GET：用于获取资源，多次操作不会对数据产生影响，具有幂等性。注意不是结果。
• POST：用于新增资源，对同一个URI进行两次POST操作会在服务端创建两个资源，不具有幂等性。
• PUT：用于修改资源，对同一个URI进行多次PUT操作，产生的影响和第一次相同，具备幂等性。
• DELETE：用于删除资源，对同一个URI进行多次DELETE操作，产生的影响和第一次相同，具备幂等性

综上所述，这些仅仅只是HTTP协议建议在基于RESTFUL风格定义WEB API时的语义，并非强制性。同时对于幂等性的实现，肯定是通过前端或服务端完成。

业务问题抛出

在业务开发与分布式系统设计中，幂等性是一个非常重要的概念，有非常多的场景需要考虑幂等性的问题，尤其对于现在的分布式系统，经常性的考虑重试、重发等操作，一旦产生这些操作，则必须要考虑幂等性问题。以交易系统、支付系统等尤其明显，如：

• 当用户购物进行下单操作，用户操作多次，但订单系统对于本次操作只能产生一个订单。
• 当用户对订单进行付款，支付系统不管出现什么问题，应该只对用户扣一次款。
• 当支付成功对库存扣减时，库存系统对订单中商品的库存数量也只能扣减一次。
• 当对商品进行发货时，也需保证物流系统有且只能发一次货。

在电商系统中还有非常多的场景需要保证幂等性。但是一旦考虑幂等后，服务逻辑务必会变的更加复杂。因此是否要考虑幂等，需要根据具体业务场景具体分析。而且在实现幂等时，还会把并行执行的功能改为串行化，降低了执行效率。

此处以下单减库存为例，当用户生成订单成功后，会对订单中商品进行扣减库存。 订单服务会调用库存服务进行库存扣减。库存服务会完成具体扣减实现。

现在对于功能调用的设计，有可能出现调用超时，因为出现如网络抖动，虽然库存服务执行成功了，但结果并没有在超时时间内返回，则订单服务也会进行重试。那就会出现问题，stock对于之前的执行已经成功了，只是结果没有按时返回。而订单服务又重新发起请求对商品进行库存扣减。 此时出现库存扣减两次的问题。 对于这种问题，就需要通过幂等性进行结果。

解决方案

对于幂等的考虑，主要解决两点前后端交互与服务间交互。这两点有时都要考虑幂等性的实现。从前端的思路解决的话，主要有三种：前端防重、PRG模式、Token机制。

前端防重

通过前端防重保证幂等是最简单的实现方式，前端相关属性和JS代码即可完成设置。可靠性并不好，有经验的人员可以通过工具跳过页面仍能重复提交。主要适用于表单重复提交或按钮重复点击。

PRG模式

PRG模式即POST-REDIRECT-GET。当用户进行表单提交时，会重定向到另外一个提交成功页面，而不是停留在原先的表单页面。这样就避免了用户刷新导致重复提交。同时防止了通过浏览器按钮前进/后退导致表单重复提交。是一种比较常见的前端防重策略。

Token模式

通过token机制来保证幂等是一种非常常见的解决方案，同时也适合绝大部分场景。该方案需要前后端进行一定程度的交互来完成。

Token防重实现

针对客户端连续点击或者调用方的超时重试等情况，例如提交订单，此种操作就可以用 Token 的机制实现防止重复提交。

简单的说就是调用方在调用接口的时候先向后端请求一个全局 ID（Token），请求的时候携带这个全局 ID 一起请求（Token 最好将其放到 Headers 中），后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息，这样来保证幂等操作。

适用操作

• 插入操作
• 更新操作
• 删除操作

使用限制

• 需要生成全局唯一 Token 串
• 需要使用第三方组件 Redis 进行数据效验

主要流程

1. 服务端提供获取 Token 的接口，该 Token 可以是一个序列号，也可以是一个分布式 ID 或者 UUID 串。
2. 客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。
3. 然后将该串存入 Redis 数据库中，以该 Token 作为 Redis 的键（注意设置过期时间）。
4. 将 Token 返回到客户端，客户端拿到后应存到表单隐藏域中。
5. 客户端在执行提交表单时，把 Token 存入到 Headers 中，执行业务请求带上该 Headers。
6. 服务端接收到请求后从 Headers 中拿到 Token，然后根据 Token 到 Redis 中查找该 key 是否存在。
7. 服务端根据 Redis 中是否存该 key 进行判断，如果存在就将该 key 删除，然后正常执行业务逻辑。如果不存在就抛异常，返回重复提交的错误信息。

注意，在并发情况下，执行 Redis 查找数据与删除需要保证原子性，否则很可能在并发下无法保证幂等性。其实现方法可以使用分布式锁或者使用 Lua 表达式来注销查询与删除操作。

实现流程

通过token机制来保证幂等是一种非常常见的解决方案，同时也适合绝大部分场景。该方案需要前后端进行一定程度的交互来完成。

1. 服务端提供获取token接口，供客户端进行使用。服务端生成token后，如果当前为分布式架构，将token存放于redis中，如果是单体架构，可以保存在jvm缓存中。
2. 当客户端获取到token后，会携带着token发起请求。
3. 服务端接收到客户端请求后，首先会判断该token在redis中是否存在。如果存在，则完成进行业务处理，业务处理完成后，再删除token。如果不存在，代表当前请求是重复请求，直接向客户端返回对应标识。

业务执行时机

先执行业务再删除token

但是现在有一个问题，当前是先执行业务再删除token。

在高并发下，很有可能出现第一次访问时token存在，完成具体业务操作。但在还没有删除token时，客户端又携带token发起请求，此时，因为token还存在，第二次请求也会验证通过，执行具体业务操作。

对于这个问题的解决方案的思想就是并行变串行。会造成一定性能损耗与吞吐量降低。

• 第一种方案：对于业务代码执行和删除token整体加线程锁。当后续线程再来访问时，则阻塞排队。
• 第二种方案：借助redis单线程和incr是原子性的特点。当第一次获取token时，以token作为key，对其进行自增。然后将token进行返回，当客户端携带token访问执行业务代码时，对于判断token是否存在不用删除，而是对其继续incr。如果incr后的返回值为2。则是一个合法请求允许执行，如果是其他值，则代表是非法请求，直接返回。

先删除token再执行业务

那如果先删除token再执行业务呢？其实也会存在问题，假设具体业务代码执行超时或失败，没有向客户端返回明确结果，那客户端就很有可能会进行重试，但此时之前的token已经被删除了，则会被认为是重复请求，不再进行业务处理。

这种方案无需进行额外处理，一个token只能代表一次请求。一旦业务执行出现异常，则让客户端重新获取令牌，重新发起一次访问即可。推荐使用先删除token方案

但是无论先删token还是后删token，都会有一个相同的问题。每次业务请求都回产生一个额外的请求去获取token。但是，业务失败或超时，在生产环境下，一万个里最多也就十个左右会失败，那为了这十来个请求，让其他九千九百多个请求都产生额外请求，就有一些得不偿失了。虽然redis性能好，但是这也是一种资源的浪费。

基于业务实现

生成Token

修改token_service_order工程中OrderController，新增生成令牌方法genToken

@Autowired
private IdWorker idWorker;

@Autowired
private RedisTemplate redisTemplate;

@GetMapping("/genToken")
public String genToken()

    String token = String.valueOf(idWorker.nextId());

    redisTemplate.opsForValue().set(token,0,30, TimeUnit.MINUTES);

    return token;

新增接口

修改token_service_api工程，新增OrderFeign接口。

@FeignClient(name = "order")
@RequestMapping("/order")
public interface OrderFeign 

    @GetMapping("/genToken")
    public String genToken();

获取token

修改token_web_order工程中WebOrderController，新增获取token方法

@RestController
@RequestMapping("worder")
public class WebOrderController 

    @Autowired
    private OrderFeign orderFeign;

    /**
		* 服务端生成token
		* @return
	*/
    @GetMapping("/genToken")
    public String genToken()

        String token = orderFeign.genToken();

        return token;
    

拦截器

修改token_common，新增feign拦截器

@Component
public class FeignInterceptor implements RequestInterceptor 

    @Override
    public void apply(RequestTemplate requestTemplate) 

        //传递令牌
        RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();

        if (requestAttributes != null)

            HttpServletRequest request = ((ServletRequestAttributes) requestAttributes).getRequest();

            if (request != null)

                Enumeration<String> headerNames = request.getHeaderNames();

                while (headerNames.hasMoreElements())

                    String headerName = headerNames.nextElement();

                    if ("token".equals(headerName))

                        String headerValue = request.getHeader(headerName);

                        //传递token
                        requestTemplate.header(headerName,headerValue);
                    
                
            
        
    

启动类

修改token_web_order启动类

@Bean
public FeignInterceptor feignInterceptor()
    return new FeignInterceptor();

新增订单

修改token_service_order中OrderController，新增添加订单方法

/**
     * 生成订单
     * @param order
     * @return
     */
@PostMapping("/genOrder")
public String genOrder(@RequestBody Order order, HttpServletRequest request)

    //获取令牌
    String token = request.getHeader("token");

    //校验令牌
    try 
        if (redisTemplate.delete(token))

            //令牌删除成功，代表不是重复请求，执行具体业务
            order.setId(String.valueOf(idWorker.nextId()));
            order.setCreateTime(new Date());
            order.setUpdateTime(new Date());
            int result = orderService.addOrder(order);

            if (result == 1)
                System.out.println("success");
                return "success";
            else 
                System.out.println("fail");
                return "fail";
            
        else 

            //删除令牌失败，重复请求
            System.out.println("repeat request");
            return "repeat request";
        
    catch (Exception e)
        throw new RuntimeException("系统异常,请重试");
    

修改token_service_order_api中OrderFeign。

@FeignClient(name = "order")
@RequestMapping("/order")
public interface OrderFeign 

    @PostMapping("/genOrder")
    public String genOrder(@RequestBody Order order);

    @GetMapping("/genToken")
    public String genToken();

修改token_web_order中WebOrderController，新增添加订单方法

/**
     * 新增订单
     */
@PostMapping("/addOrder")
public String addOrder(@RequestBody Order order)

    String result = orderFeign.genOrder(order);

    return result;

测试

通过postman获取令牌，将令牌放入请求头中。开启两个postman tab页面。同时添加订单，可以发现一个执行成功，另一个重复请求。

"id":"123321","totalNum":1,"payMoney":1,"payType":"1","payTime":"2020-05-20","receiverContact":"heima","receiverMobile":"15666666666","receiverAddress":"beijing"

基于自定义注解实现

直接把token实现嵌入到方法中会造成大量重复代码的出现。因此可以通过自定义注解将上述代码进行改造。在需要保证幂等的方法上，添加自定义注解即可。

自定义注解

在token_common中新建自定义注解Idemptent

/**
 * 幂等性注解
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Idemptent 

创建拦截器

在token_common中新建拦截器

public class IdemptentInterceptor implements HandlerInterceptor 

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception 
        
        if (!(handler instanceof HandlerMethod)) 
            return true;
        

        HandlerMethod handlerMethod = (HandlerMethod) handler;
        Method method = handlerMethod.getMethod();

        Idemptent annotation = method.getAnnotation(Idemptent.class);
        if (annotation != null)
            //进行幂等性校验
            checkToken(request);
        

        return true;
    


    @Autowired
    private RedisTemplate redisTemplate;

    //幂等性校验
    private void checkToken(HttpServletRequest request) 
        String token = request.getHeader("token");
        if (StringUtils.isEmpty(token))
            throw new RuntimeException("非法参数");
        

        boolean delResult = redisTemplate.delete(token);
        if (!delResult)
            //删除失败
            throw new RuntimeException("重复请求");
        
    

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception 

    

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception 

    

配置拦截器

修改token_service_order启动类，让其继承WebMvcConfigurerAdapter

@Bean
public IdemptentInterceptor idemptentInterceptor() 
    return new IdemptentInterceptor();


@Override
public void addInterceptors(InterceptorRegistry registry) 
    //幂等拦截器
    registry.addInterceptor(idemptentInterceptor());
    super.addInterceptors(registry);

添加注解

更新token_service_order与token_service_order_api，新增添加订单方法，并且方法添加自定义幂等注解

@Idemptent
@PostMapping("/genOrder2")
public String genOrder2(@RequestBody Order order)

    order.setId(String.valueOf(idWorker.nextId()));
    order.setCreateTime(new Date());
    order.setUpdateTime(new Date());
    int result = orderService.addOrder(order);

    if (result == 1)
        System.out.println("success");
        return "success";
    else 
        System.out.println("fail");
        return "fail";
    

测试

获取令牌后，在jemeter中模拟高并发访问，设置50个并发访问

新增一个http request，并设置相关信息

添加HTTP Header Manager

测试执行，可以发现，只有一个请求是成功的，其他全部被判定为重复请求。

本文由传智教育博学谷狂野架构师教研团队发布。

如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。

转载请注明出处！

架构师之路系列：接口幂等性是个什么东东？如何实现接口幂等设计？

怎么理解接口幂等?

幂等实际是一个数学上的概念，在数学上如果函数满足 f(x) = f(f(x))，那么我们称函数f具备幂等性。举个栗子，假设f(x) =|x|，即函数f表示取x的绝对值，那么f(x) = f(f(x))也成立，即f(x) =||x| |。说完了幂等的原始概念，我们再来看下在编程领域，幂等指的又是什么，我们先来看下百度百科的解释。

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现。

那么我们怎么理解接口幂等呢？举个简单的例子，我们经常用的秒杀服务，在秒杀结束前，我们会疯狂的点击收集屏幕的下单按钮，但是对于秒杀而言，一个用户只能买一件，所以无论你点了多少次，要么没有秒杀到，要么秒杀到，库存只会减1，不会因为你请求了多少，或者系统因为网络重试了多少次，而改变系统的资源情况，多次操作的结果都是一致的，这种情况我们就称系统具备幂等性。

为什么要进行接口幂等设计？

如果我们不对接口进行幂等设计会导致什么问题呢？可以想象一下如果我们在京东上面下单买书，但是扣了两次钱，会有什么结果？再比如，你在银行汇钱的时候，本来要汇10000块，但是因为网络抖动原因，进行了重试，导致汇了30000块，你是不是得炸锅了。
从上面的例子我们可以知道，如果我们不做幂等设计，在一些情况下很可能会出现与我们业务期望不一样的情况，甚至会发生资损的情况，造成客户财产损失，逐渐丧失对于平台的信心，最终导致客户流失。因此我们必须要重视服务幂等问题，确保不出现上述的业务异常情况。

有哪些常见的幂等设计方案？

1、数据库唯一索引

拿用户注册这个场景来说，为了防止连续点击造成的用户信息重复的问题，我们可以在数据库中通过设置用户名、电话号码等字段的唯一性索引的方式来实现幂等，即便是出现了连续点击进行用户创建，但是在数据库层面是不会对重复数据进行入库保存的，从而达到用户服务注册接口实现幂等的目的，但是如果全靠数据库来保证的话，数据库的压力会比较大，因为入库的时候数据库要判断是否唯一，在数据量大的时候非常耗性能。

alter table `user` add UNIQUE KEY `un_user_phone` (`phone`);

2、使用Redis

上面说到唯一键会导致数据库性能下降，那么有更好的解决方案吗？如下业务，订单服务生成订单消息后发送订单消息到MQ中，库存服务根据订单信息来扣减自己的库存。但是由于网络原因，MQ迟迟未收到库存服务的消费成功消息，因此又对库存服务进行了消息投递，因而产生了两个相同订单code的订单，而此时库存服务实际第一次已经消费成功。那么库存服务如何保证幂等呢？我们可以借助于Redis来实现幂等，首先我们通过以业务code未唯一key进行redis设置，这里的业务code就是订单号，保证全局唯一，使用setNx命令。如果可以设置成功，说明是第一次设置，那么可以继续后续的业务流程，进行库存扣减。如果设置不成功，则表明此时Redis已经有对应的订单code了，本次操作属于无效请求，直接返回，不继续后续的业务流程处理。

3、先查询再进行数据操作

在进行数据插入的时候，我们可以先去查询数据是否存在，如果不存在则进行插入操作，如果已存在那么就不再进行后续操作。

这里需要注意的是幂等和防重的区别，幂等实际是包含防重的。为什么这么说呢？防重实际上指的是防止多次请求重复执行，导致系统业务异常。而幂等强调的是即使执行了业务，多次执行和一次执行的效果应该是一致的。说起来好像有点拗口，可以这么理解，重复请求是人为操作的，所以要过滤掉重复的，如秒杀。但是幂等说明的是在微服务内部，由于存在服务间的分布式调用，如果第一次调用未收到响应，会进行第二次调用来进行重试，那么此时系统需要保证两次调用达到的业务效果是一致的。因此幂等实际包含防重操作的。

PS：
大家还知道哪些其他的幂等设计方案？在你们的项目中平台是怎么设计接口幂等的？欢迎大家在评论区留言讨论哦。

---

大家好，我是慕枫，感谢各位小伙伴点赞、收藏和评论，文章持续更新，我们下期再见！

真正的大师永远怀着一颗学徒的心

微信搜索：慕枫技术笔记，优质文章持续更新，我们有学习打卡的群可以拉你进，一起努力冲击大厂，另外有很多学习以及面试的材料提供给大家。