- Sorted Set类型是基于使用了hash和skiplist两种设计实现;添加和删除都需要修改skiplist,所以复杂度为O(log(n));查找元素的话可以直接使用hash,其复杂度为O(1)
- 可以实现按权值取元素
-
Redis支持消息持久化,在服务端数据是安全的
- 消费确认机制需要单独实现,我觉得还是需要一个正在消费队列来实现,这样还可以使用多个客户端来同时处理队列消息了
- 不支持阻塞式获取
- 不允许重复消息
-
不支持分组消费
Sorted Set不仅可以实现优先队列,还可以将权值当做有序队列的自定义序号,例如使用时间戳就可以实现一个有序队列了,但是如果是做有序队列当然没有List类型来的方便了。
基于PUB/SUB,订阅/发布模式的实现方案
SUBSCRIBE用于订阅一个给定模式信道
PUBLISH用于将消息发送到指定的信道
UNSUBSCRIBE用于取消订阅指定信道
生产者和消费者通过相同的一个信道进行交互。信道其实也就是队列。通常会有多个消费者。多个消费者订阅同一个信道,当生产者向信道发布消息时,该信道会立即将消息逐一发布给每个消费者。所以该信道对于消费者是发散的信道,每个消费者都可以得到相同的消息。典型的一对多的关系。
- 典型的广播模式,一个消息可以发布到多个消费者
- 多信道订阅,消费者可以同时订阅多个信道,从而接收多类消息
- 消息即时发送,消息不用等待消费者读取,消费者会自动接收到信道发布的消息
- 消息一旦发布,不能接收。换句话就是发布时若客户端不在线,则消息丢失,不能寻回
- 不能保证每个消费者接收的时间是一致的
- 若消费者客户端出现消息积压,到一定程度,会被强制断开,导致消息意外丢失。通常发生在消息的生产远大于消费速度时
可见,Pub/Sub 模式不适合做消息存储,消息积压类的业务,而是擅长处理广播,即时通讯,即时反馈的业务。
转载请注明:XAMPP中文组官网 » 基于Redis实现消息队列的6种方案之方案简述(中)