原文連接 http://www.aosabook.org/en/zeromq.htmlhtml
ZeroMQ 是一個消息系統,或者‘面向消息的中間件’。普遍應用於金融服務,遊戲開發,嵌入式系統,學術研究和航空航天領域。服務器
消息系統基本上用於應用程序的即時消息傳遞,應用程序決定將事件傳遞給另外一個應用程序(或多個應用程序),將要發送的數據組裝,點擊‘發送’按鈕,而後消息系統來處理剩餘的問題網絡
與及時消息不一樣,消息系統沒有GUI,假定在端點出現故障時沒有人進行智能干預。所以,消息系統必須是容錯的,並且比普通的及時消息要快的多 。架構
ZeroMQ最初被構想爲股票交易中的超快速消息傳遞系統,因此重點是極端優化。該項目第一年是設計基準方法,試圖定義儘量高效的體系結構。app
後來,大概是在第二年,重點轉移到提供一個通用的系統,用於構建分佈式應用程序和支持任意消息傳遞模式,多種傳輸機制,任意語言綁定等less
在第三年,重點是提升可用性和扁平化學習曲線。咱們採用了BSD套接字API,試圖清理我的消息模式的語義等等。分佈式
但願本章能洞察以上三個目標是如何轉化爲ZeroMQ的架構的,併爲那些正在解決一樣問題的人提供一些建議。性能
Zero是有一個庫,不是一個消息服務器。學習
咱們的主要關注點是性能:若是中間有一個服務器,每條消息將兩次經過網絡(發送者到代理,代理到接收者),包括延遲和吞吐量的損失。若是全部的消息都必須經過代理,在某些時候,必定會成爲瓶頸。優化
其次是關於大規模部署:當部署跨越組織邊界時,管理整個消息流的中心管理概念就再也不適用。任何公司都不肯意將控制權讓與其餘公司的服務器;有商業祕密,也有法律責任。實際的結果是,每一個公司都有一個消息服務器,用手寫的網橋鏈接其餘公司的消息系統。整個生態系統所以四分五裂,爲每一家相關公司維護大量橋樑並不能使狀況好轉。爲了解決這個問題,咱們須要一個徹底分佈式的體系結構,即每一個組件均可能由不一樣的業務實體管理。考慮到基於服務器的體系結構中的管理單元是服務器,咱們能夠經過爲每一個組件安裝一個單獨的服務器來解決這個問題。在這種狀況下,咱們能夠經過使服務器和組件共享相同的流程來進一步優化設計。咱們最終獲得的是一個消息傳遞庫。
當咱們知道如何在沒有中央服務器的狀況下進行消息傳遞時,MQ就開始了。從一開始,MQ就是一個庫,而不是一個應用程序。
經驗教訓是,當啓動一個新項目時,若是可能的話,您應該選擇庫設計。從一個庫中經過一個簡單的程序調用它很容易,可是,從一個現有的可執行文件中建立一個庫幾乎是不可能的。庫爲用戶提供了更大的靈活性,同時也爲他們節省了沒必要要的管理工做。
全局變量在庫中不能很好地發揮做用。一個庫可能在這個過程當中加載好幾回,但即便如此,也只有一組全局變量。下圖顯示了從兩個不一樣和獨立的庫中使用的ZeroMQ庫。而後應用程序使用這兩個庫。
當出現這種狀況時,這兩個實例都會訪問相同的變量,從而致使競爭條件、奇怪的失敗和未定義的行爲。
爲了防止這個問題,ZeroMQ庫沒有全局變量。相反,庫的使用者負責顯式地建立全局狀態。包含全局狀態的對象稱爲上下文。雖然從用戶的角度來看,上下文看起來相似於一個工做線程池,但從MQ的角度來看,它只是一個對象,用來存儲咱們碰巧須要的任何全局狀態。在上面的圖片中,libA和libB都有本身的上下文。
這裏的經驗很明顯:不要在庫中使用全局狀態。若是您這樣作了,那麼在同一進程中實例化兩次庫時,它可能會異常。