RabbitMQ 幂等性

什么是幂等性

类似于数据库乐观锁机制，比如执行一条更新库存的 SQL 语句，在并发场景，为了性能和数据可靠性，会在更新时加上查询时的版本，并且更新这个版本信息。可能你要对一个事情进行操作，这个操作可能会执行成百上千次，但是操作结果都是相同的，这就是幂等性。

消费端的幂等性

在海量订单的业务高峰期，生产端可能产生重复的消息，这个时候消费端就会实现幂等性，这就意味着即使我们消费多次同一个消息，产生的结果都是一样的。

实现幂等性的操作

1. 唯一ID + 指纹码 机制 ，利用数据库主键去重
2. 利用redis的原子性实现

唯一 ID + 指纹码 机制

大家肯定懂唯一 ID 的，就不多说了，为什么需要指纹码呢？这是为了应对用户在一瞬间的频繁操作，这个指纹码可能是我们的一些规则或者时间戳加别的服务给到的唯一信息码，它并不一定是我们系统生成的，基本都是由我们的业务规则拼接而来，但是一定要保证唯一性，然后就利用查询语句进行判断这个id是否存在数据库中。

好处就是实现简单，就一个拼接，然后查询判断是否重复。

坏处就是在高并发时，如果是单个数据库就会有写入性能瓶颈

解决方案 ：根据 ID 进行分库分表，对 id 进行算法路由，落到一个具体的数据库，然后当这个 id 第二次来又会落到这个数据库，这时候就像我单库时的查重一样了。利用算法路由把单库的幂等变成多库的幂等，分摊数据流量压力，提高性能。

利用 redis 的原子性去实现

使用 redis 的原子性去实现需要考虑两个点

一是 是否 要进行数据落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？ 数据库与缓存进行同步肯定要进行写操作，到底先写 redis 还是先写数据库，这是个问题，涉及到缓存更新与淘汰的问题

二是如果不落库，那么都存储到缓存中，如何设置定时同步的策略？ 不入库的话，可以使用双重缓存等策略，保障一个消息副本，具体同步可以使用类似 databus 这种同步工具。

怎么保证消息队列消费的幂等性

其实还是得结合业务来思考
（1）比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下好吧

（2）比如你是写redis，那没问题了，反正每次都是set，天然幂等性

（3）比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。

本文借鉴于此篇文章，讲的很好