北京企业建网站网络公司名字
RabbitMQ层面有实现“去重机制”来保证“恰好一次”吗？答案是没并没有，而且现在主流的消息中间件都没有实现。
一般解决重复消息的办法是：在消费端让我们消费消息操作具有幂等性。
幂等性问题并不是消息系统独有，而是（分布式）系统中普遍存在的问题。一个幂等操作的特点是，其任意多次执行所产生的影响均与一次执行的影响相同。一个幂等的方法，使用同样的参数，对它进行多次调用和一次调用，对系统产生的影响是一样的。
对于幂等的方法，不用担心重复执行会对系统造成任何改变。
业界对于幂等性的一些常见的做法：
借助数据库唯一索引，重复插入直接报错，事务回滚。以经典的转账为例，为了保证不重复扣款或者重复加钱，系统维护一张资金变动表，这个表里至少需要记录交易单号、变动账户、变动金额等字段，使用交换单号和变动账号做联合唯一索引（单号一般由上游系统生成保证唯一性）这样如果同一笔交易发生重复请求时就会直接报索引冲突，事务直接回滚，现实中数据库唯一索引的方法通常做为兜底的保证；
前置检查机制。还以上面的转账为例，当我们在执行更改帐号余额这个动作之前，先检查下资金变动表是否存在这笔交换相关的记录了，如果已经存在，直接返回。否则执行正常的更新余额的动作。为防止并发问题，通常需要借助“排他锁”，我们也可以使用乐观锁或者CAS机制。乐观锁一般会使用扩展一个版本号字段做判断条件。
唯一ID机制。比较通用的方法。对于每条消息都可以生成唯一的ID,消费前判断交易表中是否存在，消费成功后将状态写入。可以防止重复消费。