redis（四）-pub/sub 发布/订阅

zhangxinba

　　参考：
　　http://www.sxrczx.com/pages/shift-alt-ctrl.iyunv.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、在第二个窗口输入发布命令
[iyunv@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/