redis - 基于redis实现的消息队列优缺点分析

目录：

1. 基于List的LPUSH+BRPOP的实现

2. PUB/SUB，订阅/发布模式

3. 基于Sorted-Set的实现

4. 基于Stream类型的实现

优缺点分析：

一、基于List的LPUSH+BRPOP的实现：

典型的命令：

• LPUSH：将消息加入队列头部；
• BRPOP：从队列末尾取出消息，阻塞模式（RPOP的阻塞版本）；

优点：

1. > 实现简单；
2. > redis支持持久化消息，意味着消息不会丢失，可以重复查看（注意不是消费，只看不用，LRANGE类的指定）；
3. > 可以保证顺序，使用LPUSH命令，可以保证信息的顺序性；
4. > 使用RPUSH，可以将消息放在队列的开头，达到优先消息的目的，可以实现简易的消息优先队列；

缺点：

1. > 做消费确认ACK比较麻烦，就是不能保证消费者在读取之后，未处理后的宕机问题。导致消息意外丢失。通常需要自己维护一个pending列表，保证消息的处理确认；
2. > 不能做广播模式，例如典型的Pub/Discribe模式；
3. > 不能重复消费，一旦消费就会被删除；
4. > 不支持分组消费，需要自己在业务逻辑层解决；

二、 PUB/SUB，订阅/发布模式

典型的命令：

• SUBSCRIBE：用于订阅信道
• PUBLISH：向信道发送消息
• UNSUBSCRIBE：取消订阅

优点：

1. > 典型的广播模式，一个消息可以发布到多个消费者；
2. > 多信道订阅，消费者可以同时订阅多个信道，从而接收多类消息；
3. > 消息即时发送，消息不用等待消费者读取，消费者会自动接收到信道发布的消息；

 

缺点：

1. > 消息一旦发布，不能接收。换句话就是发布时若客户端不在线，则消息丢失，不能寻回；
2. > 不能保证每个消费者接收的时间是一致的；
3. > 若消费者客户端出现消息积压，到一定程度，会被强制断开，导致消息意外消失。通常发生在消息的生产远大于消费速度时；

三、基于Sorted-Set的实现

典型的命令：

• ZADD KEY score member，压入集合
• ZRANGEBYSCORE，依据score获取成员

优点：

1. 可以自定义消息ID，在消息ID有意义时，比较重要；

 

缺点：

1. 不允许重复消息（以为是集合），同时消息ID确定有错误会导致消息的顺序错误；

 

四、基于Stream类型的实现

典型的命令：

• XADD：最加新消息；
• XREAD：从消息队列中获取信息；

优点：

1. stream类型redis就是为了实现消息队列的。支持自动生成消息ID、分组消费、ACK、消息转移、队列监控等核心消息队列功能。