在軟體架構中，釋出-訂閱（publish–subscribe）是一種訊息傳播模式，訊息的傳送者（釋出者）不會將訊息直接傳送給特定的接收者（訂閱者）。而是將釋出的訊息按特徵分類，無需對訂閱者（如果有的話）有所瞭解。同樣的，訂閱者可以表達對一個或多個類別的興趣，只接收感興趣的訊息，無需對釋出者（如果有的話）有所瞭解。

釋出/訂閱（pub/sub）與訊息佇列正規化屬於同一層級，通常是更大的面向訊息中介軟體系統的一部分。大多數訊息系統在應用程式介面（API）中同時支援訊息佇列模型和釋出/訂閱模型，例如Java訊息服務（JMS）。

這種模式提供了更大的網路擴充套件性和更動態的網路拓撲。

訊息過濾

在釋出/訂閱模型中，訂閱者通常只接收所有釋出訊息的一個子集。對需要接收和處理的訊息做出選擇的過程，稱為過濾。有兩種常用的過濾形式：基於主題和基於內容。

在基於主題的系統中，訊息被髮布到“主題”或命名的邏輯通道。基於主題的系統中，訂閱者將收到其訂閱的主題上的所有訊息，而且同一主題的所有訂閱者將接收到同樣的訊息。釋出者負責定義訂閱者可以訂閱的訊息類別。

基於內容的系統中，只有當訊息的屬性或內容匹配訂閱者定義的約束條件時，訊息才會被投遞給該訂閱者。訂閱者負責對訊息進行分類。

有些系統支援兩者的混合：釋出者釋出訊息到一個主題，而使用者註冊基於內容的訂閱到一個或多個主題。

拓撲結構

在許多釋出/訂閱系統中，釋出者釋出訊息到訊息中介，而訂閱者在該中介註冊訂閱，讓中介進行過濾。中介一般執行儲存轉發的功能將訊息從釋出者路由到訂閱者。此外，路由之前中介可能會將佇列中的訊息按優先順序排序。

歷史

最早公開描述的釋出/訂閱系統是Isis Toolkit中的“新聞”子系統，描述在1987年的美國計算機協會（ACM）作業系統原理專題討論會（87年SOSP）中的一份報告中，名為“分散式系統中的虛擬同步開發。123-138”[3]。 其中描述的釋出/訂閱技術是由Frank Schmuck發明的。

優點

鬆耦合

釋出者鬆耦合到訂閱者，甚至不需要知道它們的存在。因為關注的是主題，釋出者和訂閱者可以對系統拓撲結構保持一無所知。各自繼續正常操作而無需顧及對方。在傳統的緊耦合的客戶端-伺服器模式中, 當伺服器程序不執行時，客戶端無法傳送訊息給伺服器，伺服器也無法在客戶端不執行時接收訊息。許多釋出/訂閱系統不但將釋出者和訂閱者從位置上解耦，還從時間上解耦他們。

擴充套件性 

通過並行操作，訊息快取，基於樹或基於網路的路由等技術，釋出/訂閱提供了比傳統的客戶端–伺服器更好的擴充套件性。然而，在某些型別的緊耦合、高容量的企業環境中，隨著系統規模上升到由上千臺伺服器組成的資料中心所共享的釋出/訂閱基礎架構，現有的供應商系統經常失去這項好處；在這些高負載環境下，釋出/訂閱產品的擴充套件性是一個研究課題。

另一方面，在企業環境之外，釋出/訂閱正規化已經證明了它的可擴充套件性遠超過一個單一的資料中心，通過網路聚合協議如RSS和Atom（標準）提供網際網路範圍內分發的訊息。在互動時，為了能夠即便是用低檔Web伺服器也能將訊息播出到(可能)數以百萬計的獨立使用者節點，這些聚合協議接受更高的延遲和無保障交付。

缺點

釋出/訂閱系統最嚴重的問題是其主要優點的副作用：釋出者解耦訂閱者。釋出/訂閱系統必須仔細設計，才能提供特定的應用程式可能需要的更強大的系統性能，例如有保證交付。

• 釋出/訂閱系統的中介(broker)可能設計為在指定時間傳送訊息，隨後便停止嘗試傳送，無論是否已收到所有使用者成功接收訊息的確認回覆。這樣設計的釋出/訂閱系統不能保證訊息能夠傳遞到所有需要這種有保證交付的應用程式。要完成有保證交付，這種釋出者訂閱者在設計上的緊密耦合，必須強行脫離釋出/訂閱架構（例如，通過要求訂閱者宣佈訊息已接收）。
• 釋出/訂閱系統中的釋出者會“假定”訂閱者正在監聽，而實際上可能沒有。一個工廠可能會使用釋出/訂閱系統來允許裝置釋出問題和故障，訂閱者將問題顯示並記錄。如果記錄器失敗（崩潰了），那麼裝置故障釋出者不一定收到記錄器失敗的通知，釋出/訂閱系統的任何裝置都不會顯示和記錄錯誤訊息。應當指出的是，對於其它訊息架構這也是一個設計上的挑戰，例如客戶端/伺服器系統。在客戶端/伺服器系統中，當一個錯誤記錄器失效，系統將收到跡象。但是，客戶端/伺服器系統要處理這個失效，就必須擁有一個線上的冗餘日誌伺服器，或者動態生成回退日誌伺服器。這就增加了服務端和客戶端以及整個客戶端/伺服器架構設計的複雜度。然而，釋出/訂閱系統中，在不影響任何其它裝置的情況下，精確複製現有日誌器的冗餘日誌記錄訂閱者可以新增到系統，來增加日誌記錄的可靠性。在釋出/訂閱系統中，有保障的錯誤訊息日誌功能可以逐步新增，隨後實現裝置故障資訊記錄的簡單基本功能。

在有少量釋出者和訂閱節點的小型網路和低資訊量時釋出/訂閱能夠自如伸縮。然而，隨著節點和訊息量的增長，不穩定性隨之增長，限制了釋出/訂閱網路的最大可擴充套件性。大規模時吞吐量不穩定的例子有：

• 負荷激增 - 訂閱請求使網路流量飽和，隨後進入低資訊量（未充分利用網路頻寬）
• 速度變慢 - 越來越多的應用程式使用該系統（即使它們是在不同的釋出/訂閱頻道通訊）訊息量流入單個訂閱者的速度緩慢
• IP 廣播風暴 - 過量訊息導致的飽和時，區域網可能會徹底關閉，阻塞所有與釋出/訂閱無關的正常通訊

使用中介（伺服器）的釋出/訂閱系統，同意中介傳送訊息給帶內訂閱者，會引發安全問題。中介可能被愚弄，從而將通知傳送給錯誤的客戶端，增大了針對客戶端的服務請求被拒絕的可能性。中介本身可能超載，因為他們分配資源來跟蹤建立的訂閱者。

即使不依賴中介的系統，訂閱者也可能可以接收未被授權的資料。未經授權的釋出者可能將不正確或損壞的訊息引入到釋出/訂閱系統。對於廣播或多播訊息的系統，這是很真實的。加密（例如傳輸層安全性（SSL/TLS）），可以防止未經授權的訪問，但不能防止損壞的訊息被授權的釋出者引入。除了釋出/訂閱架構，例如客戶端/伺服器系統，也經常碰到授權的訊息傳送者有惡意行為。

語義耦合

釋出/訂閱系統對於空間、時間和同步的鬆散耦合，提供了可擴充套件的基礎架構，來進行資訊交換和分散式工作流。然而，通過事件的訂閱和方式，釋出/訂閱緊密耦合到底層事件的模式和取值的語義。在大型開放的部署中，例如智慧城市和感測器網路，事件的高度語義多相性使得釋出/訂閱系統難以開發和維護。為了解決釋出/訂閱系統中的語義耦合，使用事件的近似語義匹配是一個活躍的研究領域。

參考

引用

1. ^ Birman, K. and Joseph, T. "Exploiting virtual synchrony in distributed systems" in Proceedings of the eleventh ACM Symposium on Operating systems principles (SOSP '87), 1987. pp. 123-138.
2. ^ Hasan, Souleiman, Sean O’Riain, and Edward Curry. 2012. “Approximate Semantic Matching of Heterogeneous Events.” In 6th ACM International Conference on Distributed Event-Based Systems (DEBS 2012), 252–263. Berlin, Germany: ACM. “DOI”.

外部連結

• For an open source example which is in production on MSN.com and Microsoft.com, see Distributed Publish/Subscribe Event System
• Python PubSub a Python Publish-Subscribe broker for messages *within* an application (NOT network)