基于Redis实现任务队列

任务队列

1、List

特点

• 使用list作为任务队列时，最大长度取决于内存的大小，没有限制；
• 当任务队列为空时，消费者拉取消息，会根据不同的操作产生不同的结果：
  • 消费者使用BLPOP等阻塞式操作，会一直阻塞等待新的数据到来，直到超时或有新的数据插入到队列中。
  • 消费者使用的是非阻塞式的取出操作，如LPOP等，当队列为空时，这些操作将返回空值（null）；
• 消息只能被单个消费者消费，无法重复消费；
• redis宕机时，会存在消息丢失问题；

blpop task_queue 60
lpop task_queue
ltrim task_queue 1 4

2、Pub/Sub

pub/sub的最大特点是支持多生产者、多消费者，每个正常的消费端都能获取到生产者发出的消息。
但问题是channel本身并不存储消息，生产者创建的消息，channel会实时地将消息发送给消费端；所以，一旦一个消费者断开连接，那么它将再也无法处理断连过程中生产的消息。
=所以，pub/sub作为消息队列，完全不具备“可靠性”，它的优点在于消息的及时通知其他节点，因此，redis集群中的哨兵模式使用的就是pub/sub模型。
_哨兵模式_最简单的模型如下，哨兵进程通过监控主服务器状态是否正常，如果不正常，就通知所有从服务器。
在这里，从服务器是消费端，哨兵进程所在的服务器是生产者。

3、Stream

Stream主要用于消息队列，从它的支持命令可以看出，和redis list的使用方法类似，但stream支持重复消费，而且消息还能持久化，以及消费确认。

• XADD - 添加消息到末尾
• XTRIM - 对流进行修剪，限制长度
• XDEL - 删除消息
• XLEN - 获取流包含的元素数量，即消息长度
• XRANGE - 获取消息列表，会自动过滤已经删除的消息
• XREVRANGE - 反向获取消息列表，ID 从大到小
• XREAD - 以阻塞或非阻塞方式获取消息列表

消费确认，以示例演示

1. 新建生产者，创建4条消息

2. 创建消费组，表示开始消费的位置，0是指从头部消费消息

3. 以消费组的方式消费消息，但需要指定具体的消费者，即consumer1

4. 通过xpending查看消费组待消费的消息；可以看到因为之前消费消息时，没进行确认，现在任然是4条待消费消息。

5. xack确认消费后，看到待消费消息减少

参考

http://focus-1.wiki/redis/redis-list-blpop/
https://www.runoob.com/redis/redis-stream.html
https://blog.csdn.net/lt_xiaodou/article/details/126525965