rabbitmq消费者集群情况下，怎么保证同一个消息只被一个消费者消费

[whyyouhitme_]

rabbitmq消费者集群情况下，怎么保证同一个消息只被一个消费者消费

[maradona1984]

队列中的消息应该只会被一台客户端消费,但异常情况下可能重新消息回重新回到队列,所以客户端还是要做幂等

[whyyouhitme_]

幂等是用全局id存redis吗？还是先去数据库查，有数据就return

[maradona1984]

引用 2 楼 whyyouhitme_ 的回复:

幂等是用全局id存redis吗？还是先去数据库查，有数据就return

做法很多,可以根据业务决定,比如唯一键(业务中存在唯一的字段才行),比如消息体中丢一个uuid,存到一个做幂等的表中,uuid的字段做唯一键也可以保证重复执行不出问题,利用数据库事务保证唯一,或者加分布式锁+特定的查询来保证只执行一次 第二个可以脱离业务做到通用,其他跟业务强相关

[安小然然]

全都是不懂瞎说。。。

[安小然然]

坐等一个大神给一个准确的答案，而不是乱说

[哈希塞特]

你不是topic的话只能被消费一次

[安小然然]

引用 7 楼 maradona1984 的回复:

[quote=引用 4 楼 安小然然 的回复:] 全都是不懂瞎说。。。

瞎说?请教下哪里瞎说了[/quote] 你觉得你这个想法能在生产环境去用吗，用了消息就是要减轻数据库的压力，存到一个做幂等的表中,uuid的字段做唯一键也可以保证重复执行不出问题,利用数据库事务保证唯一, 这张表的数据量你考虑过吗，效率

[maradona1984]

引用 9 楼 安小然然 的回复:

[quote=引用 7 楼 maradona1984 的回复:] [quote=引用 4 楼 安小然然 的回复:] 全都是不懂瞎说。。。

瞎说?请教下哪里瞎说了[/quote] 你觉得你这个想法能在生产环境去用吗，用了消息就是要减轻数据库的压力，存到一个做幂等的表中,uuid的字段做唯一键也可以保证重复执行不出问题,利用数据库事务保证唯一, 这张表的数据量你考虑过吗，效率[/quote] 这张表可以定期清理,并不觉得会有多大数据量,可以单独做成一个组件,几乎没有增加额外的复杂度,你插到业务表,当然可以,但与业务代码耦合,表也增加了一个额外的字段和唯一约束,对数据库的压力并不见得比单独成表小,毕竟单独的表可以清理,可以truncate,你那个不能,表一大,索引维护也是很大成本的. 不同取舍罢了,怎么是瞎说?而且mq是减轻数据库压力?在性能上是为了削峰填谷,架构上是解耦,mq并不会减少数据库操作次数,缓存才能大幅度减轻数据库压力,当然对数据库完全没好处是假的,但作用没那么明显罢了

[maradona1984]

引用 4 楼 安小然然 的回复:

全都是不懂瞎说。。。

瞎说?请教下哪里瞎说了

[a597192251]

重复消费的问题 我的理解是 开启手动的ack 不管有多少个消费者监听队列 ，只有会有一个消费者拿到，先进先出的原则嘛 我不知道我回答的对的还是错误的 请大佬们指正，

[二生三]

引用 12 楼 a597192251 的回复:

重复消费的问题 我的理解是 开启手动的ack 不管有多少个消费者监听队列 ，只有会有一个消费者拿到，先进先出的原则嘛 我不知道我回答的对的还是错误的 请大佬们指正，

你所说的是一个很理想的环境，但是你必须要考虑，系统在消费数据期间宕机了或者被重启了的情况，消费是否加事务这个是看业务的，事务是针对数据库的，那你是在接收到数据的时候就ACK还是在消费结束前ACK？如果是前者，如何确保ACK之后所有的数据都确实都已经消费了？消费了一半的数据该如何处理？如果是后者，消费时间会不会过长导致ACK超时？超时了会重新进入排队，这时候如果避免别的端重复消费该数据（这就是幂等防止消费）？