用Redis来搞订阅发布广播，消息传递其实没那么复杂嘛

（引用来源：CSDN博客《Redis Pub/Sub：轻量级消息传递方案》）

记得以前在公司里，我们想做一个简单的通知功能，比如某个用户发表了新动态，要立刻通知到他的所有在线好友，一开始想到的是用消息队列，什么RabbitMQ、Kafka，光是把环境搭起来就头疼，配置一大堆，感觉杀鸡用了牛刀，后来团队里有个大哥说：“这么简单的广播，用Redis的订阅发布不就完了？几下就搞定了。” 我当时还半信半疑，Redis不是个缓存数据库吗？还能干这个？结果一试，发现还真是这么回事,消息传递其实没那么复杂嘛。

（引用来源：Redis官方文档对PUBLISH和SUBSCRIBE命令的解释）

Redis的订阅发布，核心就三个动作：发布、订阅、取消订阅，它就像一个小区里的广播站，想象一下，你不是有个大喇叭，而是有很多个不同的频道，小区停水通知”、“业主篮球赛”、“二手物品交换”，我呢，如果只关心停水信息和篮球赛，那我就般两个小板凳，坐到“停水通知”和“篮球赛”这两个频道前面等着听，这个“坐过去”的动作，就是订阅，而物业的工作人员，他不用管谁在听，他只需要拿起对应频道的话筒喊一嗓子：“各位业主请注意，明天上午停水三小时！”这个“喊”的动作，就是发布，所有当时正坐在“停水通知”频道前的人，就全都听到了，我要是哪天对篮球赛没兴趣了，我就把那个频道的小板凳撤了，这就是取消订阅，我根本不需要知道是谁发布的消息，发布的人也不需要知道消息都发给谁了,特别松散。

（引用来源：个人项目实践中的经验）

用代码来实现，简单得让人吃惊，假设我用Python的redis库，想订阅的人,代码大概长这样：

import redis
r = redis.Redis(host='localhost', port=6379)
pubsub = r.pubsub()
pubsub.subscribe('news')  # 订阅一个叫'news'的频道
for message in pubsub.listen():  # 开始监听，这是个阻塞操作
    if message['type'] == 'message':
        print(f"收到消息：{message['data'].decode('utf-8')}")

你看，连十行代码都不到，这个listen()方法会一直等着，直到有消息来，而发布消息的人，代码就更简单了,简直是一步到位：

import redis
r = redis.Redis(host='localhost', port=6379)
r.publish('news', '大家好，这是一条测试消息！')  # 向'news'频道发布消息

就这么一行关键的代码，消息就发出去了，之前那个订阅了news频道的程序，立马就会打印出“收到消息：大家好，这是一条测试消息！”，这种简洁性，对于快速开发一个功能原型或者对实时性要求高但允许少量消息丢失的场景,实在是太友好了。

（引用来源：网络技术论坛关于Redis Pub/Sub缺点的讨论）

当然啦，天下没有完美的工具，Redis这个“大喇叭”也有它的局限性，你得清楚它适用什么场合，最大的一个特点就是它不持久化，还拿小区广播打比方，物业广播的时候，如果你当时人不在小区，或者你没坐在那个频道的小板凳上，那这个消息你就永远错过了，Redis的订阅发布也是同样的道理，它是一种“fire-and-forget”的模式，消息发出去了，只给当前正在连接的订阅者，如果某个订阅者当时掉线了，重连之后是收不到断线期间的消息的，所以它不适合用在像订单处理、支付通知这种一条消息都不能丢的严肃场景。

（引用来源：博客园文章《Redis Pub/Sub与消息队列的对比》）

它也没有那种复杂的消息路由或者负载均衡机制，RabbitMQ那些专业的消息中间件，能搞什么工作队列、按规则路由、消息确认、持久化存储，保证消息万无一失，但Redis Pub/Sub就是纯粹的广播，来一个消息，所有订阅者都收到一份，至于你们收到后怎么处理，是大家一起处理还是咋的，它一概不管，所以它特别适合那种真正的“广播”场景：比如网页上的在线人数统计、简单的聊天室、服务器之间传递状态变化信号、或者像开头说的那种实时推送通知。

回到最开始的问题，当你需要一个轻量级、高效率、部署简单、而且能够接受偶尔消息丢失的实时消息广播机制时，Redis的订阅发布功能绝对是一个宝藏工具，它用最简单的概念和API，解决了消息传递中最核心的“一对多”即时通知问题，它让我们明白，技术选型不一定要选最强大最复杂的，而是要选最合适的，很多时候，问题本身没那么复杂，是我们把它想复杂了，用Redis搞订阅发布，就像是用一把顺手的水果刀，切水果刚刚好,没必要每次都把厨房里砍骨头的厚背大刀请出来。