消息队列Redis实现

消息队列

redis提供了三种不同的方式实现消息队列

list结构：基于list结构模拟消息队列
- 使用brlush，blpop实现阻塞获取和添加
- 缺点：无法避免数据丢失，如果刚从队列中取出Redis就宕机了，那么数据就丢失了，只支持单消费者
- 优点：基于Redis，可以持久化数据，不受限于jvm，满足消息有序性
pubsub：基本的点对点消息模型
- 消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息，就实现了多消费者
  bash 复制代码
```
subscribe channel[channel] #订阅一个或多个频道
publish channel msg #向一个频道发送消息
psubscribe pattern[pattern] #订阅与pattern格式匹配的所有频道
```
- 缺点：不支持数据持久化，无法避免数据丢失，消息堆积有上限，超出时数据丢失
Stream：比较完善的消息队列模型
- Redis5引入的一种新的数据类型
- 消息可以回溯，可以被多个消费者读取
- 但是由于$代表读最新的消息，如果我们处理一条消息的过程中，又有超过一条消息到达消息队列，则下次只能获取最新的那条消息，出现漏读消息的问题

基于Stream的消息队列

将多个消费者划分到一个组中，监听同一个队列

消息分流：队列中的消息会分流给组内不同的消费者，从而加快消息处理的速度
消费者组会维护一个标识，记录最后一个被处理的消息，就算redis宕机重启，还会从标识之后读取消息，防止了漏读消息问题
消息确认：消费者获取消息后消息处于pending状态，并存入一个pending-list，处理完成后要通过xack来确认消息，消息确认后才会被从pending-list中移除，防止了消费者获取消息后宕机，导致消息丢失的问题

一般不需要手动创建消费者，当我们指定一个组去监听消息时，如果他发现组中没有消费者，会自动帮我们创建

确定消息被处理过了

bash 复制代码

xack key group id[id......]

Stream类型消息队列的xreadgroup命令特点