发布/订阅 模式

【https://zh.wikipedia.org/wiki/%E5%8F%91%E5%B8%83/%E8%AE%A2%E9%98%85】

发布/订阅[编辑]

维基百科，自由的百科全书

本条目部分链接不符合格式手册规范。跨语言链接及章节标题等处的链接可能需要清理。（2015年12月13日）  请协助改善此条目。参见WP:LINKSTYLE、WP:MOSIW以了解细节。突出显示跨语言链接可以便于检查。

发布/订阅（Publish/subscribe 或pub/sub）是一种消息范式，消息的发送者（发布者）不是计划发送其消息给特定的接收者（订阅者）。而是发布的消息分为不同的类别，而不需要知道什么样的订阅者订阅。订阅者对一个或多个类别表达兴趣，于是只接收感兴趣的消息，而不需要知道什么样的发布者发布的消息。这种发布者和订阅者的解耦可以允许更好的可扩展性和更为动态的网络拓扑.

发布/订阅是消息队列范式的兄弟，通常是更大的消息导向的中间件的系统的一部分。大多数消息系统在应用程序接口（API）中同时支持消息队列模型和发布/订阅模型，例如Java消息服务（JMS）。

消息过滤[编辑]

在发布/订阅模型中，订阅者通常接收所有发布的消息的一个子集。选择接受和处理的消息的过程被称作过滤。有两种常用的过滤形式：基于主题的和基于内容的。

在基于主题的系统中，消息被发布到主题或命名通道上。订阅者将收到其订阅的主题上的所有消息，并且所有订阅同一主题的订阅者将接收到同样的消息。发布者负责定义订阅者所订阅的消息类别。

在基于内容的系统中，订阅者定义其感兴趣的消息的条件，只有当消息的属性或内容满足订阅者定义的条件时，消息才会被投递到该订阅者。订阅者需要负责对消息进行分类。

一些系统支持两者的混合：发布者发布消息到主题上，而订阅者将基于内容的订阅注册到一个或多个主题上。

拓扑[编辑]

在许多发布/订阅系统中，发布者发布消息到一个中间的消息代理，然后订阅者向该消息代理注册订阅，由消息代理来进行过滤。消息代理通常执行存储转发的功能将消息从发布者发送到订阅者。

历史[编辑]

最早公开描述发布/订阅系统之一的是Isis Toolkit的“新闻”子系统，1987年，在计算机协会 (ACM)的操作系统原理的研讨会上，,在论文《在分布式系统中利用虚同步》^[1]中。该文描述的发布/订阅技术是由Frank Schmuck发明的。

优点[编辑]

松耦合： 发布者与订阅者松散地耦合，并且不需要知道对方的存在。由于主题是被关注的，发布者和订阅者可以对系统拓扑毫无所知。 发送者和订阅者都可以继续正常操作，不管对方。在传统的紧耦合的客户端-服务器范式中, 在服务器进程不运行时，客户端无法发送消息给服务器，服务器也无法在客户端不运行时接收消息。许多发布/订阅系统不单解耦发布者和订阅者的位置，还从时间上解耦发布者和订阅者。

可缩放性： 对于相对小的安装，发布/订阅通过并行操作，消息缓存，基于树的或基于网络的发送等，与传统的客户端/服务器相比，提供了更好的可缩放性的机会。可是，当系统升级成为包含数千台服务器的数据中心共享发布/订阅基础设施时，这一好处通常会丧失；实际上，在大型部署中在高负载时发布/订阅产品的可缩放性是一个非常大的研究课题。

注释[编辑]

1. 跳转^ virtual synchrony in distributed systems》

参见[编辑]

• 事件驱动程序设计
• 观察者模式
• 数据分布服务（DDS）
• 推技术（en:Push technology）
• Usenet

外部链接[编辑]

• XMPP XEP-0060: Publish-Subscribe Protocol
• For an open source example which is in production on MSN.com and Microsoft.com, see Distributed Publish/Subscribe Event System
• A REconfigurable Dispatching System (REDS)
• PyPubSub a Python Publish-Subscribe broker for messages *within* an application (NOT network)
• Another open source example written in python: see Python Message Service
• A Ruby open source example: Faye