十年河东,十年河西,莫欺少年穷
学无止境,精益求精
Redis消息队列的关键字
Pub/Sub(发布/订阅)
PSUBSCRIBE
订阅一个或多个符合给定模式的频道。
每个模式以 * 作为匹配符,比如 it* 匹配所有以 it 开头的频道( it.news 、 it.blog 、 it.tweets 等等), news.* 匹配所有以 news. 开头的频道( news.it 、 news.global.today 等等),诸如此类。
PUBLISH
将信息 message 发送到指定的频道 channel 。意思就是指:发布消息,订阅者可以接收
PUBSUB
是一个查看订阅与发布系统状态的内省命令, 它由数个不同格式的子命令组成, 以下将分别对这些子命令进行介绍。
PUNSUBSCRIBE
指示客户端退订所有给定模式。
如果没有模式被指定,也即是,一个无参数的 PUNSUBSCRIBE 调用被执行,那么客户端使用 PSUBSCRIBE 命令订阅的所有模式都会被退订。在这种情况下,命令会返回一个信息,告知客户端所有被退订的模式。
SUBSCRIBE
订阅给定的一个或多个频道的信息。
UNSUBSCRIBE
指示客户端退订给定的频道。
如果没有频道被指定,也即是,一个无参数的 UNSUBSCRIBE 调用被执行,那么客户端使用 SUBSCRIBE 命令订阅的所有频道都会被退订。在这种情况下,命令会返回一个信息,告知客户端所有被退订的频道。
命令示例
关注:
SUBSCRIBE k1 k2 k3 k4 k5 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "k1" 3) (integer) 1 1) "subscribe" 2) "k2" 3) (integer) 2 1) "subscribe" 2) "k3" 3) (integer) 3 1) "subscribe" 2) "k4" 3) (integer) 4 1) "subscribe" 2) "k5" 3) (integer) 5
发布:
C:\Users\chenwolong>redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> PUBLISH k1 "hello My Name is k1" (integer) 1 127.0.0.1:6379> PUBLISH k2 "hello My Name is k2" (integer) 1 127.0.0.1:6379> PUBLISH k3 "hello My Name is k3" (integer) 1
发布消息后,订阅者界面就可以看到发布的消息
关于更多的指令演示,在此不做了,有兴趣的可以参考:Redis中文网
最后贴出一个Redis实现消息队列的案例
1 概述
2 基于List的 LPUSH+BRPOP 的实现
3 PUB/SUB,订阅/发布模式
4 基于SortedSet有序集合的实现
5 基于 Stream 类型的实现
6 其他实现
消息队列,Message Queue,常用于解决并发系统中的资源一致性问题,提升峰值的处理能力,同时保证消息的顺序性、可恢复性、必送达性,对应用进行解耦,或者实现异步通讯等。市面上的 MQ应用有很多(例如:Kafka,RabbitMQ,Disque),同时也可以基于 Redis 来实现,比较典型的方案有:
在消息队列使用中,有生产者producter和消费者consumer。生产者负责生成消息,消费者负责使用处理消息。
生产,指的是将消息放入消息队列。 消费,指的是读取并处理消息。通常一个消息再被消费后,就应该从消息队列中删除。
接下来分别讨论具体实现方案。
典型的命令为:
LPUSH,将消息队列
BRPOP,从队列中取出消息,阻塞模式
就是一个典型的基于FIFL队列的解决方案。其中LPUSH是生产者做的事,而BRPOP是消费者做的事。
该模式有很多优点:
同时也有些劣势:
注意,没有好不好的技术,只有适合不适合。
SUBSCRIBE,用于订阅信道
PUBLISH,向信道发送消息
UNSUBSCRIBE,取消订阅
生产者和消费者通过相同的一个信道(Channel)进行交互。信道其实也就是队列。通常会有多个消费者。多个消费者订阅同一个信道,当生产者向信道发布消息时,该信道会立即将消息逐一发布给每个消费者。可见,该信道对于消费者是发散的信道,每个消费者都可以得到相同的消息。典型的对多的关系。
典型的优点是:
也有些缺点:
可见,Pub/Sub 模式不适合做消息存储,消息积压类的业务,而是擅长处理广播,即时通讯,即时反馈的业务。
ZADD KEY score member,压入集合
ZRANGEBYSCORE,依据score获取成员
有序集合的方案是在自己确定消息顺ID时比较常用,使用集合成员的Score来作为消息ID,保证顺序,还可以保证消息ID的单调递增。通常可以使用时间戳+序号的方案。确保了消息ID的单调递增,利用SortedSet的依据Score排序的特征,就可以制作一个有序的消息队列了。
和上面的方案相比,优点就是可以自定义消息ID,在消息ID有意义时,比较重要。缺点也明显,不允许重复消息(以为是集合),同时消息ID确定有错误会导致消息的顺序出错。
所以,若不是需要自定义消息ID,这个方案好像有点鸡肋...
这个Stream类型redis就是为了实现消息队列的。支持自动生成消息ID,分组消费,ACK,消息转移,队列监控等核心消息队列功能,请参考:基于Redis的Stream类型的完美消息队列解决方案,http://www.hellokang.net/redis/stream.html,来获取完整方案。
很多成熟的MQ产品:
@天才卧龙的博客