Tag Archives: 分散式運算

新世紀通訊函式庫 – ZeroMQ

2012年就快到了,離2015年第三次衝擊也快到了,聽不懂我在說什麼就算了,跟主題沒什麼關聯,在介紹主角之前,我總喜歡描述一下主角的背景 欲上雲端,必先分散 這幾年,雲端炒得正熱門,愛跟風的台灣人當然也不能錯過,不管是賣主機的聲稱他們是做雲端的,連賣房子的也稱他們的是雲端,哪天就連在路邊看見雲端雞排都請不要大驚小怪,因為那簡直和奈米光觸媒雞排一樣有異曲同工之妙,然而口口聲聲說雲端,但前陣子iPhone4S預購就給了各家電信商一個大巴掌,他們的網頁伺服器都在一瞬間被大量擁入的使用者塞暴了,更別說其中還有不乏自家推出雲端服務的電信商,說真的,連分散運算的基本功都做不到,跟人家雲什麼端? 你說是吧? 但今天的主角不在於雲端是什麼,或是什麼才算真正的雲端之類的無聊話題,今天的主軸是分散式運算,因為要達到規模的運算和高可得性就一定要扯到分散式的運算,而分散式運算一直以來都不是什麼簡單的議題,最麻煩的就要算是溝通上的問題了,如果你有 三個節點之間想要進行溝通,該怎麼做? 你說簡單,直接串在一起不就好了? 好吧,或許你只有固定的三個節點,這好辦,但是要是你有更多的節點呢? 考慮一下十個節點、一百個節點,光想像就能知道,隨著節點的增加,他們之間的連線數量呈指數在成長,不光是連線本身的問題,連這些節點要如何知道對方的存在以及管理都是相當麻煩的問題 中央集權 光想就令人頭皮發麻,為了解決這樣的問題,一個經典的模式被設計且大量使用,那就是所謂的 Broker (掮客),也有稱Message Queue、Message bus等,簡單的概念,就是所有節點都連向中間的訊息交換伺服器,而溝通都透過這個中央的交換中心來進行,節點與節點之間無需去在意到底誰在和我溝通,只需要在意訊息的種類和內容即可   雖然這樣的模式解決了一些問題,但同時也引入了新的問題,分散式系統的頭號公敵 – 單點失效,正因為所有節點都依賴著這個中間的掮客幫忙轉送訊息,這也意味著當掮客網路斷線、當機等等意外的發生,都會讓整個系統陷入停擺的狀態,除此之外還有另一個嚴重的問題,就是當節點數量增加,掮客的工作量也會一直往上升,在無法擴增的情況下會造成整個系統的擴展性受到限制,效能也會因為掮客受限制 各自為政 正因為中央集權造成了問題,所以有人提出了各自為政來解決問題,可以想見的,在分散式的系統裡,並不是所有的節點都需要和所有人進行溝通,他們通常只需要和特定的節點溝通,舉個例子,假設你設計的是一個多媒體檔案的處理系統,在第一個節點可能做的是Hash,用來產生該檔案的唯一識別編號,節點二做的是轉檔,節點三做的是儲存,節點四做的是歸檔,那麼你需要的就只是這樣的結構,如果以物件導向的設計模式來看,我們稱這樣的結構為責任鏈   再看另一個例子,如果我們是氣象局,想發佈各種天氣的消息,那麼你需要的是一個伺服器,讓大家去訂閱他們有興趣的主題,這樣的結構以物件導向的觀點來看就叫做觀察者模式,與我們先前見到的Broker做的是一樣的事情,然而在這裡的重點在於該伺服器只負責發佈天氣消息,並不參與訊息的交換 整體的概念就是各自有不同的子系統,我們透過通訊的方式將它們串在一起,這樣做有個好處就是效能好,再來就是設計得當的話,某子系統雖然停擺,但不會影響到所有的系統 各自為政的代價 雖然各自為政的做法有其好處,但相對的也有它的代價,光是通訊的協定就是很腦人的問題,考慮一下各種不同的子系統間該用什麼協定來溝通,連線中斷了怎麼處理,負載平衡? 這些問題都要花相當大的心力來解決 而在不同的環境下,使用不同的通訊方式都各有好處,使用TCP/IP的話,不管你的節點在同一台機器或是遠端,都可以連線,缺點是在同一台機器會有一定的效能耗損,而且遇到廣播的訊息,同樣的訊息被傳送N次,就沒有UDP廣播來得划算,如果節點是在同一台機器上溝通,使用IPC的方式效率好,如果是在同一個thread裡,那麼分享記憶體的方式最快,IPC反而會拖慢速度,正因為有各種不同的考量,使得想要達成高效率的分散式系統是一件困難的事情 是主角登場的時候了 – ZeroMQ 講了半天,ZeroMQ到底是做什麼用的? 簡單的來說,它是一套網路通訊函式庫,用來解決上面所提到的問題,考慮一下上面所提到的物件導向設計模式,你想,即然那樣的模式一再出現,為什麼我們不能將這些常見的通訊方式變成可以輕易重覆使用的形式? ZeroMQ所做到的即是如此,它將常見的通訊方式定義成不同行為的socket,讓你可以輕易地重覆使用這些樣式去組出強健的分散式系統 老樣子 Hello world.. 不! 是Hello baby … Continue reading

Posted in 中文文章, 分享 | Tagged , , , , , , , , , , , , , | 8 Comments