Redis精通系列——Pub/Sub(发布订阅)

  本文已收录于专栏


《Redis精通系列》


上千人点赞收藏,全套Redis学习资料,大厂必备技能!


目录


1、简介


2、实例演示


2.1 普通订阅


2.2 模式订阅


3、Pub/Sub为什么被抛弃


1、简介

李子捌把话说在前头,如果你是面试或者为了了解知识来学习这一知识点,我觉得是有必要的;但是如果你是作为公司的技术负责人或者项目技术选型来使用Redis的Pub/Sub做消息的发布订阅,如果你不是走投无路了,那么你可能值得斟酌一下。Redis的Pub/Sub发布订阅,是Redis一步步完善消息队列功能的一个进步点,虽然现在没人用Pub/Sub做消息队列,但是它的思想和功能也是值得玩一下的,这个就是我写这篇文章的主要原因。


Redis 发布订阅 (pub/sub) 是一种消息通信模式:发送者 (pub) 发送消息,订阅者 (sub) 接收消息。


pub -> publisher

sub -> subscriber

Redis客户端订阅一个频道非常简单,它可以订阅任意数量的频道。

如下图,Redis客户端订阅(subscriber)频道(channel)Redis精通系列——Pub/Sub(发布订阅)Redis精通系列——Pub/Sub(发布订阅)Redis精通系列——Pub/Sub(发布订阅)Redis精通系列——Pub/Sub(发布订阅)Redis精通系列——Pub/Sub(发布订阅)Redis精通系列——Pub/Sub(发布订阅)3、Pub/Sub为什么被抛弃

关于Redis的Pub/Sub为什么被抛弃,最主要的原因是它无法持久化,没有实现持久化机制的Pub/Sub,无法做到消息的不丢失,在客户端宕机或者Redis服务宕机的情况下,都会导致消息丢失。


客户端宕机,客户端无法接收消息

Redis服务宕机,没有客户端能连接上,肯定也无法接收到消息

大部分情况下,我们都不会用到Redis去做消息中间件,市面上成熟且好用的消息中间件非常多,如果真的需要使用Redis来做消息中间件,可以考虑Redis 5.0的新数据结构Stream,这个功能在Pub/Sub的基础上,实现了持久化机制,并且大力借鉴了kafka的设计原理,完善了Redis用于实现消息队列的不足之处。


关于stream的知识点,请查看我的Redis专栏!




上一篇:Linux主辅DNS数据不同步故障排除


下一篇:剖析 Elasticsearch 源码,解读 ES 在 index、create 时的原理