如何保证消息只被消费一次？

[Lullaby]

最近用 redis 的 pub/sub 做消息队列，开启多个 MQ 应用进程，由于使用的是发布订阅者模式，多个监听者(消费者)如何保证只有一个监听器接收到消息并消费？

[evanmeng]

这不就是要做 Exactly Once 吗？虽然有很多绕过去的做法，但直接的回答就是一句：不能。

[surfire91]

考虑过走队列吗？哪个消费者拿到了，哪个消费者处理。

[Lullaby]

@evanmeng 意思是只能 producers / consumers ？

[Lullaby]

@surfire91 就是走队列，只是借用了 redis 的 pub / sub ，生产消费者模式能保证只有一个消费者拿到并消费

[evanmeng]

在生产者和消费者都有可能当机的现实网络，要保证无数据丢失的 Exactly Once 是做不到的。
常用的做法无非是：用一个 Zookeeper 之类的分布式锁记录已发送信息， pub 要 sub 发送确认，在多个 sub 一方去重。
@Lullaby

[est]

@mathiasverraes

There are only two hard problems in distributed systems:

2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery


https://twitter.com/mathiasverraes/status/632260618599403520

[odirus]

无法保证的，建行当年花那么多钱都无法保证，还是需要去重，别去踩坑了。

[yangmls]

为什么不用 redis 的 lpop ？

[Lullaby]

@evanmeng pub 要 sub 发送确认是什么意思？

[Lullaby]

@yangmls 看到支持 pub/sub 就直接扯来用了

[moe3000]

不要用 pub/sub 用 list 操作

[xiamx]

无法保证， CAP Theorem: https://en.wikipedia.org/wiki/CAP_theorem

[love]

只能绕过这个问题。

比如以前我们的做法：
队列向一个 consumer 发一个消息后，把这个消息设置为正在处理，并设置一个倒计时，时间到后 consumer 没有回发确认处理完毕的消息的话再放回队列以便给别的 consumer 再处理。

[xiamx]

嗯 @love 说的是一个比较常见的折中方案了

[surfire91]

@Lullaby 我懂了，你是用 pub/sub 来实现消息队列。 pub/sub 就没法保证只消费一次，还不如用 LIST 。

[xufang]

简单一点用数据库， sql 的 acid 特性可以保证。 单点问题可以通过主从来实现。

复杂一些上 zk 或 etcd ，这个前面有人提到了。

[xufang]

见我 /t/233785 的回复，和这贴可以互相验证。

[zacard]

一个订阅者即可啊。

[SparkMan]

还是使用生产者消费者模式吧，否则就算加锁来保证，效率也大大降低了

[eimsteim]

不开启多个 MQ 应该能解决这个问题吧？如果单个 MQ 没有性能瓶颈的话，就不要开启多个了撒