By

前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

Redis 的消息队列不是专业的消息队列，它没有非常多的高级特性， 没有 ack 保证，如果对消息的可靠性有着极致的追求，那么它就不适合使用

1、异步消息队列

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

image-20210429143455524

> rpush notify-queue apple banana pear 
(integer) 3

> llen notify-queue
(integer) 3
> lpop notify-queue
"apple"
> llen notify-queue
(integer) 2

> lpop notify-queue
"banana"
> llen notify-queue
(integer) 1

> lpop notify-queue
"pear"
> llen notify-queue
(integer) 0

> lpop notify-queue
(nil)

2、队列空了怎么办?

客户端是通过队列的 pop 操作来获取消息，然后进行处理。处理完了再接着获取消息， 再进行处理。如此循环往复，这便是作为队列消费者的客户端的生命周期。

可是如果队列空了，客户端就会陷入 pop 的死循环，不停地 pop，没有数据，接着再 pop， 又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的 CPU，redis 的 QPS 也 会被拉高，如果这样空轮询的客户端有几十来个，Redis 的慢查询可能会显著增多。

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

image-20210429143927912

3、队列延迟

用上面睡眠的办法可以解决问题。但是有个小问题，那就是睡眠会导致消息的延迟增大。 如果只有 1 个消费者，那么这个延迟就是 1s。如果有多个消费者，这个延迟会有所下降，因为每个消费者的睡觉时间是岔开来的。

有没有什么办法能显著降低延迟呢? 你当然可以很快想到:那就把睡觉的时间缩短点。这种方式当然可以，不过有没有更好的解决方案呢? 。

解决方案：当然也有，那就是 blpop/brpop，这两个指令的前缀字符 b 代表的是 blocking，也就是阻塞读

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

4、空闲连接自动断开

⬤ 你以为上面的方案真的很完美么?

⬤ 先别急着开心，其实他还有个问题需要解决。

⬤ 什么问题?—— 空闲连接的问题。

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

解决方案：所以编写客户端消费者的时候要小心，注意捕获异常，还要重试。…

5、延时队列的实现

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

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

2、然后用多个线程轮询 zset 获取到期 的任务进行处理，多个线程是为了保障可用性，万一挂了一个线程还有其它线程可以继续处 理。

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

⬤ 获取数据代码

public Set<String> zrangeByScore(final String key, final double min, final double max,
                                 final int offset, final int count) {
  checkIsInMultiOrPipeline();
  client.zrangeByScore(key, min, max, offset, count);
  final List<String> members = client.getMultiBulkReply();
  if (members == null) {
    return null;
  }
  return SetFromList.of(members);
}

⬤ 代码运行


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;

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


  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;
  }

  public void delay(T msg){
    TaskItem task = new TaskItem();
    task.id = UUID.randomUUID().toString(); //分配谓一值uuid
    task.msg = msg;
    String JSONResultString = JSON.toJSONString(task); //fastjson序列化
    jedis.zadd(queueKey,System.currentTimeMillis()+5000,JSONResultString);  //放入延时队列，5s后再试
  }

  public void loop(){
    while (!Thread.interrupted()){
      //SCORE 从0开始到System.currentTimeMillis()   +  只获取一条
      Set values = jedis.zrangeByScore(queueKey,0,System.currentTimeMillis(),0,1);
      if(values.isEmpty()){
        try {
          Thread.sleep(500);
        } catch (InterruptedException e) {
          break;
        }
        continue;
      }
      String valuesString = (String) values.iterator().next();
      if(jedis.zrem(queueKey,valuesString) > 0){ //  抢到了（多个线程并发执行，删除成功表示抢到了）
        TaskItem task = JSON.parseObject(valuesString,TaskType);
        this.handleMsg(task.msg);
      }
    }
  }


  //同时，我们要注意一定要对 handle_msg 进行异常捕获，避免因为个别任务处理问题导致循环异常退 出。
  //这里我只是简单打印了一下而已
  private void handleMsg(Object msg) {
    System.out.println(msg);
  }

  public static void main(String[] args) {
    Jedis jedis = new Jedis();
    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);
        }
      }
    };

    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) {
      e.printStackTrace();
    }
  }

}

5.2、存在的问题

上面的算法中同一个任务可能会被多个进程取到之后再使用 zrem 进行争抢，那些没抢到 的进程都是白取了一次任务，这是浪费。

解决：可以考虑使用 lua scripting 来优化一下这个逻辑，将 zrangebyscore 和 zrem 一同挪到服务器端进行原子化操作，这样多个进程之间争抢任务时就不 会出现这种浪费了。

ContactAuthor