关于重复消费的一些解决方案

重复消费问题一直是一个热点问题，不管是面试还是实际工作过程中都会遇到，今天我就盘一下这个问题。

1. 重复消费是怎么出现的

重复消费的问题出现的情况有很多，我列举一下常见的吧：

• 用户重复提交表单。

• 用户使用软件恶意刷单。

• 消息由于失败，但是并没有失败，存在重试机制导致重复消费。

• MQ 中的经典重复消费问题。

2. 那怎么解决呢？

解决重复消费问题，就需要保证一个特性，那就是幂等性，即调用一次请求的结果和调用多次相同请求的结果是一样的。

一般情况下，像查询业务，删除业务这些都是幂等的，而用户下单和退款业务这些不是幂等的。

保证幂等性有以下解决方式：

1. 用户提交表单后，让提交按钮变为 loading 标志确保不能重复点击，同时跳转到一个提交成功的页面。

2. 去重，每条消息都有一个唯一标识，通过判断标识是否存在从而去重，这样就能避免处理已经处理过的消息。

3. 保证接口的幂等性，通过先查再更新的方式修改数据库记录。比如消息有一个唯一标识，那么先去数据库中查找是否有这个标识，如果没有再添加；也可以根据业务来，比如支付业务，先去查对应的支付订单是否为未付款，如果是则进行扣款并更新订单状态。

3. 详细说一下去重

上面提到的解决方式中1，3点都是老生常谈了（个人拙见），我重点说一下去重有哪些方案吧。

1.Redisson 客户端的布隆过滤器

它的底层数据结构是一个 bitmap(位图)，里面存放的是二进制0或者1。刚开始全是0，当一个key来了之后先经过3次hash运算，模于数组长度找到对应的数组下标，把对应的0改为1。这样的话，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。

但是它存在一定程度的误判，比如一个 key 过来布隆过滤器判断它存在于 bitmap 中，但是实际上不存在。我们可以通过增加数组的长度或者增加 hash 计算的次数从而减少误判率，但是这也会带来一定的内存和性能开销，实际应用中需要结合业务预估误判率，并且我们需要对误判的情况进行兜底操作，比如查询数据库中是否存在相应的记录。

• 业务代码

2. 创建自定义注解实现去重

可以自定义一个幂等注解，然后配合 AOP 进行方法拦截，对拦截的请求信息(包括ip+方法名+参数名+参数值)根据固定的规则去生成一个 key，然后调用 redis 的 setnx 方法，如果返回 ok，则正常调用方法，否则就是重复调用了。这样可以保证重复请求接口在一定时间内只会被成功处理一次。至于锁的有效时长要根据业务情况而定的。

• 创建幂等性注解

• 获取 IP 的工具类

• 创建幂等性切面

上述解决调用的重复问题，核心是找到一个唯一的标识，从而判断是否为重复操作。