Redis实现消息队列的方式

实现方式

1. 通过数据结构list来实现
2. 通过pub/sub实现

通过List实现

实现机制

一个客户端通过LPUSH命令将消息放入队列中,
而另一个客户端通过RPOP或者BRPOP命令取出队列中等待时间最长的消息，
即 FIFO.

优点

1. 能够实现持久化：可以通过多个client来提高消费速度
2. 支持集群：可以通过多个client来提高消费速度
3. 接口使用简单：生产者，消费者模式，生产者lpush消息，消费者brpop消息，并设定超时时间，可以减少redis的压力

缺点

1. 生产者写入太快，消费者消费太慢，导致Redis的内存问题，处理机制需要自己实现
2. 生产者或者消费者崩溃后的处理机制，需要自己实现
3. Redis上消息只会被一个消费者消费，不会有多个消费者消费同一个消息，简单一对一；
4. 消息没有状态，消息取出后依赖于client的记录或者重新push到队列中，消息被重新消费，需要实现一致性补偿或异步幂等；

通过pub/sub实现

实现机制

即发布-订阅模式：
订阅，取消订阅和发布实现了发布/订阅消息范式；
发布者通过PUBLISH发布的消息分到不同的channel，不关注发给谁；
订阅者通过SUBSCRIBE订阅对一个或多个channel，不关注是谁发布；

优点

1. 一个发布者可以对应多个生产者；
2. 支持集群；
3. 可以模糊匹配订阅，取消订阅，发布；

缺点

1. 非持久化：消息发布者和订阅者必须同时在线，否则一旦消息订阅者由于各种异常情况而被迫断开连接，在其重新连接后，其离线期间的消息是无法被重新通知的（即发即弃）；
2. 数据库的可靠性不能保证：在redis宕机之后，redis没有专门定制消息的备份与恢复；
3. 扩展不灵活：当大量的消息到达redis服务时，如果消息订阅者来不及完成处理，会导致消息堆积，如果数据最终要落地数据库，那么数据不同步的状态越久，风险越大；
4. 不支持分组，即 做不到同一个组里只有一个订阅者会收到消息，做简单的负载均衡；

总结

1. redis 轻量级，低延迟，高并发，可靠性低
2. 轻量级：相对于 开源的mq来说；
3. 低延迟：实时性高，redis作为高效的缓存服务器，所有数据都存在在服务器中，所以它具有更高的实时性
4. 高并发：高效的缓存服务器
5. 可靠性低：没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中；