消息队列，Message Queue，常用于解决并发系统中的资源一致性问题，提升峰值的处理能力，同时保证消息的顺序性、可恢复性、必送达性，对应用进行解耦，或者实现异步通讯等。市面上的 MQ应用有很多（例如：Kafka，RabbitMQ，Disque），同时也可以基于 Redis 来实现，比较典型的方案有：
基于List的 LPUSH+BRPOP 的实现
PUB/SUB，订阅/发布模式
基于Sorted-Set的实现
基于Stream类型的实现
讨论之前，先推荐使用 Redis5.0中的Stream方案，一个几乎完美的Redis消息队列方案,http://www.hellokang.net/redis/stream.html
在消息队列使用中，有生产者producter和消费者consumer。生产者负责生成消息，消费者负责使用处理消息。
生产，指的是将消息放入消息队列。 消费，指的是读取并处理消息。通常一个消息再被消费后，就应该从消息队列中删除。
image.png
基于List的 LPUSH+BRPOP 的实现
redis的列表类型天生支持用作消息队列。(类似于MQ的队列模型--任何时候都可以消费，一条消息只能消费一次)
典型的命令为：
LPUSH，将消息队列
BRPOP，从队列中取出消息，阻塞模式
就是一个典型的基于FIFL队列的解决方案。其中LPUSH是生产者做的事，而BRPOP是消费者做的事。
该模式有很多优点：
- 实现简单
- Reids支持持久化消息，意味着消息不会丢失，可以重复查看（注意不是消费，* 只看不用，LRANGE类的指令）。
- 可以保证顺序，保证使用LPUSH命令，可以保证消息的顺序性
- 使用RPUSH，可以将消息放在队列的开头，达到优先消息的目的，可以实现简易的消息优先队列。
同时也有些劣势：
- 做消费确认ACK比较麻烦，就是不能保证消费者在读取之后，未处理后的宕机问题。导致消息意外丢失。通常需要自己维护一个Pending列表，保证消息的处理确认。
- 不能做广播模式，例如典型的Pub/Discribe模式。
- 不能重复消费，一旦消费就会被删除
- 不支持分组消费，需要自己在业务逻辑层解决
3 PUB/SUB，订阅/发布模式
SUBSCRIBE，用于订阅信道
PUBLISH，向信道发送消息
UNSUBSCRIBE，取消订阅
生产者和消费者通过相同的一个信道（Channel）进行交互。信道其实也就是队列。通常会有多个消费者。多个消费者订阅同一个信道，当生产者向信道发布消息时，该信道会立即将消息逐一发布给每个消费者。可见，该信道对于消费者是发散的信道，每个消费者都可以得到相同的消息。典型的对多的关系。
典型的优点是：
- 典型的广播模式，一个消息可以发布到多个消费者
- 多信道订阅，消费者可以同时订阅多个信道，从而接收多类消息
- 消息即时发送，消息不用等待消费者读取，消费者会自动接收到信道发布的消息
也有些缺点：
- 消息一旦发布，不能接收。换句话就是发布时若客户端不在线，则消息丢失，不能寻回
- 不能保证每个消费者接收的时间是一致的
- 若消费者客户端出现消息积压，到一定程度，会被强制断开，导致消息意外丢失。通常发生在消息的生产远大于消费速度时
可见，Pub/Sub 模式不适合做消息存储，消息积压类的业务，而是擅长处理广播，即时通讯，即时反馈的业务。
