订阅、取消订阅和发布实现了发布/订阅的消息范式，在这种范式下，发送方(发布者)没有被编程为将他们的消息发送给特定的接收者(订阅者)。相反，已发送消息的特征是渠道，发布者不知道可能有什么(如果有的话)订阅者。订阅者对一个或多个渠道表示兴趣，并且只接收他们感兴趣的消息，而压根不知道有哪些(如果有的话)发布者。这种对发布者和订阅者的解耦将可以允许更大的可伸缩性和更动态的网络拓扑结构。

例如，为了订阅渠道foo和bar的消息，客户端可以发出一个提供渠道名称的订阅：
SUBSCRIBE foo bar

其他客户端发送到这些渠道的消息将会被Redis推送给所有那些订阅了这些渠道的客户端。

一个订阅了一个或多个渠道的客户端不应该发出命令，尽管他可以订阅和取消订阅其它渠道。回复订阅和取消订阅的操作都是以消息的形式发送的，所以客户端只需要读取一个连续的消息流，流的第一个元素表示消息类型。在一个订阅的客户端允许执行的命令包括SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE、PUNSUBSCRIBER、PING和QUIT。

推送消息的格式

每条消息都是一个数组，包含三个元素。
第一个元素表示消息类型：

• subscribe: 表示我们成功订阅了在响应的第二个元素中给出的渠道。第三个元素表示我们当前已经订阅的渠道数量。
• unsubscribe: 表示我们成功取消订阅了在响应的第二个元素中给出的渠道。第三个元素表示我们当前已经订阅的渠道数量。当最后一个元素为0时，表示我们没有订阅任何渠道，由于我们已经不再处于发布/订阅状态，此时客户端可以发出任意类型的Redis命令。
• message: 这是一条由其他客户端发出的发布命令接收的消息。第二个元素是来源渠道名称，而第三个元素则表示消息的实际内容。

数据库 & 作用域

发布/订阅与键所在的空间没有任何关系。它被设计成不受任何级别的干扰，包括数据库号。在10号db上发布，也可以被1号db上的订阅者接收到。

如果你需要区分某种类型，可以在渠道前加上环境名称作为前缀(测试环境、演示环境、生产环境...)。

协议示例

SUBSCRIBE first second
*3
$9
subscribe
$5
first
:1
*3
$9
subscribe
$6
second
:2

此时，我们可以从另一个客户端发出针对渠道名称为second的发布操作：
PUBLISH second Hello
第一个客户端将接收到如下消息：

*3
$7
message
$6
second
$5
Hello

现在客户端可以使用UNSUBSCRIBE命令将它自身从所有渠道中取消订阅而无需额外的参数：

UNSUBSCRIBE
*3
$11
unsubscribe
$6
second
:1
*3
$11
unsubscribe
$5
first
:0

模式匹配订阅

Redis的发布/订阅实现支持模式匹配。客户端可以订阅全局样式的模式，以便接收所有发送至名称跟指定模式相匹配的渠道的消息。例如：
PSUBSCRIBE news.*
将可以接收所有发送至news.art.figurative,news.music.jazz等等这些渠道的消息。所有的全局样式模式都是有效的，所有也支持多通配符。
PUNSUBSCRIBE news.*
会将该客户端取消订阅所有匹配到该模式的渠道。此调用不会影响其它订阅。

由模式匹配接收到的消息将会以不同的格式发送：

这种消息的类型是pmessage：它是一种由其他客户端发出的PUBLISH命令匹配一个模式匹配订阅的接收结果。第二个元素是原始的匹配模式，第三个元素是来源渠道名称，而最后一个元素则是实际的消息内容。

跟SUBSCRIBE和UNSUBSCRIBE相似，PSUBSCRIBE和PUNSUBSCRIBE命令也是系统公认的消息发送类型，它在发送psubscribe、punsubscribe类型的消息格式时使用与subscribe、unsubscribe类型一样的消息格式。

同时匹配模式和渠道订阅的消息

如果一个客户端订阅的多个模式匹配了同一个已发布消息，或者它订阅的模式和渠道匹配了同一条消息，那么它可能就多次接收到一条同样的消息。如下例所示：

SUBSCRIBE foo
PSUBSCRIBE f*

在上面这个栗子中，如果消息被发送至渠道foo，那么客户端将会接收到两条消息：一条message类型和一条pmessage类型。

模式匹配订阅统计的意义

在subscribe、unsubscribe、psubscribe和punsubscribe这些类型的消息中，最后一个元素都是当前依然活跃的订阅数。这个数字实际上就是客户端依然订阅的渠道和模式的总量。所以只有当客户端取消订阅了所有渠道和模式时，这个数字才会下降为0，此时客户端将会退出发布/订阅状态。

程序示例

Pieter Noordhuis提供了一个非常棒的使用EventMachine和Redis创建一个多用户高性能网络聊天的样例。

客户端库实现提示

由于所有接收到的信息都包含了原始的订阅信息，这就导致消息传递(消息类型为message时是渠道，消息类型为pmessage时是模式)客户端库可以跟原始订阅信息的回调方法(可能是匿名函数、块或者函数指针)通过哈希表进行绑定。

当接收到一条消息时，一个O(1)复杂度的查找就可以将消息传递至已注册的回调。

2017-09-04
原文链接：https://redis.io/topics/pubsub