-
發佈訂閲
鎖定
- 中文名
- 發佈訂閲
- 外文名
- publish-subscribe
- 類 型
- 消息範式
發佈訂閲簡介
發佈訂閲消息過濾
在發佈/訂閲模型中，訂閲者通常接收所有發佈的消息的一個子集。選擇接受和處理的消息的過程被稱作過濾。有兩種常用的過濾形式：基於主題的和基於內容的。
在基於主題的系統中，消息被髮布到主題或命名通道上。訂閲者將收到其訂閲的主題上的所有消息，並且所有訂閲同一主題的訂閲者將接收到同樣的消息。發佈者負責定義訂閲者所訂閲的消息類別。
在基於內容的系統中，訂閲者定義其感興趣的消息的條件，只有當消息的屬性或內容滿足訂閲者定義的條件時，消息才會被投遞到該訂閲者。訂閲者需要負責對消息進行分類。
一些系統支持兩者的混合：發佈者發佈消息到主題上，而訂閲者將基於內容的訂閲註冊到一個或多個主題上。
發佈訂閲拓撲
在許多發佈/訂閲系統中，發佈者發佈消息到一箇中間的消息代理，然後訂閲者向該消息代理註冊訂閲，由消息代理來進行過濾。消息代理通常執行存儲轉發的功能將消息從發佈者發送到訂閲者。
發佈訂閲歷史
最早公開描述發佈/訂閲系統之一的是Isis Toolkit的“新聞”子系統，1987年，在計算機協會(ACM)的操作系統原理的研討會上，在論文《在分佈式系統中利用虛同步》中。該文描述的發佈/訂閲技術是由Frank Schmuck發明的。
發佈訂閲優點
發佈訂閲松耦合
發佈者與訂閲者松耦合，甚至不需要知道它們的存在。由於主題才是關注的焦點，發佈者和訂閲者可以對系統拓撲結構保持一無所知。各自繼續正常操作而無需顧及對方。在傳統的緊耦合的客户端-服務器模式中，當服務器進程不運行時，客户端無法發送消息給服務器，服務器也無法在客户端不運行時接收消息。許多發佈/訂閲系統不但將發佈者和訂閲者從位置上解耦，還從時間上解耦他們。中間件分析師對這種發佈/訂閲使用的常用策略，是拆卸一個發佈者來讓訂閲者處理完積壓的工作（帶寬限制的一種形式）。
發佈訂閲可擴展性
- 通過並行操作，消息緩存，基於樹或基於網絡的路由等技術，發佈/訂閲提供了比傳統的客户端–服務器更好的可擴展性。然而，在某些類型的緊耦合、高容量的企業環境中，隨着系統規模上升到由上千台服務器組成的數據中心所共享的發佈/訂閲基礎架構，現有的供應商系統經常失去這項好處；在這些高負載環境下，發佈/訂閲產品的擴展性是一個研究課題。
發佈訂閲缺點
發佈/訂閲系統最嚴重的問題是其主要優點的副作用：發佈者解耦訂閲者。
消息交付問題：發佈/訂閲系統必須仔細設計，才能提供特定的應用程序可能需要的更強大的系統性能，例如有保障的交付。
- 發佈/訂閲系統的中介(broker)可能設計為在指定時間發送消息，隨後便停止嘗試發送，無論是否已收到所有用户成功接收消息的確認回覆。這樣設計的發佈/訂閲系統不能保證消息能夠傳遞到所有需要這種有保障交付的應用程序。要達成有保障交付，必須在發佈/訂閲架構之外強制執行這種發佈者和訂閲者之間在設計上更緊密的耦合（例如，通過要求訂閲者宣佈消息已接收）。
- 發佈/訂閲系統中的發佈者會“假定”訂閲者正在監聽，而實際上可能沒有。一個工廠可能會使用發佈/訂閲系統來允許設備發佈問題和故障，訂閲者將問題顯示並記錄。如果記錄器失敗（崩潰了），那麼設備故障發佈者不一定收到記錄器失敗的通知，發佈/訂閲系統的任何設備都不會顯示和記錄錯誤消息。應當指出的是，對於其它消息架構這也是一個設計上的挑戰，例如客户端/服務器系統。在客户端/服務器系統中，當一個錯誤記錄器失效，系統將收到跡象。但是，客户端/服務器系統要處理這個失效，就必須擁有一個在線的冗餘日誌服務器，或者動態生成回退日誌服務器。這就增加了服務端和客户端以及整個客户端/服務器架構設計的複雜度。然而，發佈/訂閲系統中，在不影響任何其它設備的情況下，精確複製現有日誌器的冗餘日誌記錄訂閲者可以添加到系統，來增加日誌記錄的可靠性。在發佈/訂閲系統中，有保障的錯誤消息日誌功能可以逐步添加，隨後實現設備故障信息記錄的簡單基本功能。
在有少量發佈者和訂閲節點的小型網絡和低信息量時發佈/訂閲能夠自如伸縮。然而，隨着節點和消息量的增長，不穩定性隨之增長，限制了發佈/訂閲網絡的最大可擴展性。大規模時吞吐量不穩定的例子包括：
- 負載激增 - 訂閲請求使網絡流量飽和，隨後進入低信息量（未充分利用網絡帶寬）
- 速度變慢 - 越來越多的應用程序使用該系統（即使它們是在不同的發佈/訂閲頻道通信）消息量流入單個訂閲者的速度緩慢
使用中介（服務器）的發佈/訂閲系統，同意中介發送消息給帶內訂閲者，會引發安全問題。中介可能被愚弄，從而將通知發送給錯誤的客户端，增大了針對客户端的服務請求被拒絕的可能性。中介本身可能超載，因為他們分配資源來跟蹤創建的訂閲。
