【承】Redis 原理篇——Redis 发布/订阅模式

前言

关于 Redis 的“起承转合”，我前面已经用五个篇章的长度作了一个 Redis 基础篇——“起”篇的详细阐述，相信大家无论之前有没有接触过 Redis，都能从中学到不少东西。基础篇的内容顾名思义，只是个基础，主要说了 Redis 的发展以及 Redis 的基本数据类型，内容跟平时使用关联会比较大，难度不算大，希望大家能好好消化。
这里送上基础篇的飞机票：
【起】Redis 概述篇——带你走过 Redis 的前世今生
【起】Redis 基础篇——基本数据结构之String，Hash
【起】Redis 基础篇——基本数据结构之 List，Set
【起】Redis 基础篇——基本数据结构之 ZSet，Bitmap…
【起】Redis 基础篇——基本数据结构之总结篇

在“承”篇中，我会围绕 Redis 的原理来阐述，讲一些相对比较高级的特性，比如本篇章要讲到的 pub/sub（发布/订阅）模式，持久化机制，高性能特性，事务，内存回收机制等等，在接下来的篇章中，我会为大家穿针引线，把每个篇章的内容都串起来，这里就先不占用大家的前言篇章。

那话归正题，我们今天来看一下关于 Redis 的发布/订阅模式。

正文

发布/订阅模式

列表的局限

前面我们说通过队列的 rpush 和 lpop 可以实现消息队列（队尾进队头出），但是消费者需要不停地调用 lpop 查看 List 中是否有等待处理的消息（比如写一个 while 循环）。

为了减少通信的消耗，可以 sleep()一段时间再消费，但是会有两个问题：

1. 如果生产者生产消息的速度远大于消费者消费消息的速度，List 会占用大量的内存；
2. 消息的实时性降低；

list 还提供了一个阻塞的命令：blpop，没有任何元素可以弹出的时候，连接会被阻塞。

blpop queue 5

基于 list 实现的消息队列，不支持一对多的消息分发。

发布订阅模式

除了通过 list 实现消息队列之外，Redis 还提供了一组命令实现发布/订阅模式。
这种方式，发送者和接收者没有直接关联（实现了解耦），接收者也不需要持续尝试获取消息。

订阅频道

首先，我们有很多的频道（channel），我们也可以把这个频道理解成 queue。

订阅者可以订阅一个或者多个频道。

消息的发布者（生产者）可以给指定的频道发布消息。

只要有消息到达了频道，所有订阅了这个频道的订阅者都会收到这条消息。

需要注意的点是，发出去的消息不会被持久化，因为它已经从队列里面移除了，所以消费者只能收到它开始订阅这个频道之后发布的消息。

下面我们来看一下发布订阅命令的使用方法。

订阅者订阅频道：可以一次订阅多个，比如这个客户端订阅了 3 个频道。

subscribe channel-1 channel-2 channel-3

发布者可以向指定频道发布消息（并不支持一次向多个频道发送消息）：

publish channel-1 2673

取消订阅（不能在订阅状态下使用）：

unsubscribe channel-1

按规则（Pattern）订阅频道

支持?和*占位符。?代表一个字符，*代表 0 个或者多个字符。

消费端 1，关注运动信息:

psubscribe *sport

消费端 2，关注所有新闻：

psubscribe news*

消费端 3，关注天气新闻：

psubscribe news-weather

生产者，发布 3 条信息

publish news-sport yaoming
publish news-music jaychou
publish news-weather rain

By the way

有问题？可以给我留言或私聊
有收获？那就顺手点个赞呗~

当然，也可以到我的公众号下「6曦轩」，

回复“学习”，即可领取一份
【Java工程师进阶架构师的视频教程】~

回复“面试”，可以获得：
【本人呕心沥血整理的 Java 面试题】

回复“MySQL脑图”，可以获得
【MySQL 知识点梳理高清脑图】

还有【阿里云】【腾讯云】的购买优惠噢~具体请联系我

曦轩我是科班出身的程序员，php，Android以及硬件方面都做过，不过最后还是选择专注于做 Java，所以有啥问题可以到公众号提问讨论（技术情感倾诉都可以哈哈哈），看到的话会尽快回复，希望可以跟大家共同学习进步，关于服务端架构，Java 核心知识解析，职业生涯，面试总结等文章会不定期坚持推送输出，欢迎大家关注~~~