《Redis深度历险学习笔记》：Redis的延时队列使用

最新推荐文章于 2023-08-30 18:13:59 发布

天乔巴夏丶

最新推荐文章于 2023-08-30 18:13:59 发布

阅读量249

点赞数

分类专栏： Redis 文章标签：队列 redis 分布式 java

本文链接：https://blog.csdn.net/Sky_QiaoBa_Sum/article/details/110947352

版权

Redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

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

异步消息队列

Redis的list常用来作为异步消息队列使用，使用``rpush/lpush操作入队列，使用lpop/rpop`来出队列。

> rpush stack 1 2 3
(integer) 3
> rpop stack
"3"
> rpop stack
"2"
> rpop stack
"1"
> rpop stack
(nil)

队列空了怎么办？

可以发现客户端通过队列的pop操作来获取消息并进行处理，处理完接着获取消息，不断循环。

如果队列空了，客户端就会不停pop，而陷入死循环。空轮询不但拉高了客户端的 CPU，redis 的 QPS 也会被拉高，如果这样空轮询的客户端有几十来个，Redis 的慢查询可能会显著增多。

通常我们使用 sleep 来解决这个问题，让线程睡一会，睡个 1s 钟就可以了Thread.sleep(1000)。不但客户端的 CPU 能降下来，Redis 的 QPS 也降下来了。

队列延迟问题

用上述睡1s的方法会产生：消息延迟的问题。

如果有一个消费者，消息延迟就是1s，如果有多个消费者，由于大家睡觉的时间岔开，消息延迟会有所下降。

那如何显著降低延迟呢？使用blpop/brpop命令，阻塞读。

阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，就立刻醒过来。消息的延迟几乎为零，完美解决上面的问题。

空闲连接问题

但这个方案又会存在问题：空闲连接。

如果线程一直阻塞在哪里，Redis 的客户端连接就成了闲置连接，闲置过久，服务器一般会主动断开连接，减少闲置资源占用。这个时候``blpop/brpop`会抛出异常来。

所以客户端消费者需要注意捕获异常，并且重试。

延时队列

使用Redis实现分布式锁时，如果客户端加锁失败，我们说过有一种方案就是将当前冲突的请求扔到一个消息队列中，异步处理。

延时队列可以通过 Redis 的 zset(有序列表) 来实现。我们将消息序列化成一个字符串作为 zset 的value，这个消息的到期处理时间作为score，然后用多个线程轮询 zset 获取到期的任务进行处理，多个线程是为了保障可用性，万一挂了一个线程还有其它线程可以继续处理。因为有多个线程，所以需要考虑并发争抢任务，确保任务不能被多次执行。

public class RedisDelayingQueue<T> {

    private final Jedis jedis;
    private final String queueKey;
    private final Gson gson;

    static class TaskItem<T> {
        public String id;
        public T msg;

        @Override
        public String toString() {
            return StrUtil.format("id = {}, msg = {}", id, msg);
        }
    }

    public RedisDelayingQueue(String queueKey) {

        this.queueKey = queueKey;
        this.jedis = new Jedis("localhost");
        this.gson = new Gson();
    }


    public void loop() {
        while (!Thread.interrupted()) {
            // 取出一条记录
            Set<String> values = jedis.zrangeByScore(queueKey, 0, System.currentTimeMillis(), 0, 1);
            if (values.isEmpty()) {
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    break;
                }
            }else {
                String taskStrings = values.iterator().next();
                // 移除获取到的数据
                if (jedis.zrem(queueKey, taskStrings) > 0) {
                    TaskItem item = gson.fromJson(taskStrings, TaskItem.class);
                    executeTask(item);
                }
            }
        }
    }

    private void executeTask(TaskItem<T> item) {
        System.out.println(item);
    }

    public static void main(String[] args) throws InterruptedException {
        String queueKey = "queue-key";
        RedisDelayingQueue<Object> delayingQueue = new RedisDelayingQueue<>(queueKey);
        // 创建生产者
        Thread producer = new Thread(() -> {
            for (int i = 0; i < 10; i++) {
                delayingQueue.delay("delay queue :" + i);
            }
        });
        Thread consumer = new Thread(delayingQueue::loop);
        producer.start();
        consumer.start();

        producer.join();
        // 让消费者线程处理消息
        Thread.sleep(6000);
        consumer.interrupt();
        consumer.join();
    }

    private void delay(T msg) {
        TaskItem taskItem = new TaskItem();
        taskItem.id = UUID.randomUUID().toString();
        taskItem.msg = msg;
        String s = gson.toJson(taskItem);
        jedis.zadd(queueKey, System.currentTimeMillis() + 5000, s);
    }
}

进一步优化延时队列

上面的实现, 在多线程逻辑上也是没有问题的, 假设有两个线程 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 的处理

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

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" +
    "        return ''\n" +
    "    end\n" +
    "else\n" +
    "    return ''\n" +
    "end";


List<String> keys = Arrays.asList(queueKey);
List<String> args = Arrays.asList(String.valueOf(System.currentTimeMillis()));
String taskStrings = (String) jedis.eval(luaScript, keys, args);

Redis延时队列的优势

1.Redis zset支持高性能的 score 排序。

2.Redis是在内存上进行操作的，速度非常快。

3.Redis可以搭建集群，当消息很多时候，我们可以用集群来提高消息处理的速度，提高可用性。

4.Redis具有持久化机制，当出现故障的时候，可以通过AOF和RDB方式来对数据进行恢复，保证了数据的可靠性

Redis延时队列劣势

使用 Redis 实现的延时消息队列也存在数据持久化, 消息可靠性的问题

没有重试机制 - 处理消息出现异常没有重试机制, 这些需要自己去实现, 包括重试次数的实现等

没有 ACK 机制 - 例如在获取消息并已经删除了消息情况下, 正在处理消息的时候客户端崩溃了, 这条正在处理的这些消息就会丢失, MQ 是需要明确的返回一个值给 MQ 才会认为这个消息是被正确的消费了

如果对消息可靠性要求较高, 推荐使用 MQ 来实现

Redis 作为消息队列为什么不能保证 100% 的可靠性？

因为没有ask机制，当消费端崩溃后消息丢失。pop出消息后，list 中就没这个消息了，如果处理消息的程序拿到消息还未处理就挂掉了，那消息就丢失了，所以是不可靠队列。https://redis.io/commands/rpoplpush 这个可以实现可靠队列。

参考阅读

天乔巴夏丶

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
《Redis深度历险学习笔记》：Redis的延时队列使用

Redis 的消息队列不是专业的消息队列，它没有非常多的高级特性，没有 ack 保证，如果对消息的可靠性有着极致的追求，那么它就不适合使用，对于那些只有一组消费者的消息队列，使用 Redis 就可以非常轻松的搞定。异步消息队列Redis的list常用来作为异步消息队列使用，使用``rpush/lpush操作入队列，使用lpop/rpop`来出队列。> rpush stack 1 2 3(integer) 3> rpop stack"3"> rpop stack"2"&gt
复制链接

扫一扫