Pre
最终方案-----> Redis进阶-Stream多播的可持久化的消息队列
我们知道redis 5.x版本，作者提供了stream这种基于radix tree 基数树的数据结构，解决使用Redis实现MQ“百花齐放”的乱象。
这里我们来聊一聊使用Redis实现MQ的主要集中实现以及利弊
方案1 Pub/Sub
优点
- Pub/Sub的消息是 Fan Out 多播模式 ，每个订阅了Channel的消费者都能从Channel中获取到同等的信息。
缺点
消息没有持久化的机制。当消费者的连接断掉 后，再次重连，那么Channel中的消息对于该消费者而言将无法消费。
消费消息的速度和消费者的数量成反比. 当消费者的数量达到一定规模时，服务器的性能将线性下降，因此每个消费者获取到消息的延迟也线性增长
当生产者产生消息的速度远大于消费者的消费能力的时候，消费者会被强制断开连接，因此会造成消息的丢失
client-output-buffer-limit pubsub 32mb 8mb 60
当消费者的buffer积压超过32MB，或者在60s内消费者的buffer一直保持在8MB以上，那么该消费者就会被redis服务器给强制断开连接，可以修改这个配置，但无法预料修改后的会带来什么样的结果。
小结
Redis的Pub/Sub模型对于无法容忍数据丢失，消息可能积压的场景不太适合。
方案2 List
优点
- 消息可以持久化。当consumer断开连接或者crash的时候，再次去消费，历史消息会得以保留，可以从最后一次消费的位置进行消费
- 消息可以积压。当生产者产生消息的速度大于消费者的速度的时候，除了会耗费一些内存外，无其他影响
缺点
一个消息最多只能被消费一次 。 一条消息被一个消费者消费之后，这条消息就被删除了，其他的消费者再无可能重复消费掉这条消息。也就是说List方案的消息不是发散的，同一条消息只能被一个消费者消费。
小结
List方案适合应用在消息最多被消费一次的场景 .
如果想要消息被重复消费，需要通过其他手段来解决，比如
- 一个消费者消费完消息之后，把它加入到另外一个队列的对尾，其他消费者从这个新建的队列中消费消息，这样就会造成多个消费者消费的顺序依赖，不能并行执行
- 在消费者消费之前，对消息进行处理，把该消息写入到若干个队列中，这样能支持多个消费者同时消费，但是数据却被拷贝了多次
方案3 ZSet
优点
在5.0的stream出现之前，zset是这几种之中最复杂的实现方案，但是它能有效地解决Pub/Sub和List方案的不足。
- ZSet支持消息持久化
- ZSet支持消息重复消费。 ZSet使用的获取消息操作ZRANGEBYSCORE（返回有序集合中指定分数区间的成员列表） ，该操作不会删除消息
缺点
使用zset要考虑一下几点
- 消息的顺序。 score至关重要，这关系到消息的先后顺序，比如使用timestamp+seq作为score能够保证消息的顺序。
- 重复消息的添加。zset重复的消息是不能够添加到集合中的， 当消息一样的时候，如何存放，需要考虑
小结
基于上述原因 ZSet方案的实现相比list和pub/sub 相对复杂。
方案4 stream
千呼万唤始出来， stream解决你的绝大部分苦恼 ~
