Redis高级特性——消息队列

消息队列

消息队列的设计方案在开发过程中应用比较广泛，一般情况都是为了实现程序解耦，生产者发送一个消息，消费者或多个客户端消费者去消费消息，完成任务的异步处理。如果有多个消费者，一方面可以提高处理性能，另一方面可以使得消费者程序得容灾。基于这两方面得有点，消息队列当前应用的非常广泛，一般在启用消息队列时都会采用MQ服务中间件，比如RabbitMq、ZeroMQ等等，这些服务是专业的消息服务，在互联网公司应用的非常多，因此服务质量和分布式方案都是比较成熟的。

依据Redis的特点，他也有很多类型可以实现消息队列方案，在之前的项目中也有应用，并且有些场合是MQ无法替代的。同时Redis因为不是一个标准的MQ服务，因此很多方面无法满足需求，比如ACK，丢包的问题无法保证，有这方面的需求还是使用MQ中间件；即使有这方面的问题使用Redis作为消息中间件的团队仍大量存在，基于这些原因，Redis的作者开发了一个新的MQ服务，同Redis类似，使用方式也基本类似Disque，文档，之前作者表示未来会将该组件加入到Redis标准组件中，这样的话，未来Redis也可以作为MQ的一个首选项。

在之前的项目中分别使用过列表、有序集合作为简单的消息队列，这里对这几种方式进行简单描述。

列表作为消息队列

列表作为消息队列，是最简单的选择，其特性天然适合队列。只要在一端分别使用LPUSH将信息添加到列表，在另一端使用RPOP消费一个消息即可。采用两个cli模拟列表的消息队列行为

# client 1  producer，对入库的资源ID进行上架操作
LPUSH mymq 1
LPUSH mymq 2

# client 2  consumer
# 获取消息，并消费
RPOP mymq
"1"
# 获取到资源1后，进行上架操作，操作完成后丢弃
# 处理完成后，需要再次获取消息
RPOP mymq
"2"
RPOP mymq
(nil)
# mymq中没有新的消息，消费者客户端，需要不断重复RPOP去检查有没有消息

采用列表作为消息队列，也有一个问题，如上述示例中演示的，消费者每次主动去获取消息，有没有消息没有办法判断，只能不断的读取。对于服务端采用JAVA的话，一般这种任务型的都会采用定期执行的方案，那么这种代码很可能如下所示：

public void runTask() {
    while(true) {
        Object id = redis.rpop(myMqKey);
        if (null == id) {
            // 没有消息了，需要停止，停止多久再次执行，这个时间不太好处理，并且没有什么经验值，因为资源的入库没有规律。
        }
        // 处理上架
        do(id);
    }
}

不断的去检查Redis是否有新消息，虽然不麻烦，但是也在耗费资源，并且是无效的投入。Redis的列表中有一个BRPOP方法，前面章节提到过，这里可以采用这个方法，解决不断检查Redis是否有数据，消耗资源的问题。仍然使用上述示例

# 客户端1，consumer
BRPOP mymq 0        # 0 表示永不过期
# mymq队列没有数据，此时一直阻塞,客户端2生产消息后，客户端1理解消费消息
# 1) "mymq"
# 2) "1"
# (30.82s)
# 等待了30.82秒，mymq出现数据并进行了消费,一次读取消息结束

# 客户端2，producer
LPUSH mymq 1
# (integer) 1

这种方式很好的解决了不断检查耗费资源的问题，此时JAVA代码的更改并不大

public void runTask() {
    while(true) {
        List