分布式环境下接口幂等性浅析

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

    幂等性,通俗的说就是一个接口,多次发起同一个请求,必须保证返回结果必须准确,比如订单接口,不能多次创建订单,支付宝回调接口可能会多次回调,你要保证你的业务处理准确且操作只能执行一次。

      在分布式场景中,假如你的某个服务部署了5台机器,前端请求调用,因为某些原因可能重复请求了俩次,因为负载均衡算法落到了俩台机器上,可能会导致重复的业务处理逻辑;又比如说 在使用微服务组件,例如zuul,feign等 在超时的情况下会有重试机制,也可能会导致重试请求多次,如果业务方没有做好幂等性,就会导致业务处理出错,比如多次创建订单,多次扣款,这些坑都会导致很严重的问题。

     那么怎么保证幂等性呢,保证幂等性主要就是要保证每一次请求都必须要有一个唯一的标识,比如订单id,比如支付流水号,或者前端请求可以生成一个唯一的随机串,都可以作为唯一标识,对于第一次请求的时候,就必须要将唯一标识存放到数据库MySQL或者redis等存储中。后端服务收到请求,在进行业务处理之前,必须要先检查这个唯一标识是否存在,如果存在,就可以判定已经此次请求已经处理过,不需要进行重复处理。

      在实际开发中保证接口幂等性主要有以下几个方案,可供参考。

      (1) 对于要操作的数据,在表中建立唯一索引字段。特别适用于进行一些新增数据,插入操作,比如创建订单,在MySQL业务表中建立唯一索引字段,当请求过来的时候,如果是多次重试,就违反了表中索引字段的唯一性,就会报错,业务自然会回滚。

      (2) 还是基于MySQL数据库,在业务表中增加版本号字段,调用方每次请求数据的时候可以先获取version版本号,然后多传入一个version版本号字段,业务方在处理请求的时候,会去查新数据库中的version版本号,判断一下俩个version的值是否相同,如果version不相同,说明本次请求已经处理过了,直接返回。

      (3) 基于业务状态进行判断,设计接口的时候,对于每一个业务操作能否操作,设置可以执行的状态,比如使用状态机模式,便于检查业务对象的状态,接受到请求要进行一些业务处理时,可以先行判断业务对象的状态,是否满足执行操作的条件,如果当前操作已经执行过了,那么状态就会发生变化,也就不能进行当前操作,直接返回。

      (4) 可以在外部存储中设置一个单独的去重表,比如使用redis,每次请求过来,生成唯一的key。重复请求过来的时候判断一下这个key是否存在,如果存在,说明存在重复调用,直接返回。

      实现接口的幂等性 是业务接口方必须保证的基础功能,特别是服务与服务间的调用,可以使得服务接口在异常请求情况下,仍然保证接口的准确性,数据的准确性。

你可能感兴趣的:(分布式环境下接口幂等性浅析)