Redis实现消息队列整理笔记
Redis 的消息队列
- Redis 可以作为消息队列，使用简单。
- 应用的场景：
- 数据场景简单和单一
- 能够容忍数据丢失
实现方式
List
原理
- Redis的列表是使用双向链表实现的，保存了头节点和尾节点，所以在列表的头部和尾部两边插入或获取元素都是非常快的，时间复杂度为O(1)。
模式
- lpush/rpush(推送消息)
- rpop/lpop(拉取消息 非阻塞)
- brpop/blpop(拉取消息 支持阻塞)：避免不停的调用rpop方法查看redis的list中是否有待处理的数据（消息）。每调用一次都会发起一次连接，有可能list中没有数据，造成大量的空轮询，导致造成不必要的浪费。
特点
- 简单易用且高效。
- 多个消费端可以同时分摊消费
- 消息支持持久化，消费者宕机不影响队列中的消息。如果消费力弱，会导致内存消耗。
pub/sub 发布/订阅
简单的传递消息，无法支持持久化。
特点
- 每个消费者可以消费一份完整的队列数据，不是分摊的。
- 不支持持久化，消费者宕机的话会错过消费消息。
- 如果消费能力弱，超过每个消费者缓冲区最大空间，会被直接踢下线，且缓冲区数据清除。
stream模式
支持发布订阅，且能持久化，基本具备传统mq系统的特性了，但是不推荐使用，与其用这个相对复制的stream模式的消息队列，还不如使用专业的消息中间件。
总结
- 推荐 List 模式：消费者宕机不会错过消息、足够的消费能力、多个消费者分摊消息。
- 推荐 pub/sub 模式：多个消费者同时消费完整的相同数据。
- 其他场景使用专业的消息中间件。
与MQ消息中间对比
可靠性和机制不一样
- 使用 redis 的消息发布与订阅实现消息队列，不支持持久化，要求消费者在生产者之前启动。然而消息中间件则不需要。
- redis 本身的并发量限制无法实现大数据量处理。然后消息中间件支持大数据量处理。