消息队列
Redis 的 list(列表) 数据结构常用来作为异步消息队列使用,使用rpush/lpush操作入队列, 使用 lpop 和 rpop 来出队列。
客户端是通过队列的 pop 操作来获取消息,然后进行处理。处理完了再接着获取消息, 再进行处理。如此循环往复,这便是作为队列消费者的客户端的生命周期。
可是如果队列空了,客户端就会陷入 pop 的死循环,不停地 pop,没有数据,接着再 pop, 又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的 CPU,redis 的 QPS 也 会被拉高,如果这样空轮询的客户端有几十来个,Redis 的慢查询可能会显著增多。
通常使用 sleep 来解决这个问题,让线程睡一会,睡个 1s 钟就可以了。不但客户端 的 CPU 能降下来,Redis 的 QPS 也降下来了。
延时队列
用上面睡眠的办法可以解决问题。但是有个小问题,那就是睡眠会导致消息的延迟增大。 如果只有 1 个消费者,那么这个延迟就是 1s。如果有多个消费者,这个延迟会有所下降,因 为每个消费者的睡觉时间是岔开来的。
有没有什么办法能显著降低延迟呢?,那就是 blpop/brpop。这两个指令的前缀字符 b 代表的是 blocking,也就是阻塞读。
阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。消 息的延迟几乎为零。用 blpop/brpop 替代前面的 lpop/rpop,就完美解决了上面的问题。
空闲连接自动断开
如果线程一直阻塞在哪里,Redis 的客户端连接就成了闲置连接,闲置过久,服务器一般会主动断开连接,减少闲置资源占用。这个时候 blpop/brpop 会抛出异常来。
所以编写客户端消费者的时候要小心,注意捕获异常,还要重试。
锁冲突处理
客户端在处理请求时加锁没加成功一般有 3 种策略来处理加锁失败:
- 直接抛出异常,通知用户稍后重试;
- sleep一会再重试;
- 讲请求转移至延时队列,过一会再试;
直接抛出特定类型的异常
这种方式比较适合由用户直接发起的请求,用户看到错误对话框后,会先阅读对话框的内 容,再点击重试,这样就可以起到人工延时的效果。如果考虑到用户体验,可以由前端的代码 替代用户自己来进行延时重试控制。它本质上是对当前请求的放弃,由用户决定是否重新发起 新的请求。
sleep
sleep 会阻塞当前的消息处理线程,会导致队列的后续消息处理出现延迟。如果碰撞的比 较频繁或者队列里消息比较多,sleep 可能并不合适。如果因为个别死锁的 key 导致加锁不成 功,线程会彻底堵死,导致后续消息永远得不到及时处理。
延时队列
这种方式比较适合异步消息处理,将当前冲突的请求扔到另一个队列延后处理以避开冲突。
延时队列的实现
延时队列可以通过 Redis 的 zset(有序列表) 来实现。我们将消息序列化成一个字符串作 为 zset 的 value,这个消息的到期处理时间作为 score,然后用多个线程轮询 zset 获取到期 的任务进行处理,多个线程是为了保障可用性,万一挂了一个线程还有其它线程可以继续处 理。因为有多个线程,所以需要考虑并发争抢任务,确保任务不能被多次执行。
Redis 的 zrem 方法是多线程多进程争抢任务的关键,它的返回值决定了当前实例有没有抢到任务, 因为 loop 方法可能会被多个线程、多个进程调用,同一个任务可能会被多个进程线程抢到,通过 zrem 来决定唯一的属主。
同时,我们要注意一定要对 handle_msg 进行异常捕获,避免因为个别任务处理问题导致循环异常退 出。以下是 Java 版本的延时队列实现,因为要使用到 Json 序列化,所以还需要 fastjson 库的支持。
package com.example.demo.book;
import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.TypeReference;
import redis.clients.jedis.Jedis;
import java.lang.reflect.Type;
import java.util.Set;
import java.util.UUID;
/**
* @Author: acton_zhang
* @Date: 2023/4/16 1:54 上午
* @Version 1.0
* Redis延时队列
*/
public class RedisDelayingQueue<T> {
static class TaskItem<T> {
public String id;
public T msg;
}
//fastjson序列化对象中存在generic类型时,需要使用TypeReference
private Type taskType = new TypeReference<TaskItem<T>>(){}.getType();
private Jedis jedis;
private String queueKey;
public RedisDelayingQueue(Jedis jedis, String queueKey) {
this.jedis = jedis;
this.queueKey = queueKey;
}
/**
* 入队
* @param msg 消息
* @param delayTime 延迟时间
*/
public void delay(T msg, long delayTime) {
TaskItem task = new TaskItem();
task.id = UUID.randomUUID().toString();//分配唯一uuid
task.msg = msg;
String s = JSON.toJSONString(task);
jedis.zadd(queueKey, System.currentTimeMillis() + delayTime, s);
}
/**
* 轮询队列取出消息
*/
public void loop() {
while (!Thread.interrupted()) {
//只取一条
Set values = jedis.zrangeByScore(queueKey, 0, System.currentTimeMillis(), 0, 1);
if (values.isEmpty()) {
try {
//没取到则休息一下继续
Thread.sleep(500);
} catch (InterruptedException e) {
break;
}
continue;
}
String s = (String) values.iterator().next();
if (jedis.zrem(queueKey, s) > 0) {//抢到了
TaskItem task = JSON.parseObject(s, taskType);//反序列化
this.handleMsg((T) task.msg);//处理消息
}
}
}
public void handleMsg(T msg) {
System.out.println(msg);
}
public static void main(String[] args) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
jedis.auth("123456");
RedisDelayingQueue queue = new RedisDelayingQueue(jedis, "q-demo");
Thread producer = new Thread() {
@Override
public void run() {
for (int i = 0; i < 10; i++) {
queue.delay("codehole" + i, 5000l);
}
}
};
Thread consumer = new Thread() {
@Override
public void run() {
queue.loop();
}
};
producer.start();
consumer.start();
try {
producer.join();
Thread.sleep(6000);
consumer.interrupt();
consumer.join();
} catch (InterruptedException e) {
//
}
}
}
输出:
codehole0
codehole2
codehole5
codehole4
codehole3
codehole1
codehole6
codehole7
codehole8
codehole9