前言
Redis发布订阅(pub/sub)是一种消息通信模式,发布者发布消息,订阅者接收消息。
订阅SUBSCRIBE
通过SUBSCRIBE channel指令订阅频道。
127.0.0.1:6379> subscribe ps1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1
redis客户端可以同时订阅多个频道。
127.0.0.1:6379> subscribe ps1 ps2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1
1) "subscribe"
2) "ps2"
3) (integer) 2
发布PUBLISH
通过PUBLISH channel message可以往指定频道发布消息。
// 发布者
127.0.0.1:6379> publish ps1 m1
(integer) 2
127.0.0.1:6379> publish ps2 m2
(integer) 1
// 订阅者1
127.0.0.1:6379> subscribe ps1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1
1) "message"
2) "ps1" <================收到ps1频道的消息
3) "m1" <================消息内容为m1
// 订阅者2
127.0.0.1:6379> subscribe ps1 ps2
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ps1"
3) (integer) 1
1) "subscribe"
2) "ps2"
3) (integer) 2
1) "message"
2) "ps1" <================收到ps1频道的消息
3) "m1" <================消息内容为m1
1) "message"
2) "ps2" <================收到ps2频道的消息
3) "m2" <================消息内容为m2
使用场景(基本没有)
- 分析
查阅到的资料中只介绍了发布、订阅、退订等的是使用,未对具体使用场景做出介绍。网上也未搜到具体的使用场景 -_-||
redis的发布订阅机制很简单,相较于MQ系列消息中间件,缺少了消息持久化、消费确认等机制,个人理解redis的使用场景与UDP报文广播类似,一端只负责无脑发送消息,不去确认消息是否有人接收,自然也就无法确认消息是否丢失。另一边只负责无脑接收消息,接受完消息不去做出反馈(因为对方也不接收反馈),当接收不到消息时也不抛出异常或警告。
综上所述,redis的发布订阅机制是一种不可靠的MQ(UDP广播),在需要发送通知或者传递消息时无法保证消息的送达,亦无法保证消息不丢失。所以需要可靠的消息传递的场景均不适用。 - 结论
redis的发布订阅机制过于简单,只适用于可以容忍消息丢失、未送达的场景(这样的场景真的存在吗)。如果想要可靠的发布订阅实现,还是要选择MQ系列消息中间件。