Redis发布订阅：美丽的陷阱与不宜之境

薛伟同学

已于 2024-01-10 09:15:54 修改

阅读量7.2k

点赞数 4

CC 4.0 BY-SA版权

分类专栏：消息队列：探索消息架构的未知领域数据库：解锁数据之美的代码魔法文章标签： redis

于 2021-08-09 17:33:48 首次发布

本文链接：https://blog.csdn.net/weixin_53287520/article/details/119543049

数据库：解锁数据之美的代码魔法同时被 2 个专栏收录

20 篇文章

订阅专栏

消息队列：探索消息架构的未知领域

15 篇文章

订阅专栏

本文探讨了Redis作为消息队列的使用，包括发布/订阅模式的运作原理及其在缓存、排行榜等场景的应用。然而，由于无法持久化数据和对客户端在线状态的依赖，Redis并不适合大规模、高稳定性的消息传递，可能导致消息丢失和系统不稳定。因此，尽管Redis可以临时充当消息队列，但并不推荐将其用于关键的消息传递任务。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

做后端开发的童鞋肯定都知道Redis，这是一个性能非常不错的非关系型数据库，通常扮演缓存的角色来存在于项目当中。

Redis的应用场景还是不少的，比如：缓存、排行榜、分布式会话、分布式锁、计数器、简单的消息队列等。

对于它能当一个简单的消息队列这件事，我还是比较好奇的，所以最近就研究了一下，随手写下这篇文章来做个总结。

先说结论：Redis的确可以充当消息队列，但是不推荐。

发布/订阅（pub/sub）

Publish/Subscribe 是目前广泛使用的通信模型，它采用事件作为基本的通信机制，提供大规模系统所要求的松散耦合的交互模式。订阅者（如客户端）以事件订阅的方式表达出它有兴趣接收的一个事件或一类事件；发布者（如服务器）可将订阅者感兴趣的事件随时通知相关订阅者。

简单总结就是：

发布订阅 (Pub/Sub) 是一种消息通信模式：发送者 (Pub) 发送消息，订阅者 (Sub) 接收消息。

熟悉设计模式的童鞋应该了解这与23种设计模式中的观察者模式极为相似。

Redis的发布/订阅

在Redis中，每个客户端可以订阅任意数量的频道（Channel）。

下图展示了频道channel1，以及订阅这个频道的三个客户端之间的关系：

当有新消息通过PUBLISH命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端：

演示如下：

客户端常用命令

命令	解释
publish channel message	向指定的channel中发布消息
subscribe channel1 [channel2…]	订阅给定的一个或多个渠道的消息
unsubcribe [channel1 [channel2…]]	取消订阅给定的一个或多个渠道的消息
psubscribe pattern1 [pattern2…]	订阅一个或多个符合给定模式的频道
punsubscribe [pattern1 [pattern2…]]	退订所有给定模式的频道
pubsub channel	列出至少有一个订阅者的频道
pubsub numsub [channel…]	列出给定频道的订阅者数量

Java整合Redis的发布订阅

以SpringBoot项目为例，整合Redis实现发布订阅。

引入依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

配置Redis的连接信息

通过查看RedisTemplate的源码，我发现如果你是在本地电脑上启动的Redis，而且端口是默认的，那么下面的配置信息可以不写。

spring.redis.database=0
spring.redis.host=localhost
spring.redis.port=6379

消费者

@Component
public class RedisReceiver {

    public void receiveMessage(String jsonMsg){
        System.out.println("receiveMessage 消费了消息：" + jsonMsg);
    }
}

生产者

@EnableScheduling
@Component
public class PublishService {

    @Autowired
    private RedisTemplate redisTemplate;

    @Scheduled(fixedRate = 5000)
    public void hello() {
        redisTemplate.convertAndSend("world", JSONObject.toJSONString(System.currentTimeMillis()));
    }
}

消息配置类

@Configuration
@EnableCaching
public class RedisMessageConfig {

    @Bean
    public RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory, MessageListenerAdapter listenerAdapter) {
        RedisMessageListenerContainer container = new RedisMessageListenerContainer();
        container.setConnectionFactory(connectionFactory);
        container.addMessageListener(listenerAdapter, new PatternTopic("world"));
        return container;
    }

    @Bean
    public MessageListenerAdapter listenerAdapter(RedisReceiver receiver) {
        MessageListenerAdapter listenerAdapter = new MessageListenerAdapter(receiver, "receiveMessage");
        listenerAdapter.setSerializer(new JdkSerializationRedisSerializer());
        return listenerAdapter;
    }

    @Bean
    public StringRedisTemplate template(RedisConnectionFactory connectionFactory) {
        return new StringRedisTemplate(connectionFactory);
    }
}

效果

生产者每5秒会往名叫world的频道中发送当前系统的时间戳，消费者获取到消息并打印到控制台。

分析

消息队列通常适用于多个不同的系统进行信息通信，如果把上面的消费者和生产者分别写在不同的项目中，就会发现，如果你的消费者突然意外挂掉了，由于使用Redis作为消息队列这种方案是无法将数据进行持久化的，所以不可避免的会导致消息的丢失！

这种方案的的缺陷就在于客户端必须一直在线才能接收到消息。

结论

不推荐Redis作为消息队列的原因有以下两点：

系统稳定性：在旧版的Redis中，如果一个客户端订阅了某个或者某些频道，但是它读取消息的速度不够快，那么不断的积压的消息就会使得Redis输出缓冲区的体积越来越大，这可能会导致Redis的速度变慢，甚至直接崩溃。也可能会导致Redis被操作系统强制杀死，甚至导致操作系统本身不可用。
数据可靠性：任何网络系统在执行操作时都可能会遇到断网的情况。而断线产生的连接错误通常会使得网络连接两端中的一端进行重新连接。如果客户端在执行订阅操作的过程中断线，那么客户端将会丢失在断线期间的消息，这在很多业务场景下是不可忍受的。

参考资料

https://www.cnblogs.com/xinde123/p/8489054.html
https://my.oschina.net/u/2457218/blog/3065021