想要看更加舒服的排版、更加准时的推送
关注公众号“不太灵光的程序员”
每日八点有干货推送
转载自公众号“不太灵光的程序员” 《基于Redis实现消息队列的6种方案之方案简述（中）》
阅读原文
在《基于Redis实现消息队列的6种方案之方案简述（上）》中我们讲到了基于List类型实现的消息队列，今天我们来讲下优先队列的实现。
Redis有序集合的特点
回忆下优先队列的特点，能保证每次取出的元素都是队列中优先级别最高的。这一特点是使用List类型无法满足的，数据只能是先进先出的，那我们来看下Sorted Set类型的特点。
有序集合（Sorted Set）是不允许重复的String类型元素的集合，且每个元素都会关联一个Double类型的分数。
有序集合的成员是唯一的，但分数是可以重复。集合中最大的成员数为 232 - 1 等于4294967295， 也就是每个集合可存储40多亿个成员。
基于Sorted Set以上的特点在实际开发中有许多的应用，比如做游戏的实时战绩排行榜、博客中文章点赞排行榜等各类排行榜和优先队列的实现。
基于Sorted Set的实现方案
- ZADD在集合中添加一个带有分数的元素。
- ZRANGE返回有序集中，指定区间内的成员，其中成员的位置按分数值递增(从小到大)来排序；我们使用0，0区间来获取处于顶部的元素。
ZREVRANGE与ZRANGE不同的是成员的位置按分数值递减(从大到小)来排列。 - ZREM用来移除有序集中的一个元素，不存在的成员将被忽略。当消费0，0区间元素成功后，移除该元素。
优点：
- Sorted Set类型是基于使用了hash和skiplist两种设计实现；添加和删除都需要修改skiplist，所以复杂度为O(log(n))；查找元素的话可以直接使用hash，其复杂度为O(1)
- 可以实现按权值取元素
- Redis支持消息持久化，在服务端数据是安全的
缺点：
- 消费确认机制需要单独实现，我觉得还是需要一个正在消费队列来实现，这样还可以使用多个客户端来同时处理队列消息了
- 不支持阻塞式获取
- 不允许重复消息
- 不支持分组消费
- Sorted Set不仅可以实现优先队列，还可以将权值当做有序队列的自定义序号，例如使用时间戳就可以实现一个有序队列了，但是如果是做有序队列当然没有List类型来的方便了。
基于PUB/SUB，订阅/发布模式的实现方案
- SUBSCRIBE用于订阅一个给定模式信道
- PUBLISH用于将消息发送到指定的信道
- UNSUBSCRIBE用于取消订阅指定信道
生产者和消费者通过相同的一个信道进行交互。信道其实也就是队列。通常会有多个消费者。多个消费者订阅同一个信道，当生产者向信道发布消息时，该信道会立即将消息逐一发布给每个消费者。所以该信道对于消费者是发散的信道，每个消费者都可以得到相同的消息。典型的一对多的关系。
优点：
- 典型的广播模式，一个消息可以发布到多个消费者
- 多信道订阅，消费者可以同时订阅多个信道，从而接收多类消息
- 消息即时发送，消息不用等待消费者读取，消费者会自动接收到信道发布的消息
缺点：
- 消息一旦发布，不能接收。换句话就是发布时若客户端不在线，则消息丢失，不能寻回
- 不能保证每个消费者接收的时间是一致的
- 若消费者客户端出现消息积压，到一定程度，会被强制断开，导致消息意外丢失。通常发生在消息的生产远大于消费速度时
可见，Pub/Sub 模式不适合做消息存储，消息积压类的业务，而是擅长处理广播，即时通讯，即时反馈的业务。
懂了啵！！！
会在《基于Redis实现消息队列的6种方案之方案简述（下）》主要介绍使用Stream类型实现的消息队列的方案。
感觉用就点个关注、点个看一看噢
