Redis系列14：使用List实现消息队列

1 介绍

在分布式系统中，很重要的一个能力就是消息中间件。我们通过消息队列实现 功能解耦、消息有序性、消息路由、异步处理、流量削峰 等能力。
目前主流的Mq主要有 RabbitMQ 、RocketMQ、kafka，可以参考这篇《​​​MQ系列2：消息中间件技术选型​​​》。
那除了这些主流MQ之外，咱们的这一节要说的Redis也具备实现消息队列的能力。
我们来看看消息队列主要要实现哪些能力，原理是什么，以及如何在 Redission 中应用。

2 关于消息队列

2.1 什么是消息队列

消息中间件是指在分布式系统中完成消息的发送和接收的基础软件。
消息中间件也可以称消息队列（Message Queue / MQ），用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。
简而言之，互联网场景中经常使用消息中间件进行消息路由、订阅发布、异步处理等操作，来缓解系统的压力。

• Broker：消息服务器，作为Server提供消息核心服务，一般会包含多个Q。
• Producer：消息生产者，业务的发起方，负责生产消息传输给broker，
• Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理

2.2 它解决了我们哪些问题

1、解耦：

这种场景很常见，比如A是订单系统，B是库存系统，可以通过消息队列把削减库存的工作交予B系统去处理。如果A系统同时想让B、C、D...多个系统处理问题的时候，这种优势就更加明显了。

2、有序性：

对数据的顺序性和一致性有强需求的业务，比如同一张银行卡同时被多个入口使用，需要保证入账出账的顺序性，避免出现数据不一致。

3、消息路由：

通过消息队列将不同染色的请求发送到不同的服务去操作。这样达成了流量按照业务拆分的目的。

4、异步处理： 处理一项任务的时候，有3个步骤A、B、C，需要先完成A操作, 然后做B、C 操作。任务执行成功与否强依赖A的结果，但不依赖B、C 的结果。
如果我们使用串行的执行方式，那处理任务的周期就会变长，系统的整体吞吐能力也会降低（在同一个系统中做异步其实也是比较大的开销），所以使用消息队列是比较好的办法。

登录操作就是典型的场景：A：执行登录并得到结果、B：记录登录日志、C：将用户信息和Token写入缓存。执行完A就可以从登录页跳到首页了，B、C让服务慢慢去消化，不阻塞当前操作。

5、削峰：

详细可参考笔者这篇《​​MQ系列1：消息中间件执行原理​​》。

2.3 消息队列满足的业务特性

2.3.1 消息有序性

正如上面提到的有序性一样，他能够保证消息按照生产的顺序进行处理和消费，避免消息被无序处理的情况发生。

2.3.2 消息去重

同样的，生产和消费的消息需要保证幂等性原理。避免出现重复执行的情况，
而消息队列的去重机制，也需要确保避免消息被重复消费的问题。

2.3.3 消息的可靠性传输

消息队列的数据可以实现重试、持久化存储、死信队列记录等，以避免消息无法成功传递所产生的不一致现象。
当消息服务器或者消费者恢复健康的时候，可以继续读取消息进行处理，防止消息遗漏。

3 使用Redis的List实现消息队列

稍微学过数据结构都知道。我们经常说Queue（队列），他的存储和使用规则是【先进先出】，栈的存储和使用规则是【先进后出】。
所以List本质上是一个线性的有序结构，也就是Queue的存储关系，它能够保证消费的有序性，按照顺序进行处理。

3.1 入列操作 LPUSH

即进行消息生产，入列操作语法：

 LPUSH key element[element...] 

如果key存在，Producer 通过 LPUSH 将消息插入该队列的头部；如果 key 不存在，则是先创建一个空队列，然后在进行数据插入。
下面举个例子，往队列中插入几个消息，然后得到的返回值是插入消息的个数。

> LPUSH msg_queue msg1 msg2 msg3
(integer) 3

这边往 key 为 msg_queue 的队列中插入了三个消息 msg1、msg2、msg3。

3.2 出列操作 RPOP

即进行消息消费，消费的顺序是先进先出（先生产先消费），出列使用的语法如下：

> RPOP msg_queue
"msg1"
> RPOP msg_queue
"msg2"
> RPOP msg_queue
"msg3"
> RPOP msg_queue
(nil)

都消费完成之后，就是nil了。

3.3 消费及时性问题

不同于常规的MQ，具备订阅模式，消费者可以感知到有新的消息生产出来了，再进行消费。
List的问题在于，生产者向队列插入数据的时候，List 并不会主动通知消费者，所以消费者做不到及时消费。
为了保证消费的及时，可能需要做一个心跳包（1秒执行一次），不断地执行 RPOP 指令，当探测到有新消息就会取出消息进行消费，没有消息的时候就返回nil。
但是这种也存在明显的短板，就是不断的调用 RPOP 指令，占用 I/O 资源和CPU资源。

比较好的解决办法就是在队列为空队列的时候，暂停读取，等有消息入列的时候，恢复取数和消费的工作，这样也避免了无效的资源浪费。
Redis 提供了 BLPOP、BRPOP ，无数据的时候自动阻塞读取的命令，有新消息进入的时候，恢复消息取数，如下：

# BRPOP  key  timeout 
BRPOP  msg_queue  0

命令最后一个参数 timeout 是超时时间，单位是秒，如果 timeout 大于0，则到达指定的秒数即使没有弹出成功也会返回，如果 timeout 的值为0，则会一直阻塞等待其他连接向列表中插入元素， timeout 参数不允许为负数。

3.4 消息的重复消费问题

目前 List 没有纯幂等的鉴别能力，但是可以通过以下两种方法来实现：

• List为每一条消息生成一个 Glocal ID，重复的Glocal ID 不进行重复消费。
• Producer在生产消息的时候在消息中创建一个Glocal ID，当消费的时候把Glocal ID Record一下，后续的消费先判断再消费，避免重复消费同一个消息。
  这样就保证了对于同一条消息，消费者始终只处理一次，结果始终保持一致。

3.5 消息的可靠性传输问题

可靠性传输我们在MQ篇章用了一整节来介绍持久化存储、消息ACK 、二次记录保障。这边我们也来看看Redis List中的可靠性传输的保障。
Redis中缺少了一个消息确认（ACK）的机制，如果消费数据的时候运行崩溃了，没有确认机制，很可能这条消息就被错过了，无法保证数据的一致性。
解决方案：Redis 提供了 ​​​RPOPLPUSH​​​ 指令，当List读取消息的时候，会同步的把该消息复制到另外一个List以作备份。
整个操作过程是具备原子性的，避免读取消息了，但是同步备份不成功。

如果出现处理消息出现故障的情况，在故障回复之后，可以从备份的List中复制消息继续消费。操作如下：

# 生产消息 msg1 msg2
> LPUSH list_queue msg1 msg2  
(integer) 2
# 消费消息并同步到备份
> RPOPLPUSH list_queue list_queue_bak
"msg1"
# 当发生故障的时候去消费备份的数据，可以消费到
> RPOP list_queue_bak
"msg1"

如果消费成功则把 list_queue_bak 消息删除即可，如果发生故障，则可以继续从 list_queue_bak 再次读取消息处理。

4 使用 Redission 实现队列能力

这边以Java SpringBoot为例子进行说明，可以参考官方文档。

4.1 添加maven依赖 和 配置基本连接

# maven信息
<dependency>
  <groupId>org.redisson</groupId>
  <artifactId>redisson-spring-boot-starter</artifactId>
  <version>3.16.8</version>
</dependency>

# 基本配置
spring:
  application:
    name: redission_test
  redis:
    host: x.x.x.x
    port: 6379
    ssl: false
    password: xxxx.xxxx

4.2 Java程序实现

@Slf4j
@Service
public class RedisQueueService {

    @Autowired
    private RedissonClient redissonClient;

    private static final String REDIS_QUEUE = "listQueue";

    /**
     * 消息生产
     *
     * @param msg
     */
    public void msgProduce(String msg) {
        RBlockingDeque<String> blockDeque = redissonClient.getBlockingDeque(REDIS_QUEUE);
        try {
            blockDeque.putFirst(msg); // 消息写入队列头部
        } catch (InterruptedException e) {
            log.error(e.printStackTrace());
        }
    }

    /**
     * 消息消费：阻塞
     */
    public void msgConsume() {
        RBlockingDeque<String> blockDeque = redissonClient.getBlockingDeque(REDIS_QUEUE);
		Boolen isCheck = true;
        while (isCheck) {
            try {
                String msg = blockDeque.takeLast();  // 从队列中取出消息
            } catch (InterruptedException e) {
                log.error(e.printStackTrace());
            }
        }
    }

5 总结

• Redis中使用List 数据结构实现消息队列，满足FIFO的处理机制，使用 RPOP 进行消息读取。
• 使用 BRPOP 指令处理消费及时性问题
• 使用 BRPOPLPUSH 命令进行消息数据备份，解决消息可靠性传输问题。
• 相对于专业的MQ，如kafka和RocketMQ，处理能力会差很多。所以在在消息量不大的场景中使用，可以作为一个比较不错的消息队列解决方案。但是过于复杂的场景容易造成消息堆积。

文章转载自公众号： 架构与思维