redis发布订阅

一般来说，消息队列有两种场景，一种是发布者订阅者模式，一种是生产者消费者模式。利用redis这两种场景的消息队列都能够实现。

生产者消费者模式(PUSH/ BRPOP)：生产者lpush将消息数据添加到list结构中，消费者通过rpop或者brpop消费消息，brpop是阻塞的方式，可以设置等待时长。如果有多个消费者同时监听该列表，只有一个能取到消息。

发布者订阅者模式(PUB/SUB)：发布者和订阅者通过channel频道解偶， 订阅者监听某个channel的消息，当发布者向该channel推送消息时，订阅该channel的消费者都可以收到消息。

redis订阅消息有两种方式，一种是channel方式，固定只监听某一频道的消息；另一种是pattern方式，模糊匹配channel，收取匹配到的所有channel的消息。

在redis server中，有一个数据字典pubsub_channels用于保存channel以及订阅者的关系，结构如下：

当有客户端订阅某个channel时，如果pubsub_channels不存在该channel，就会追加一个channel，每个channel所有的订阅者是以链表的形式存在。

 

演示：

通过subscribe命令订阅了mychannel频道，subscrbe可以订阅多个频道

psubscribe命令表示按照模糊匹配的方式监听频道，支持多个

publish命令向mychannel推送消息

收到消息

 

问题：

redis发布订阅消息采用“发送即忘（fire and forget）”的策略，如果订阅者重启或者宕机，都有可能导致消息丢失，因此redis发布订阅机制并不是可靠的消息通道，仅适用于对消息准确性要求不严格的场景，例如：日志打点等。