消息队列
- 消息队列：存储和管理队列，消息代理
- 生产者：发送消息到消息队列
- 消费者：从消息队列获取消息并处理消息
优点
- 消息队列独立于jvm存在，不依赖jvm内存
- 消息队列会确保数据安全，会对其中的数据持久化，会在消息头这里要求消费者做确认，消费者没有确认就一直存在
Redis实现方式
redis提供了三种不同的方式实现消息队列
list结构：基于list结构模拟消息队列
- 使用brlush，blpop实现阻塞获取和添加
- 缺点：无法避免数据丢失，如果刚从队列中取出Redis就宕机了，那么数据就丢失了，只支持单消费者
- 优点：基于Redis，可以持久化数据，不受限于jvm，满足消息有序性
pubsub：基本的点对点消息模型
消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息，就实现了多消费者
subscribe channel[channel] #订阅一个或多个频道 publish channel msg #向一个频道发送消息 psubscribe pattern[pattern] #订阅与pattern格式匹配的所有频道缺点：不支持数据持久化，无法避免数据丢失，消息堆积有上限，超出时数据丢失
Stream：比较完善的消息队列模型
Redis5引入的一种新的数据类型
消息可以回溯，可以被多个消费者读取
但是由于$代表读最新的消息，如果我们处理一条消息的过程中，又有超过一条消息到达消息队列，则下次只能获取最新的那条消息，出现漏读消息的问题
消费者组
基于Stream的消息队列
将多个消费者划分到一个组中，监听同一个队列
- 消息分流：队列中的消息会分流给组内不同的消费者，从而加快消息处理的速度
- 消费者组会维护一个标识，记录最后一个被处理的消息，就算redis宕机重启，还会从标识之后读取消息，防止了漏读消息问题
- 消息确认：消费者获取消息后消息处于pending状态，并存入一个pending-list，处理完成后要通过xack来确认消息，消息确认后才会被从pending-list中移除，防止了消费者获取消息后宕机，导致消息丢失的问题
一般不需要手动创建消费者，当我们指定一个组去监听消息时，如果他发现组中没有消费者，会自动帮我们创建
确定消息被处理过了
xack key group id[id……]
Stream类型消息队列的xreadgroup命令特点
- 消息可回溯
- 可以多消费者争抢资源，加快消费速度
- 可以阻塞读取
- 没有消息漏读风险
- 有消息确认机制，保证消息至少被消费一次
