Redis知识梳理(2) [ 延时队列 ]

小鱼儿 2022-02-03 12:41 328阅读 0赞

对于那些只有一组消费者的消息队列， 使用 Redis 就可以非常轻松的搞定。Redis 的消息队列不是专业的消息队列，它 没有非常多的高级特性，没有 ack 保证，如果对消息的可靠性有着极致的追求， 那么它就不适合使用。

Redis 的 list(列表) 数据结构常用来作为异步消息队列使用，使用 rpush/lpush 操作入队列，

使用 lpop 和 rpop 来出队列。

![img][]

队列空,解决方案.

通常我们使用 sleep 来解决这个问题，让线程睡一会，睡个 1s 钟就可以了。

不 但客户端的 CPU 能降下来，Redis 的 QPS 也降下来了。

time.sleep(1) \# python 睡 1s

Thread.sleep(1000) \# java 睡 1s

![img][img 1]

# 阻塞读 #

blpop/brpop。

这两个指令的前缀字符 b 代表的是 blocking ，也就是阻塞读。

阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，则立刻醒 过来。消息的延迟几乎为零。

**用 blpop/brpop 替代 lpop/rpop ，就完美解 决了上面的问题。**

# **空闲连接自动断开** #

如果线程一直阻塞在哪里，Redis 的客户端连接就成了闲置连接，闲置过久，

服 务器一般会主动断开连接，减少闲置资源占用。这个时候 blpop/brpop 会抛出异 常来。

# 锁冲突处理 #

\\1. 直接抛出异常，通知用户稍后重试;

\\2. sleep 一会再重试;  
\\3. 将请求转移至延时队列，过一会再试;

## 直接抛出特定类型的异常 ##

这种方式比较适合由用户直接发起的请求，用户看到错误对话框后，会先阅读对话框的内容，再点击重试，

这样就可以起到人工延时的效果。如果考虑到用户体验，可以由前端的代码替代用户自己来进行延时重试控制。

它本质上是对当前请求的放弃，由用户决定是否重新发起新的请求。

## sleep ##

sleep 会阻塞当前的消息处理线程，会导致队列的后续消息处理出现延迟。

如果 碰撞的比较频繁或者队列里消息比较多，sleep 可能并不合适。

如果因为个别死 锁的 key 导致加锁不成功，线程会彻底堵死，

导致后续消息永远得不到及时处 理。

## 延时队列 ##

这种方式比较适合异步消息处理，将当前冲突的请求扔到另一个队列延后处理以避开冲突。

### 延时队列的实现 ###

延时队列可以通过 Redis 的 zset(有序列表) 来实现。

我们将消息序列化成一个 字符串作为 zset 的 value ，这个消息的到期处理时间作为 score ，

然后用多个 线程轮询 zset 获取到期的任务进行处理，多个线程是为了保障可用性，

万一挂 了一个线程还有其它线程可以继续处理。

因为有多个线程，所以需要考虑并发争 抢任务，确保任务不能被多次执行。

def delay(msg):  
[msg.id][] = str(uuid.uuid4()) \# 保证 value 值唯一  
value = json.dumps(msg)  
retry\_ts = time.time() + 5 \# 5 秒后重试  
redis.zadd(“delay-queue”, retry\_ts, value)

def loop():  
while True:  
\# 最多取 1 条  
values = redis.zrangebyscore(“delay-queue”, 0, time.time(), start=0, num=1)  
if not values:  
time.sleep(1) \# 延时队列空的，休息 1s  
continue  
value = values\[0\] \# 拿第一条，也只有一条  
success = redis.zrem(“delay-queue”, value) \# 从消息队列中移除该消息  
if success: \# 因为有多进程并发的可能，最终只会有一个进程可以抢到消息  
msg = json.loads(value)  
handle\_msg(msg)

Redis 的 zrem 方法是多线程多进程争抢任务的关键，它的返回值决定了当前实 例有没有抢到任务，

因为 loop 方法可能会被多个线程、多个进程调用，

同一个 任务可能会被多个进程线程抢到，通过 zrem 来决定唯一的属主。

同时，我们要注意一定要对 handle\_msg 进行异常捕获，避免因为个别任务处 理问题导致循环异常退出。

以下是 Java 版本的延时队列实现，因为要使用到 Json 序列化，所以还需要 fastjson 库的支持。

import java.lang.reflect.Type;
    import java.util.Set;
    import java.util.UUID;
    import com.alibaba.fastjson.JSON;
    import com.alibaba.fastjson.TypeReference;
    import com.fasterxml.jackson.core.type.TypeReference;
    import redis.clients.jedis.Jedis;
    
        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;
            }
    
            TaskItem<T> task = new TaskItem<T>();
            task.id = UUID.randomUUID().toString(); // 分配唯一的 uuid
            task.msg = msg;
            String s = JSON.toJSONString(task); // fastjson 序列化
            jedis.zadd(queueKey, System.currentTimeMillis() + 5000, s); // 塞入延时队列 ,5s 后再试
        }
        public void loop() { 
            while (!Thread.interrupted()) { 
                // 只取一条
                Set<String> values = jedis.zrangeByScore ( queueKey, 0, System.currentTimeMillis());
                if(values.isEmpty()) { 
    
                    try { 
                        Thread.sleep(500); // 歇会继续
                    } catch (InterruptedException e) { 
                        break;
                    }
                    continue;
                }
                String s = values.iterator().next();
                if (jedis.zrem(queueKey, s) > 0) {  // 抢到了
                    TaskItem<T> task = JSON.parseObject(s, TaskType); // fastjson 反序列化
                    this.handleMsg(task.msg);
                }
            }
        }
        public void handleMsg(T msg) { 
            System.out.println(msg);
        }
    
        public static void main(String[] args) { 
            Jedis jedis = new Jedis();
            RedisDelayingQueue<String> queue = new RedisDelayingQueue<>(jedis, "q-demo");
            Thread producer = new Thread() { 
                public void run() { 
                    for (int i = 0; i < 10; i++) { 
                        queue.delay("codehole" + i);
                    }
                } };
            Thread consumer = new Thread() { 
                public void run() {  queue.loop();
                }
            };
            producer.start();
            consumer.start(); try { 
                producer.join();
                Thread.sleep(6000);
                consumer.interrupt();
                consumer.join();
            } catch (InterruptedException e) { 
            }
        }
    
    
    }

上面的算法中同一个任务可能会被多个进程取到之后再使用zrem进行争抢，那 些没抢到的进程都是白取了一次任务，这是浪费。可以考虑使用lua scripting来 优化一下这个逻辑，将zrangebyscore和zrem一同挪到服务器端进行原子化操 作，这样多个进程之间争抢任务时就不会出现这种浪费了。

[img]: /images/20220203/7ab16fc787ed4076bb879d51d6ad9fbf.png
[img 1]: /images/20220203/42867bc72a7741158182b29857d1b74f.png
[msg.id]: http://msg.id