redis pub/sub模型是否需要与redis的持久连接?

cod*_*ing 17 publish-subscribe redis

在Web应用程序中,如果我需要将事件写入队列,我将建立与redis的连接以编写事件.

现在,如果我想要另一个后端进程(比如一个守护进程或cron作业)来处理或以redis方式发布事件,我是否需要持久连接?

关于这个发布/订阅过程在Web应用程序中的工作方式有点困惑.

ant*_*rez 44

基本上在Redis中有两种不同的消息传递模型:

  • 火和忘记/一对多:Pub/Sub.在消息被PUBLISH-ed时,所有订阅者都将收到它,但此消息将永远丢失.如果没有订阅客户端,则无法将其恢复.
  • 持久队列/一对一:列表,可能与阻止命令(如BLPOP)一起使用.使用列表,您有一个生产者推入列表,一个或多个消费者等待元素,但一个消息将只到达一个等待的客户端.使用列表,您有持久性,消息将等待客户端弹出它们而不是消失.因此,即使没有人在监听,也会有积压(与可用内存一样大,或者您可以使用LTRIM限制积压).

我希望这很清楚.我建议您研究以下命令以了解有关Redis和消息传递语义的更多信息:

  • LPUSH/RPUSH,RPOP/LPOP,BRPOP/BLPOP
  • 发布,订阅,PSUBSCRIBE

可以在redis.io上找到此命令的文档

  • 有了Pub/Sub,是的.请看[this](http://blog.joshsoftware.com/2011/01/03/do-you-need-a-push-notification-manager-redis-pubsub-to-the-rescue/)以获取示例关于如何使用Pub/Sub和自定义ruby客户端实现持久性消息. (5认同)

rm-*_*-rf 2

我不完全确定,但我相信,是的,发布/订阅需要持久连接。

作为替代方案,我会看看resque以及它是如何处理的。它不使用 pub/sub,而是简单地将一个项目添加到 redis 中的列表中,然后您拥有的任何守护程序或 cron 作业都可以使用 lpop 命令来获取第一个项目。

抱歉只给出一个伪答案然后一个插头。