Redis实现消息队列详解

为什么要消息队列

维基百科对消息队列的解释：

简单的概括下上面的定义：消息队列就是一个使用队列来通信的组件。 上面的定义没有错，但就现在而言我们日常所说的消息队列常常指代的是消息中间件，它的存在不仅仅只是为了通信这个问题。消息队列常常被用来解耦服务之间的关系、控制资源合理合时的使用以及缓冲流量洪峰等等。简而言之，我们一般用消息队列来实现，异步处理、服务解耦、流量控制。

1. 1、解耦：生产者只负责生产消息，并把消息放在队列中，而不用关心谁去使用它。
2. 2、异步：生产者把消息放在队列中后即可返回，而不用一个个的通知消费者去执行，消费者是异步的获取消息的。
3. 3、限流：生产者一次性产生大量的数据时，暂存在消息队列，不会给消费者造成压力，消费者可以根据自身的能力，去消息队列中取数据。

 消息队列对消息的需求

在使用消息队列时，消费者可以异步读取生产者消息，然后再进行处理。这样一来，即使生产者发送消息的速度远远超过了消费者处理消息的速度，生产者已经发送的消息也可以缓存在消息队列中，避免阻塞生产者，这是消息队列作为分布式组件通信的一大优势。不过，消息队列在存取消息时，必须要满足三个需求，分别是消息保序、合理处理重复的消息和保证消息可靠性。

Redis基于List实现消息队列

我们主要看redis怎么实现上述三个要求，消息保序、合理处理重复的消息和保证消息可靠性。

消息保序

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

具体来说，生产者可以使用 LPUSH 命令把要发送的消息依次写入 List，而消费者则可以使用 RPOP 命令，从 List 的另一端按照消息的写入顺序，依次读取消息并进行处理。 

不过，在消费者读取数据时，有一个潜在的性能风险点。在生产者往 List 中写入数据时，List 并不会主动地通知消费者有新消息写入，如果消费者想要及时处理消息，就需要在程序中不停地调用 RPOP 命令（比如使用一个 while(1) 循环）。如果有新消息写入，RPOP 命令就会返回结果，否则，RPOP 命令返回空值，再继续循环。所以，即使没有新消息写入 List，消费者也要不停地调用 RPOP 命令，这就会导致消费者程序的 CPU 一直消耗在执行 RPOP 命令上，带来不必要的性能损失。为了解决这个问题，Redis 提供了 BRPOP 命令。BRPOP 命令也称为阻塞式读取，客户端在没有读到队列数据时，自动阻塞，直到有新的数据写入队列，再开始读取新数据。和消费者程序自己不停地调用 RPOP 命令相比，这种方式能节省 CPU 开销。 

合理处理重复的消息

接下来，我们还需要考虑解决重复消息处理的问题，这里其实有一个要求：消费者程序本身能对重复消息进行判断（其实是无法避免消息重复的，我们要做的是用幂等性合理解决这个问题）

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

当收到一条消息后，消费者程序就可以对比收到的消息 ID 和记录的已处理过的消息 ID，来判断当前收到的消息有没有经过处理。如果已经处理过，那么，消费者程序就不再进行处理了。这种处理特性也称为幂等性，幂等性就是指，对于同一条消息，消费者收到一次的处理结果和收到多次的处理结果是一致的。不过，List 本身是不会为每个消息生成 ID 号的，所以，消息的全局唯一 ID 号就需要生产者程序在发送消息前自行生成。生成之后，我们在用 LPUSH 命令把消息插入 List 时，需要在消息中包含这个全局唯一 ID。 

例如，我们执行以下命令，就把一条全局 ID 为 101、库存量为 10 的消息插入了消息队列： 

LPUSH mq "101:stock:10"
(integer) 1

保证消息可靠性

最后，我们再来看下，List 类型是如何保证消息可靠性的。

当消费者程序从 List 中读取一条消息后，List 就不会再留存这条消息了。所以，如果消费者程序在处理消息的过程出现了故障或宕机，就会导致消息没有处理完成，那么，消费者程序再次启动后，就没法再次从 List 中读取消息了。

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

到这里，你可以看到，基于 List 类型，我们可以满足分布式组件对消息队列的三大需求。