如何设计实现幂等框架

拼搏现实的明天。 2023-03-01 13:35 4阅读 0赞

# 1.定义 #

幂等：就是对于同一个接口，同一个业务请求，无论发起多少次，保证业务只执行一次，也就是接口的逻辑只会被执行一次。

# 2.使用场景 #

场景：微服务A中调用微服务B中的接口，会有三种结果出现，即成功、失败、超时。

成功和失败两种结果非常明确，如果是成功，那么表示此次调用是正常的。如果是失败，那么表示此次调用是失败的，可以由调用的发起方来根据失败的结果决定接下来要做的事情。

但是超时就是一个非常不明确的事情了， 有可能是微服务B中的逻辑已经成功执行完成，但是返回成功的结果的网络传输过程中产生了超时；也有可能是微服务B中的逻辑执行中超时，比如插入数据库数据的过程中超时；也有可能是执行失败了，但是返回失败的结果的网络传输过程中产生了超时。总之，业务执行过程中，产生了超时，如何处理超时是最让开发人员头疼的问题。

如果接口仅仅只是查询数据，那么超时后重试即可。

如果接口是删除数据，哪怕是第一次执行删除成功了但是返回超时，那么第二次重试执行一次删除操作也不会造成什么影响。但是删除要注意ABA的问题，即上一次执行删除成功了但是返回了超市，在第二次重试执行前，又插入了同样的一条数据，那么第二次重试执行就会把本不应该删除的数据给删除了。当然这种场景其实在很多业务流程上不会出现，也可以避免，甚至是就算会出现，也可以针对性的去处理这种情况，消除对业务上的影响。

如果接口是简单的更新操作，哪怕是上一次执行更新成功但是返回超时，那么第二次重试执行一次更新也是没有关系的。当然，也会出现删除的时候ABA的问题。

如果接口是增加数据，哪怕是第一次执行成功了但是返回超时，那么第二次重试执行就可能会出现同一笔数据被插入两次，当然这种情况，也是可以规避的，可以用数据库的UK来保证一条业务数据只会生成一条数据。

所以，超时重试就需要接口幂等来支持。

# 3.关键点 #

根据定义中幂等的概念，关键点之一在于如何识别是同一个业务请求，所以幂等是脱离不开业务来单独讲的，并且幂等也是为了我们业务服务的。

举个具体的例子，一个用户可以发起多笔的售后退款申请，那么这笔退款申请的单号可以作为业务请求是不是同一个的区分凭证，也就是说为这个幂等增加这样的一个幂等号，如果两次请求都是这样同一个售后单号，那么就说明这两次是同一个业务请求，只需要执行一次即可。

但是这里会有一个问题，如果我们的幂等是设计给很多业务使用的，那么幂等号最好是脱离具体业务单号的生成规则，由自己来生成和分配幂等号。

# 4.幂等框架的主要处理流程 #

针对微服务A调用微服务B的场景

step1. 接口A从幂等框架中拿到此次幂等框架生成的幂等号

step2. 接口A携带者幂等号调用接口B

step3. 接口B拿到幂等号，调用幂等框架查询是否已经存在此次的幂等号