实现方式
- 通过数据结构list来实现
- 通过pub/sub实现
通过List实现
实现机制
一个客户端通过LPUSH命令将消息放入队列中,
而另一个客户端通过RPOP或者BRPOP命令取出队列中等待时间最长的消息，
即 FIFO.
优点
- 能够实现持久化：可以通过多个client来提高消费速度
- 支持集群：可以通过多个client来提高消费速度
- 接口使用简单：生产者，消费者模式，生产者lpush消息，消费者brpop消息，并设定超时时间，可以减少redis的压力
缺点
- 生产者写入太快，消费者消费太慢，导致Redis的内存问题，处理机制需要自己实现
- 生产者或者消费者崩溃后的处理机制，需要自己实现
- Redis上消息只会被一个消费者消费，不会有多个消费者消费同一个消息，简单一对一；
- 消息没有状态，消息取出后依赖于client的记录或者重新push到队列中，消息被重新消费，需要实现一致性补偿或异步幂等；
通过pub/sub实现
实现机制
即发布-订阅模式：
订阅，取消订阅和发布实现了发布/订阅消息范式；
发布者通过PUBLISH发布的消息分到不同的channel，不关注发给谁；
订阅者通过SUBSCRIBE订阅对一个或多个channel，不关注是谁发布；
优点
- 一个发布者可以对应多个生产者；
- 支持集群；
- 可以模糊匹配订阅，取消订阅，发布；
缺点
- 非持久化：消息发布者和订阅者必须同时在线，否则一旦消息订阅者由于各种异常情况而被迫断开连接，在其重新连接后，其离线期间的消息是无法被重新通知的（即发即弃）；
- 数据库的可靠性不能保证：在redis宕机之后，redis没有专门定制消息的备份与恢复；
- 扩展不灵活：当大量的消息到达redis服务时，如果消息订阅者来不及完成处理，会导致消息堆积，如果数据最终要落地数据库，那么数据不同步的状态越久，风险越大；
- 不支持分组，即 做不到同一个组里只有一个订阅者会收到消息，做简单的负载均衡；
总结
- redis 轻量级，低延迟，高并发，可靠性低
- 轻量级：相对于 开源的mq来说；
- 低延迟：实时性高，redis作为高效的缓存服务器，所有数据都存在在服务器中，所以它具有更高的实时性
- 高并发：高效的缓存服务器
- 可靠性低：没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中；
