Redis Pub/Sub模式的主要缺点 消息可靠性无法保障 具体表现:Redis的Pub/Sub模式不会对消息进行持久化。如果订阅者在消息发布时未连接到Redis服务器,它们将无法接收到这些消息。这意味着在订阅者断开连接或重新启动期间发布的消息可能会丢失。 可能带来的问题:对于需要确保消息传递可靠性的应用程序,这种消息丢失可能导致...
2.没有ack机制; redis pub/sub是一个要即时消费的MQ,如果消费晚了,数据就会丢失。因此在使用redis pub/sub作为MQ的时候,我们通常要用一个线程轮询去sub,丢到内存队列中等待处理线程去处理,这带来了消费者服务资源不必要的损耗。 可能是为了解决这些问题吧,redis5.0增加一个新的数据类型Streams,这个数据类型的特点...
消息不能持久化 因为PubSub的消息并非是Redis的一种数据类型,所以PubSub中数据是没有得到aof等持久化机制的支持的,既一旦节点崩溃,重新上线后,消息是会丢失的。这一点在Redis 5.0的Stream新数据结构中得到了改善 也正因为PubSub模块的这些缺点,在严谨的消息队列领域,Redis的PubSub模型上不了主舞台,只能做一下简单...
1.Pub/Sub Pub/Sub模式的缺点: 消息的发布是无状态的,无法保证可达。对于发布者来说,消息是“即发即失”的。 此时如果某个消费者在生产者发布消息时下线,重新上线之后, 是无法接收该消息的,要解决该问题需要使用专业的消息队列,如 Kafka … 此处不再赘述。 #在redis-cli下, 开两个窗口C1, C2: #C1执行 s...
前面我们讲了 Redis 消息队列的使用方法,但是没有提到 Redis 消息队列的不足之处,那就是它不支持消息的多播机制。 消息多播 消息多播允许生产者生产一次消息,中间件负责将消息复制到多个消息队列,每个消息队列由相应的消费组进行消费。它是分布式系统常用的一种解耦方式
Redis Stream 主要用于消息队列(MQ,Message Queue),Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能,但它有个缺点就是消息无法持久化,如果出现网络断开、Redis 宕机等,消息就会被丢弃。 简单来说发布订阅 (pub/sub) 可以分发消息,但无法记录历史消息。
以上的缺点导致Redis的Pub/Sub模式就像个小玩具,在生产环境中几乎无用武之地,为此 Redis5.0版本新增了Stream数据结构,不但支持多播,还支持数据持久化,相比Pub/Sub更加的强大,其次更建议还是redis做好缓存,而消息中间件的操作交给专业的中间件例如RebbitMQ完成 ...
Pub/Sub 常用命令: 2.3 Streams 实现消息队列 Redis 发布订阅 (pub/sub) 有个缺点就是消息无法持久化,如果出现网络断开、Redis 宕机等,消息就会被丢弃。而且也没有 Ack 机制来保证数据的可靠性,假设一个消费者都没有,那消息就直接被丢弃了。 后来Redis 的父亲 Antirez,又单独开启了一个叫 Disque 的项目来完善...