現在你已經見識了ømq的實際應用,讓我們回到「為什麼」。
目前很多應用程式由跨越某種網路的元件組成,不是區域網就是網際網路。那麼多的程式設計師最終都在從事某種訊息傳遞。一些開發者使用訊息佇列產品,但大多是用tcp或udp來自己開發。這些協議不難使用,但是從a到b傳送少量位元組和任何可靠方式的訊息傳遞之間是有非常大的區別的。
讓我們看看當我們開始用原始tcp來連線時面臨的典型問題。任何可重用的訊息層都需要解決全部或大部分以下問題:
看乙個典型的開源專案如hadoopzookeeper,參見src/c/src/zookeeper.c裡的c api。當此文寫作時,2023年,已有3200行神秘**,裡面有個未公開的客戶端伺服器網路通訊協議。我明白它很有效率因為使用了poll()而不是select()。但實際上,zookeeper應該使用乙個通用的訊息層和顯式公開的線路級協議。對於團隊來說要一遍一遍的建造這個獨特的輪子真是個驚人的浪費。
但是如何製作可重用訊息層?為何當那麼多專案需要這項技術,人們還是在用困難的辦法,通過在**中驅使tcp套接字,並解決著那個長長列表中的難題,一遍一遍?
圖7 – 開始時的訊息傳遞messaging as it starts
事實證明建造可重用訊息傳遞系統真的很難,這就是為何只有少數foss(自由開源軟體)嘗試過,而商業的訊息傳遞產品為何複雜、昂貴、僵化、脆弱。2023年imatix公司設計了amqp(高階訊息佇列協議),它開始給予foss開發者或許是第乙個訊息傳遞系統的可重用處方。amqp比很多其它設計都工作的更好,但還是相對複雜、昂貴、脆弱。需要花數週時間來學習使用,數月時間才能創造出當事情變得複雜時不至於崩潰的穩定架構。
大部分訊息傳遞專案,例如amqp,在嘗試以可重用方式解決這個長列表中的難題時,是通過發明乙個新概念,「中介」,來做定址、路由、和佇列。這導致了乙個客戶端伺服器協議或者一組api構建在一些未公開協議之上,來讓程式與中介交談。中介在減少大型網路複雜度方面是非常出色的。但是將基於中介的訊息傳遞新增到產品例如zookeeper將使它更糟,而不是更好。這將意味著新增乙個額外的大型機,和乙個新的單一故障點。中介迅速的成為乙個瓶頸和乙個新的管理風險。如果軟體支援,我們能新增第
二、第三、第四個中介,還能做一些容錯方案。人們這麼做著。建立了更多的移動部件、更多複雜度、更多故障。
並且以中介為中心的模式需要它自己的操作團隊。你真的需要日夜觀察著中介,當它行為不當時用棍子抽打。你需要機子,還需要備份的機子,還有管理這些機子的人。只有在做有很多移動部件、多個團隊人員建造的、跨越多年的大型程式時才值得這麼做。
所以中小型程式開發者被困住了。要麼他們避免網路程式設計,去做無需縮放的整體應用。要麼他們跳入網路程式設計去做脆弱、難以維護的複雜程式。要麼他們下賭注在乙個訊息傳遞產品上,最終可擴充套件性程式基於昂貴、易碎的技術。真沒有什麼好的選擇,這也許是為何訊息傳遞在上世紀死死卡住並激起強烈情緒。對於使用者來說是負面的,對於依靠支援和授權來盈利的人則是興奮而愉悅的。
圖 8 – 訊息傳遞變成了messaging as it becomes
我們需要的是能做訊息傳遞但方式上如此簡單而廉價,它能夠以接近零的成本,工作在任何程式中。它應該是乙個只需要鏈結的函式庫,無需任何其它依賴。沒有附加的移動部件,所以也沒有附加的風險。應當能執行在任何作業系統和任何程式語言。
而這就是ømq:乙個高效的、可嵌入庫,解決了讓乙個程式變得富有彈性的跨過網路的大部分難題,成本不高。
特別是:
事實上ømq做的比這更多。對於如何開發支援網路的程式方面具有顛覆性效果。表面上它是乙個受到套接字啟發的api,你通過它做zmq_msg_recv()和zmq_msg_send()。但訊息處理很快變成了中心迴圈,而你的程式馬上分解成一組訊息處理任務。優雅而自然。並擴充套件著:每個任務對映到乙個節點,節點們通過任意傳輸方式相互交談。程序內的兩個節點(節點是執行緒),機子上的兩個節點(節點是程序),或網路上的兩台機子(節點是機子)——都是一樣的,程式**沒有變化。
我們再看看ømq的擴充套件性。這裡是乙個shell指令碼用於啟動天氣伺服器然後啟動一群並行的客戶端:
wuserver &
wuclient 12345 &
wuclient 23456 &
wuclient 34567 &
wuclient 45678 &
wuclient 56789 &
客戶端執行時,我們用「top」命令來看看活動程序,會看到類似於(在4核機子上):
pid user pr ni virt res shr s %cpu %mem time+ command
7136 ph 20 0 1040m 959m 1156 r 157 12.0 16:25.47 wuserver
7966 ph 20 0 98608 1804 1372 s 33 0.0 0:03.94 wuclient
7963 ph 20 0 33116 1748 1372 s 14 0.0 0:00.76 wuclient
7965 ph 20 0 33116 1784 1372 s 6 0.0 0:00.47 wuclient
7964 ph 20 0 33116 1788 1372 s 5 0.0 0:00.25 wuclient
7967 ph 20 0 33072 1740 1372 s 5 0.0 0:00.35 wuclient
讓我們想想看這發生了什麼。天氣伺服器有乙個單獨的套接字,我們讓它向五個並行客戶端傳送資料。我們可能會有成千上萬的併發客戶端。伺服器程式看不到它們也不會直接與它們交談。那麼ømq就像個小伺服器,默默接受客戶端請求並以網路能處理的最快速度將資料推出。而且它是個多執行緒伺服器,從你的cpu中榨取更多的汁水。 ZeroMQ指南 第1章 基礎
分而治之 作為最終示例 你肯定對生動的 開始生厭並希望回頭去鑽研關於比較性 抽象性準則的語言學 讓我們來做乙個小型超級計算。然後喝個咖啡。我們的超級計算程式是個非常典型的並行處理模型。我們有 乙個通風機 ventilator 來產生可以並行處理的任務 一組工人 worker 來處理任務 乙個水槽 s...
《Ansible權威指南》第1章
第一篇 part 1 基礎入門篇 第1章 ansible基礎入門 第2章 ansible基礎元素介紹 第3章 ansible ad hoc命令集 第4章 playbook快速入門 第5章 ansible playbook拓展 第1章 ansible基礎入門 從早期all in one 所有應用部署在...
1 第1章 Pandas基礎
1.5.2.5 練習二 現有乙份關於科比的投籃資料集,請解決如下問題 1.5.2.6 a 哪種action type和combined shot type的組合是最多的?df pd.read csv data kobe data.csv index col shot id df.head pd.se...