如何设计实现幂等框架

1.定义

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

2.使用场景

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

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

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

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

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

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

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

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

3.关键点

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

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

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

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

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

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

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

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

step3.1 如果已经存在，那么直接返回

step3.2 如果不存在，则执行此次业务操作，并记录此次幂等号

注意step3.2中，要在业务操作正常执行完，来调用幂等框架记录此次幂等号。

以上的处理流程中，会出现不同的异常情况，后面会对具体的异常进行分析。

5.框架层面上的设计思考

低耦合：一个好的框架，一定是尽量少侵入业务代码，保持低耦合

高内聚：尽量保证在业务代码中统一的地方来接入框架

易用性：接入成本低，易于理解，通过少量配置或者少量代码就可以接入

高性能：业务在发起请求的时候，需要每次去请求一个幂等号，这就要求请求幂等号的接口尽可能的是高性能的，不然幂等号接口性能低下，就会拖慢整体调用的时长，尤其是针对c端用户的产品，都是要尽量保证高QPS的。

可用性：如果请求幂等号的接口挂了，怎么办？这个时候就需要根据业务的具体场景，来决定是不是要继续执行。比如是资金类的转账场景，幂等框架出现问题，那么可能就要选择讲转账的业务降级掉，待幂等框架问题解决，再讲转账业务恢复，针对异常这期间的操作通过补偿的机制来补偿这段时间内的异常。