Redis发布订阅
是一种消息通信模式：发送者(PUBLISH)发送消息，订阅者(SUBSCRIBE)接收消息，可以实现进程间的消息传递
能干什么？
可以订阅任意数量的频道，类似微信关注多个公众号
当有新消息通过PUBLISH命令发送给频道channel1时
发布/订阅其实是一个轻量的队列，只不过数据不会被持久化，一般用来处理实时性较高的异步消息
常用命令
SUBSCRIBE channel [channel …]
订阅给定的一个或多个频道的消息，推荐先执行订阅后再发布，订阅成功之前发布的消息是收不到的
订阅的客户端每次可以收到3个参数的消息
- 消息的种类
- 始发频道的名称
- 实际的消息内容
PUBLISH channel message
发布消息到执行的频道
订阅了c1频道的可以接收到“helloc1”的这串信息
PSUBSCRIBE pattern [pattern …]
按照模式批量订阅，订阅一个或多个符合给定模式(支持*号?号之类的)的频道
PUBSUB subcommand [argument [argument …]]
查看订阅与发布系统状态
PUBSUB CHANNELS
由活跃频道组成的列表
PUBSUB NUMSUB [channel [channel …]]
某个频道有几个订阅者
PUBSUB NUMPAT
只统计使用PSUBCRIBE命令执行的，返回客户端订阅的唯一模式的数量
UNSUBSCRIBE [channel [channel …]]
取消订阅
PUNSUBSCRIBE [pattern [pattern …]]
退订所有给定模式的频道
PUB/SUB总结
Redis可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流。（不建议使用，redis就做好分布式缓存功能就行了，专业的事情交给专业的中间件处理）
缺点
- 发布的消息在Redis系统中不能持久化，因此，必须先执行订阅再等消息发布，如果先发布了信息，那么该消息由于没有订阅者，消息将被直接丢弃
- 消息只管发送对于发布者而言消息是即发即失的，不管接收，也没有ACK机制，无法保证消息的消费成功
以上的缺点导致了Redis的PUB/SUB模式就像个小玩具，在生产环境中几乎无用武之地，为此，Redis5.0版本新增了Stream数据结构，不但支持多播，还支持数据持久化，相比PUB/SUB更加强大
