前言

Redis发布订阅（pub/sub）是一种消息通信模式，发布者发布消息，订阅者接收消息。

订阅SUBSCRIBE

通过SUBSCRIBE channel指令订阅频道。

127.0.0.1:6379> subscribe ps1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1

redis客户端可以同时订阅多个频道。

127.0.0.1:6379> subscribe ps1 ps2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1
1) "subscribe"
2) "ps2"
3) (integer) 2

发布PUBLISH

通过PUBLISH channel message可以往指定频道发布消息。

// 发布者
127.0.0.1:6379> publish ps1 m1
(integer) 2
127.0.0.1:6379> publish ps2 m2
(integer) 1

// 订阅者1
127.0.0.1:6379> subscribe ps1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1
1) "message"
2) "ps1"				<================收到ps1频道的消息
3) "m1"				<================消息内容为m1

// 订阅者2
127.0.0.1:6379> subscribe ps1 ps2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1
1) "subscribe"
2) "ps2"
3) (integer) 2
1) "message"
2) "ps1"				<================收到ps1频道的消息
3) "m1"				<================消息内容为m1
1) "message"
2) "ps2"				<================收到ps2频道的消息
3) "m2"				<================消息内容为m2

使用场景（基本没有）

1. 分析
   查阅到的资料中只介绍了发布、订阅、退订等的是使用，未对具体使用场景做出介绍。网上也未搜到具体的使用场景 -_-||
   redis的发布订阅机制很简单，相较于MQ系列消息中间件，缺少了消息持久化、消费确认等机制，个人理解redis的使用场景与UDP报文广播类似，一端只负责无脑发送消息，不去确认消息是否有人接收，自然也就无法确认消息是否丢失。另一边只负责无脑接收消息，接受完消息不去做出反馈（因为对方也不接收反馈），当接收不到消息时也不抛出异常或警告。
   综上所述，redis的发布订阅机制是一种不可靠的MQ（UDP广播），在需要发送通知或者传递消息时无法保证消息的送达，亦无法保证消息不丢失。所以需要可靠的消息传递的场景均不适用。
2. 结论
   redis的发布订阅机制过于简单，只适用于可以容忍消息丢失、未送达的场景（这样的场景真的存在吗）。如果想要可靠的发布订阅实现，还是要选择MQ系列消息中间件。

redis学习-发布订阅

原文：https://www.cnblogs.com/bcomll/p/13497708.html