请教下 redis 的 pubsub 有什么作用？

[TangMonk]

进程间通讯？还是做及时消息推送？

[TangMonk]

我使用 socket.io 来做消息推送的。。感觉用不到这个功能，不太明白到底是干嘛的。。。

从 wikipeda 的 Publish–subscribe pattern ，看到 Messaging pattern， 还有 Message queue

其中的 「进程间通讯」、「消息队列」。。这些个名词搞不懂啊

消息队列是干嘛的？用来做即使消息推送的，然后作为用户的消息列表吗？

[HunterPan]

推送订阅消息

[TangMonk]

@HunterPan 咳咳。。麻烦您能详细解说下吗。。虽然你言简意赅，但是我还是没懂。。

[kaichen]

Pub/Sub模式比较常见的应用还是解耦两个系统吧，比如我有两个程序，可能是不同编程语言构建的，可能是在不同的机器上运行的，那么利用这个模式，可以比较简单地实现这两个程序之间的通讯。

消息队列，就是用来解耦系统的，以消息生产者和消息消费者的角色来定义两个系统。

举个例子，假如V2EX有个徽章的功能，当你抢沙发超过10次时，能获得一个「抢沙发小能手」的徽章。那么一般来说，代码会这么写，先创建这条回复，然后检查是否为该主题的第一个回复，如果是，对用户抢到沙发次数加1，最后判断用户抢到沙发次数是否大于10次，如果是则发放徽章。

那么，当回复里包含的逻辑越多时（比如还要通知被回复者），回复这个功能的代码会越复杂。此时如果我们采用消息队列，那么可以只是简单地创建回复记录，然后**发布一个回复被创建的消息**到消息队列。而检查是否发放徽章的**消息订阅程序**，会收到前面创建的这条消息，然后去做相应的检查逻辑。

通过这样解耦，添加回复这块代码会变得清晰，因为这里只负责创建这条记录，并发布这个消息出去，无须关心还有哪些逻辑。而处理剩下逻辑的部分，也相当清晰，因为一个消息订阅者只处理一个逻辑。单一的逻辑非常容易进行单元测试，但是这样同时会让系统分离成好多部分，变得复杂，故只有当你的逻辑相当复杂，并且需要提高扩展性，获得更好的性能的时候才会用到这个模式。

不知道这个例子是否清楚，希望能帮你理解。

[20150517]

我的理解，可能不正确，这就是个可以跨服务器的发布者与订阅者的关系，比如你触发了一件事，你希望通知所有监听的服务器，redis这个就方便这功能

[TangMonk]

@kaichen 昨晚上太困，先睡了，今早看到你的回复受益匪浅。

可不可以把消息队列理解为 middleware 呢

[julyclyde]

@TangMonk 消息队列就是middleware的一种。pubsub是多对多消息队列

[srdrm]

本质上都是消息队列模式