参考:
http://www.sxrczx.com/pages/shift-alt-ctrl.iteye.com/blog/1867454.html
一、是什么
1、redis的发布/订阅是为用户订阅频道,广播发送的一种消息推送机制。
2、发布者不是将消息直接发送给订阅者,而是将消息发送给频道(channel),然后由频道将消息转发给所有对频道感兴趣的订阅者。
3、发布者无需知道任何订阅者的信息。
4、订阅者也无需知道是那个客户端给他发送的消息,它只要关注自己喜欢的频道就行了。
二、优点
1、发布者和订阅者非耦合,可以极大的提高系统的扩展性,并得到一个更动态的网络拓扑。
三、缺点
1、服务器只做消息的转发,不会保留。消息即发即得,消息的订阅者也只能接受到订阅之后的消息。
2、做到了消息发布和订阅的基本能力,但尚未提供JMS中关于消息的持久化等各种企业级的特性。
四、怎么用
1、订阅喜欢的两个频道redis> SUBSCRIBE foo bar
2、消息的格式
频道转发的每条消息都是一条带有三个元素的多条批量回复(mutil-bulk reply)。
消息的第一个元素标识了消息的类型:
subscribe:表示当前客户端成功的订阅了消息第二个元素所指示的频道。
unsubsribe: 表示当前客户端成功退订了消息第二个元素所指示的频道。
message:表示这条信息是有某个客户端执行PUBLISH命令所发送的,真正的信息,消息的第二个元素是消息来源的频道,而第三个元素则是消息的内容。
消息的第二个元素标识了消息的频道:频道名称
消息的第三个元素标识了消息订阅的频道数:记录了客户端目前仍在订阅的频道数量。
1、客户端连接服务端 redis-cli 2、输入订阅命令 127.0.0.1:6379> SUBSCRIBE news Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "news" 3) (integer) 1 3、再重新开启个界面,连接服务端 redis-cli 4、在第二个窗口输入发布命令 [root@www ~]# redis-cli 127.0.0.1:6379> PUBLISH news 'i am joandora' (integer) 1 5、在第一个窗口就会收到消息 127.0.0.1:6379> SUBSCRIBE news Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "news" 3) (integer) 1 1) "message" 2) "news" 3) "i am joandora"3.频道订阅-支持模式匹配
客户端订阅的模式里面可以包含多个glob风格的通配符,比如:* 、 ? 和 [...] 等等。订阅的命令:PSUBSCRIBE、PUNSUBCRIBE
比如说,执行命令:
redis> PSUBSCRIBE news.*
客户端将收到来自news.art、news.music等频道的信息。
4、客户端同时订阅两种模式
如果客户端订阅的多个模式匹配了同一个频道,或者客户端同时订阅了某个频道、以及匹配这个频道的某个模式,那么它可能会多次接收到同一条信息。
SUBSCRIBE foo PSUBSCRIBE f*
那么当有信息发送到频道foo时,客户端将收到两条信息:一条来自频道foo,信息类型为message;另一条来自模式f*,信息类型为pmessage。
五、注意点
1、消息发布者,无需独占连接。你可以在发布消息的同时,使用同一个redis-cli连接进行其他操作。
2、消息的接收者,需独占连接,将以阻塞的方式等待接收服务端publish消息。
3、一旦subscribe端断开链接,将会失去部分消息,如果你非常关注每个消息,那么你应该考虑使用JMS或者基于Redis做一些额外的补充工作,如果你期望订阅是持久的,那么如下的设计思路可以借鉴(如下原理基于 JMS):
1) subscribe端首先向一个Set集合中增加“订阅者ID”,此Set集合保存了“活跃订阅”者,订阅者ID标记每个唯一的订阅者,例如:sub:email,sub:web。此SET称为“活跃订阅者集合” 2) subcribe端开启订阅操作,并基于Redis创建一个以“订阅者ID”为KEY的LIST数据结构,此LIST中存储了所有的尚未消费的消息。此LIST称为“订阅者消息队列” 3) publish端:每发布一条消息之后,publish端都需要遍历“活跃订阅者集合”,并依次向每个“订阅者消息队列”尾部追加此次发布的消息。 4) 到此为止,我们可以基本保证,发布的每一条消息,都会持久保存在每个“订阅者消息队列”中。 5) subscribe端,每收到一个订阅消息,在消费之后,必须删除自己的“订阅者消息队列”头部的一条记录。 6) subscribe端启动时,如果发现自己的自己的“订阅者消息队列”有残存记录,那么将会首先消费这些记录,然后再去订阅。
六、应用场景
1、服务器控制及监控:http://m.blog.csdn.net/blog/liguohui/7706815
2、日志记录:http://irayd.com/blog/use-redis-pub-sub/