都在用 MQ，Redis 的 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）

如下图，当消息发送到客户端订阅的频道（channel）时，这个消息就会被订阅的所有未故障的客户端接接收到

2、实例演示

演示 Redis 的发布订阅，我们需要开启多个客户端，订阅频道（channel）。

2.1 普通订阅

如下我会启动 4 个客户端，第一个客户端用来发布消息，其他的用来订阅频道，接收消息。

客户端 2、客户端 3、客户端 4 同时订阅 news 和 weather 频道（channel）

客户端 1 向频道 news/weather 发布消息

此时可以看到三个客户端均接收客户端 1 向频道 news/weather 发布的消息

2.2 模式订阅

Redis 为了方便同时订阅多个模式的频道，也有类似市面上常见的 MQ 中模式订阅功能（如 Rabbit MQ 中的 topic），这个功能可以匹配符的方式进行订阅。

比如我需要订阅以 fund.开头，任意字符结尾的频道，就可以使用如下的订阅方式

尝试向 fund.nuoan 发布消息

订阅了 fund.*的客户端，成功接收到消息

3、Pub/Sub 为什么被抛弃

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

• 客户端宕机，客户端无法接收消息

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

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

关于 stream 的知识点，请查看我的 Redis 专栏！