pub&sub(发布&订阅)
发布/订阅
是一种消息通信模式:发送者(publish)发送消息,订阅者(subscribe)接受消息,可以实现进程间的消息传递
Redis 可以实现消息中间件 MQ 的功能,通过发布订阅实现消息的引导和分流。不推荐使用该功能,专业的事情交给专业的中间件,redis就做好分布式缓存功能
能干嘛?
redis 客户端可以订阅任意数量的频道,类似我们微信关注多个公众号

- 当有新的消息通过 publish 命令发送给频道 channel1 时
总结:
发布/订阅其实是一个轻量的队列,只不过数据不会被持久化,一般用来处理实时性较高的异步消息

常用命令
subscribe channel [channel...] |
- 订阅给定的一个或多个频道的信息
- 推荐先执行订阅后再发布,订阅成功之前发布的消息是收不到的
- 订阅的客户端每次可以收到一个3个参数的消息
- 消息的种类
- 始发频道的名称
- 实际的消息内容
publish channel message |
- 发布消息到指定的频道
psubscribe pattern[pattern...] |
按照模式批量订阅,订阅一个或多个符合给定模式(支持*号?号之类的)频道
pubsub subcommand [argument [argument ...]] |
- 查看订阅与发布系统状态
pubsub channels |
由活跃频道组成的列表

pubsub numsub [channel [channel...]] |
- 某个频道有几个订阅者
pubsub numpay |
- 只统计使用 pubscribe 命令执行的,返回客户端订阅的唯一模式的数量

unsubscribe [channel [channel...]] |
- 取消订阅
punsubscribe [pattern [pattern...]] |
- 退订所有给定模式的频道
总结
- redis 可以实现消息中间件 MQ 的功能,通过发布订阅实现消息的引导和分流。不推荐使用该功能,专业的事情交给专业的中间件出来,redis就做好分布式缓存功能
- pub/sub 缺点
- 发布的消息在 redis 系统中不能持久化,因此,必须先订阅,再等待消息发布。如果先发布了消息,那么该消息由于没有订阅者,消息将被直接丢弃
- 消息只管发送对于发布者而言消息是即发即失的,不管接收,也没有 ack 机制,无法保证消息的消费成功。
- 以上的缺点导致redis的pub/sub模式就像个小玩具,在生产环境中几乎无用武之地,为此redis 5.0 版本新增了 stream 数据结构,不但支持多播,还支持数据持久化,相比 pub/sub 更加的强大
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Lazy的个人博客!





