java项目中遇到的幂等性问题

前端多次调用（伪幂等性问题）

1.一般情况

前端控制消息调用频率，禁用请求

2.网络不好，第一次调用响应时间过长，第二次又调用

针对一些重要的接口，建议进入页面时分配一个全局ID放到前端设备中，之后调用接口时先判断全局ID是否存在redis中，若已有则直接返回，若没有就设置超时时间存放到库里，业务处理完清理掉改全局ID。（安全等级高则可以选择redis分布式锁机制）

rpc调用幂等性问题

rpc的默认重试机制会导致调用方在规定超时时间和次数内反复调用被调用方

1.禁用重试（不合理）

2.加大超时时间（简单粗暴，理论上可行，超时时间越长越不容易发生幂等性）

3.rpc调用的一般是自己系统，调用方和被调用方可以共享一个库，所以全局ID法是可行的，全局ID的产生最简单的办法就是和业务ID直接挂钩，也可以间接挂钩（如用业务ID计算出一个新的ID），业务处理前进行幂等性校验。

httpClient幂等性问题

httpClient他底层也是有线程池，也是可以配置重试时间，重试次数的

1.禁用重试（不合理）

2.加大超时时间（简单粗暴，理论上可行，超时时间越长越不容易发生幂等性）

3.httpClient一般是调用别的系统，无法共享一个库，和rpc调用类似，不过需要和对方系统进行讨论决定，只考虑调用方的话，全局id和redis仍是最方便的处理方法

MQ幂等性问题

生产者给MQ服务器推消息，MQ服务器返回ack时卡了一下，结果生产者以为没有推成功，又退了一次，造成数据重复

消费者从MQ服务器获取消息，返回ack给MQ告诉已经消费过时卡了一下，结果又消费了一遍

1.推送时扔通过全局ID判断MQ服务器队列里是否已经有数据了

2.消费时扔通过全局ID判断该数据是否已经入库

 

总结

可以发现幂等性往往是双方的问题，双方需要一个中间件来确保数据不会重复，redis这类高性能库是首选，过期消息的特性可以保证数据不会累计过多，我认可可以当做一般项目的万金油解决方案，当然可以在此基础上在优化。