本文详细介绍了如何使用Redis实现延时队列，包括使用list数据结构作为消息队列，解决空轮询、延迟及空闲连接问题的方法。通过blpop/brpop实现阻塞读，减少延迟，并探讨了分布式锁冲突处理策略，最后讨论了延时队列的优化，如使用lua脚本避免资源浪费。
用户并发量的情况，可以延时2分钟给用户发短信
======================================================================================
我们知道，对于专业的消息队列中间件，如Kafka和RabbitMQ，消费者在消费消息之前要进行一系列的繁琐过程。
如RabbitMQ发消息之前要创建 Exchange，再创建 Queue，还要将 Queue 和 Exchange 通过某种规则绑定起来，发消息的时候要指定 routingkey，还要控制头部信息
但是绝大 多数情况下，虽然我们的消息队列只有一组消费者，但还是需要经历上面一些过程。
有了 Redis，对于那些只有一组消费者的消息队列，使用 Redis 就可以非常轻松的搞定。Redis 的消息队列不是专业的消息队列，它没有非常多的高级特性， 没有 ack 保证，如果对消息的可靠性有着极致的追求，那么它就不适合使用
==============================================================================
Redis 的 list(列表) 数据结构常用来作为异步消息队列使用，使用 rpush/lpush 操作入队列， 使用 lpop 和 rpop 来出队列
rpush queue 月伴飞鱼1 月伴飞鱼2 月伴飞鱼3
(integer) 3
lpop queue
“月伴飞鱼1”
llen queue
(integer) 2
==============================================================================
客户端是通过队列的 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 会抛出异常来。
所以编写客户端消费者的时候要小心，注意捕获异常，还要重试。
============================================================================
假如客户端在处理请求时加分布式锁没加成功怎么办。
=====================================================================================
1、直接抛出异常，通知用户稍后重试；
2、sleep 一会再重试；
3、将请求转移至延时队列，过一会再试；
===============================================================================
这种方式比较适合由用户直接发起的请求，用户看到错误对话框后，会先阅读对话框的内 容，再点击重试，这样就可以起到人工延时的效果。如果考虑到用户体验，可以由前端的代码 替代用户自己来进行延时重试控制。它本质上是对当前请求的放弃，由用户决定是否重新发起 新的请求。
=========================================================================
sleep 会阻塞当前的消息处理线程，会导致队列的后续消息处理出现延迟。如果碰撞的比 较频繁或者队列里消息比较多，sleep 可能并不合适。如果因为个别死锁的 key 导致加锁不成 功，线程会彻底堵死，导致后续消息永远得不到及时处理。
========================================================================
这种方式比较适合异步消息处理，将当前冲突的请求扔到另一个队列延后处理以避开冲突。
===========================================================================
我们可以使用 zset这个命令，用设置好的时间戳作为score进行排序，使用 zadd score1 value1 … 命令就可以一直往内存中生产消息。再利用 zrangebysocre 查询符合条件的所有待处理的任务，通过循环执行队列任务即可。也可以通过 zrangebyscore key min max withscores limit 0 1 查询最早的一条任务，来进行消费
private Jedis jedis;
public void redisDelayQueueTest() { String key = “delay_queue”;
// 实际开发建议使用业务 ID 和随机生成的唯一 ID 作为 value, 随机生成的唯一 ID 可以保证消息的唯一性, 业务 ID 可以避免 value 携带的信息过多
String orderId1 = UUID.randomUUID().toString(); jedis.zadd(queueKey, System.currentTimeMillis() + 5000, orderId1);
String orderId12 = UUID.randomUUID().toString(); jedis.zadd(queueKey, System.currentTimeMillis() + 5000, orderId2);
new Thread() {
@Override public void run() { while (true) {
Set resultList; // 只获取第一条数据, 只获取不会移除数据
resultList = jedis.zrangebyscore(key, System.currentTimeMillis(), 0, 1);
if (resultList.size() == 0) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace(); break;
} } else {
// 移除数据获取到的数据
if (jedis.zrem(key, resultList.get(0)) > 0) {
String orderId = resultList.get(0);
log.info(“orderId = {}”, resultList.get(0));
this.handleMsg(orderId);
} } } } }.start();}public void handleMsg(T msg) { System.out.println(msg);}
上面的实现, 在多线程逻辑上也是没有问题的, 假设有两个线程 T1, T2和其他更多线程, 处理逻辑如下, 保证了多线程情况下只有一个线程处理了对应的消息:
1.T1, T2 和其他更多线程调用 zrangebyscore 获取到了一条消息 A
2.T1 准备开始删除消息 A, 由于是原子操作, T2 和其他更多线程等待 T1 执行 zrem 删除消息 A 后再执行 zrem 删除消息 A
3.T1 删除了消息 A, 返回删除成功标记 1, 并对消息 A 进行处理
4.T2 其他更多线程开始 zrem 删除消息 A, 由于消息 A 已经被删除, 所以所有的删除均失败, 放弃了对消息 A 的处理
同时，我们要注意一定要对 handle_msg 进行异常捕获，避免因为个别任务处理问题导致循环异常退 出
=========================================================================
上面的算法中同一个任务可能会被多个进程取到之后再使用 zrem 进行争抢，那些没抢到 的进程都是白取了一次任务，这是浪费。可以考虑使用 lua scripting 来优化一下这个逻辑，将 zrangebyscore 和 zrem 一同挪到服务器端进行原子化操作，这样多个进程之间争抢任务时就不 会出现这种浪费了
[]
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
(https://blog.youkuaiyun.com/qwe123147369/article/details/108844962)使用调用Lua脚本进一步优化
==================================================================================
Lua 脚本, 如果有超时的消息, 就删除, 并返回这条消息, 否则返回空字符串:
String luaScript = “local resultArray = redis.call(‘zrangebyscore’, KEYS[1], 0, ARGV[1], ‘limit’ , 0, 1)\n” +
“if #resultArray > 0 then\n” +
" if redis.call(‘zrem’, KEYS[1], resultArray[1]) > 0 then\n" +
" return resultArray[1]\n" +
" else\n" +
扫一扫
2743
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
