Redis 发布订阅是一种消息通信模式，发送者（pub）发送消息，订阅者（sub）接收消息。微信、微博、关注系统。
Redis 客户端可以订阅任意数量的频道。
使用场景
- 实时消息系统
- 实时聊天
- 订阅、关注系统
转自：https://my.oschina.net/u/4299068/blog/3381033
异步消息通知
比如渠道在调支付平台的时候，我们可以用回调的方式给支付平台一个我们的回调接口来通知我们支付状态，还可以利用 Redis 的发布订阅来实现。比如我们发起支付的同时订阅频道 pay_notice_ + wk (假如我们的渠道标识是 wk，不能让其他渠道也订阅这个频道)，当支付平台处理完成后，支付平台往该频道发布消息，告诉频道的订阅者该订单的支付信息及状态。收到消息后，根据消息内容更新订单信息及后续操作。
当很多人都调用支付平台时，支付时都去订阅同一个频道会有问题。比如用户 A 支付完订阅频道 pay_notice_wk，在支付平台未处理完时，用户 B 支付完也订阅了 pay_notice_wk，当 A 收到通知后，接着 B 的支付通知也发布了，这时渠道收不到第二次消息发布。因为同一个频道收到消息后，订阅自动取消，也就是订阅是一次性的。
所以我们订阅的订单支付状态的频道就得唯一，一个订单一个频道，我们可以在频道上加上订单号 pay_notice_wk+orderNo 保证频道唯一。这样我们可以把频道号在支付时当做参数一并传过去，支付平台处理完就可以用此频道发布消息给我们了。（实际大多接口用回调通知，因为用 Redis 发布订阅限制条件苛刻，系统间必须共用一套 Redis）
任务通知
比如通过跑批系统通知应用系统做一些事（跑批系统无法拿到用户数据，且应用系统又不能做定时任务的情况下）。
如每天凌晨 3 点提前加载一些用户的用户数据到 Redis，应用系统不能做定时任务，可以通过系统公共的 Redis 来由跑批系统发布任务给应用系统，应用系统收到指令，去做相应的操作。
这里需要注意的是在线上集群部署的情况下，所有服务实例都会收到通知，都要做同样的操作吗？完全没必要。可以用 Redis 实现锁机制，其中一台实例拿到锁后执行任务。另外如果任务比较耗时，可以不用锁，可以考虑一下任务分片执行。当然这不在本文的讨论范畴，这里不在赘述。
参数刷新加载
众所周知，我们用 Redis 无非就是将系统中不怎么变的、查询又比较频繁的数据缓存起来，例如我们系统首页的轮播图啊，页面的动态链接啊，一些系统参数啊，公共数据啊都加载到 Redis，然后有个后台管理系统去配置修改这些数据。
打个比方我们首页的轮播图要再增加一个图，那我们就在后管系统加上，加上就完事了吗？当然没有，因为 Redis 里还是老数据。那你会说不是有过期时间吗？是的，但有的过期时间设置的较长如 24 小时并且我们想立即生效怎么办？这时候我们就可以利用 Redis 的发布订阅机制来实现数据的实时刷新。当我们修改完数据后，点击刷新按钮，通过发布订阅机制，订阅者接收到消息后调用重新加载的方法即可。