前言
关于 Redis 的“起承转合”，我前面已经用五个篇章的长度作了一个 Redis 基础篇——“起”篇的详细阐述，相信大家无论之前有没有接触过 Redis，都能从中学到不少东西。基础篇的内容顾名思义，只是个基础，主要说了 Redis 的发展以及 Redis 的基本数据类型，内容跟平时使用关联会比较大，难度不算大，希望大家能好好消化。 这里送上基础篇的飞机票：
【起】Redis 概述篇——带你走过 Redis 的前世今生
【起】Redis 基础篇——基本数据结构之String，Hash
【起】Redis 基础篇——基本数据结构之 List，Set
【起】Redis 基础篇——基本数据结构之 ZSet，Bitmap…
在“承”篇中，我会围绕 Redis 的原理来阐述，讲一些相对比较高级的特性，比如本篇章要讲到的 pub/sub（发布/订阅）模式，持久化机制，高性能特性，事务，内存回收机制等等，在接下来的篇章中，我会为大家穿针引线，把每个篇章的内容都串起来，这里就先不占用大家的前言篇章。
那话归正题，我们今天来看一下关于 Redis 的发布/订阅模式。
正文
发布/订阅模式
列表的局限
前面我们说通过队列的 rpush 和 lpop 可以实现消息队列（队尾进队头出），但是消费者需要不停地调用 lpop 查看 List 中是否有等待处理的消息（比如写一个 while 循环）。
为了减少通信的消耗，可以 sleep()一段时间再消费，但是会有两个问题：
- 如果生产者生产消息的速度远大于消费者消费消息的速度，List 会占用大量的内存；
- 消息的实时性降低；
list 还提供了一个阻塞的命令：blpop，没有任何元素可以弹出的时候，连接会被阻塞。
blpop queue 5
基于 list 实现的消息队列，不支持一对多的消息分发。
发布订阅模式
除了通过 list 实现消息队列之外，Redis 还提供了一组命令实现发布/订阅模式。 这种方式，发送者和接收者没有直接关联（实现了解耦），接收者也不需要持续尝试获取消息。
订阅频道
首先，我们有很多的频道（channel），我们也可以把这个频道理解成 queue。
订阅者可以订阅一个或者多个频道。
消息的发布者（生产者）可以给指定的频道发布消息。
只要有消息到达了频道，所有订阅了这个频道的订阅者都会收到这条消息。
需要注意的点是，发出去的消息不会被持久化，因为它已经从队列里面移除了，所以消费者只能收到它开始订阅这个频道之后发布的消息。
下面我们来看一下发布订阅命令的使用方法。
订阅者订阅频道：可以一次订阅多个，比如这个客户端订阅了 3 个频道。
subscribe channel-1 channel-2 channel-3
发布者可以向指定频道发布消息（并不支持一次向多个频道发送消息）：
publish channel-1 2673
取消订阅（不能在订阅状态下使用）：
unsubscribe channel-1
按规则（Pattern）订阅频道
支持?和*占位符。?代表一个字符，*代表 0 个或者多个字符。
消费端 1，关注运动信息:
psubscribe *sport
消费端 2，关注所有新闻：
psubscribe news*
消费端 3，关注天气新闻：
psubscribe news-weather
生产者，发布 3 条信息
publish news-sport yaoming
publish news-music jaychou
publish news-weather rain
