Redis实现消息队列

概述

消息队列在存取消息时，消息队列必须满足的三个需求：

  1. 消息保序

    虽然消费者是异步处理消息，但是，消费者仍然需要按照生产者发送消息的顺序来处理消息，避免后发送的消息被先处理了。

  2. 重复消息处理

    消费者从消息队列读取消息时，有时会因为网络堵塞而出现消息重传的情况。此时，消费者可能会收到多条重复的消息。对于重复的消息，消费者如果多次处理的话，就可能造成一个业务逻辑被多次执行，如果业务逻辑正好是要修改数据，那就会出现数据被多次修改的问题了。

  3. 消息可靠性保证

    另外，消费者在处理消息的时候，还可能出现因为故障或宕机导致消息没有处理完成的情况。此时，消息队列需要能提供消息可靠性的保证，也就是说，当消费者重启后，可以重新读取消息再次进行处理，否则，就会出现消息漏处理的问题了。

redis实现方案

List实现

  1. 消息保序

    List 本身就是按先进先出的顺序对数据进行存取的，所以，如果使用 List 作为消息队列保存消息的话，就已经能满足消息保序的需求了。（即 LPUSH 和RPOP的结合）

    为了即使没有新消息写入 List，消费者也要不停地调用 RPOP 命令，这就会导致消费者程序的 CPU 一直消耗在执行 RPOP 命令上，带来不必要的性能损失这个问题，Redis 提供了 BRPOP 命令。BRPOP 命令也称为阻塞式读取，客户端在没有读到队列数据时，自动阻塞，直到有新的数据写入队列，再开始读取新数据。

  2. 重复消息处理

    一方面，消息队列要能给每一个消息提供全局唯一的 ID 号；另一方面，消费者程序要把已经处理过的消息的 ID 号记录下来。

    消费者程序就可以对比收到的消息 ID 和记录的已处理过的消息 ID，来判断当前收到的消息有没有经过处理。

    这种处理特性也称为幂等性，幂等性就是指，对于同一条消息，消费者收到一次的处理结果和收到多次的处理结果是一致的。

  3. 消息可靠性保证

    为了留存消息，List 类型提供了 BRPOPLPUSH 命令，这个命令的作用是让消费者程序从一个 List 中读取消息，同时，Redis 会把这个消息再插入到另一个 List（可以叫作备份 List）留存。这样一来，如果消费者程序读了消息但没能正常处理，等它重启后，就可以从备份 List 中重新读取消息并进行处理了。

缺点：

生产者消息发送很快，而消费者处理消息的速度比较慢，这就导致 List 中的消息越积越多，给 Redis 的内存带来很大压力。这个时候，我们希望启动多个消费者程序组成一个消费组，一起分担处理 List 中的消息。但是，List 类型并不支持消费组的实现。

基于 Streams 的实现

Streams 是 Redis 专门为消息队列设计的数据类型，它提供了丰富的消息队列操作命令。

  • XADD：插入消息，保证有序，可以自动生成全局唯一 ID；

    XADD mqstream * repo 5消息队列名称后面的*，表示让 Redis 为插入的数据自动生成一个全局唯一的 ID

  • XREAD：用于读取消息，可以按 ID 读取数据；

    XREAD BLOCK 100 STREAMS mqstream 1599203861727-0

    或者XREAD block 10000 streams mqstream $

    XRAED 时设定 block 配置项，实现类似于 BRPOP 的阻塞读取操作，我们设置了 block 10000 的配置项，10000 的单位是毫秒，表明 XREAD 在读取最新消息时，如果没有消息到来，XREAD 将阻塞 10000 毫秒（即 10 秒），然后再返回。命令最后的“$”符号表示读取最新的消息。

  • XREADGROUP：按消费组形式读取消息；

    XGROUP create mqstream group1 0

    XREADGROUP group group1 consumer1 streams mqstream

  • XPENDING 和 XACK：XPENDING 命令可以用来查询每个消费组内所有消费者已读取但尚未确认的消息，而 XACK 命令用于向消息队列确认消息处理已完成。