314
多核時代：並行程序設計探討（6）——多機協作(又叫分布式處理)
多機協作（又叫分布式處理）
嗯，費了九牛二虎之力，終於將Windows和Linux對比完了。你是否準備伸個懶腰，喝杯熱咖啡，聽點音樂來放鬆一下呢？
別急，革命尚未成功，同誌還需努力，鐵還得趁熱打。還記得第二篇博文裏麵總結的兩種並行實現技術沒有？一個是“多進程多線程”，另一個是“多機協作”，到目前為止我們基本上隻把“多進程多線程”分析完畢了，還有另外一個“多機協作”沒有分析，本篇我們就探討一下“多機協作”這種實現機製。
不過事先申明，由於“多機協作”這種實現機製範圍太廣：小到普通的雙機、中到模擬地球運算的大型機或者巨型機、又如Google這樣NB的公司發明的分布式文件係統、再到現在熱熱鬧鬧的“雲計算”、或者大家最常用的BT、電騾等P2P技術都屬於這一範疇，且實現太過複雜，不同的係統實現機製也相差很大，限於本人能力，隻能“蜻蜓點水”了，如有興趣研究，推薦《分布式係統概念與設計》這本書，我也沒有讀過，不過據說還不錯。
幸運的是“多機協作”實現機製和“多核編程”並沒有什麼關係，因此即使蜻蜓點水對大家的多核設計水平影響不大。
廢話了半天，讓我們轉到正題上。雖然前麵提到了“多機協作”範圍很廣，實現機製也各不相同，但既然大家都劃到“多機協作”這一類裏麵，自然有一些基因是相同的。那麼就讓我們對“多機協作”進行一次基因圖譜製作，看看究竟有哪些共同基因。
u 隻有一種通信方式：消息。
是的，看到這個不要驚訝，雖然實現形式可以多種多樣，但本質上來說，多機協作係統隻有一種通信方式：消息。不管是基於TCP/IP的Socket消息，還是基於電信網7號信令的MAP消息，還是內部光纖通信的XX消息，本質上這些都是消息通信。和“多進程多線程”多種多樣的方式來比，顯得有點單薄，因此也就增大了設計的難度。
u 沒有多機同步機製
看到這個是不是更加吃驚？但現實就是如此殘酷，多機協作沒有一個現成可用的同步機製來實現諸如互斥、事件、信號量等同步功能。
但實際應用中你的應用又不得不用到這些東東，例如Google的分布式文件係統，因此你要自己去實現這些東東，這也增大了設計的難度。
u 沒有“老大”
這裏的老大不是指黑社會的老大哈，相反它是一個好公仆，這個“老大”負責全局的事物管理。嗯，你可能會說“多進程多線程”裏麵也沒有老大的啊？
多進程多線程之間確實沒有天然的老大，誰當老大完全是由我們設計人員決定的，但還有一個我們無法決定的老大：操作係統！操作係統在“多進程多線程”實現機製裏麵完成了眾多我們沒有怎麼關注但卻不得不用到的功能：進程線程創建、調度、隔離、通信、同步等。
在“多機協作”實現機製中，唯一的老大就是我們設計人員！你要決定如何隔離、如何調度、如何通信、如何同步等所有這些事情，因此設計難度又上一層樓！
舉個最簡單的例子：多進程多線程實現機製中，時間或者時鍾都是操作係統來控製和提供；而在多機協作中，光一個時間或者時鍾同步就能讓你累個半死！！
看完上麵的初步分析，我們可以得出一個這樣的結論：多機協作隻有一個消息通信，然後要基於消息通信來實現同步、通信、管理、調度、分布式處理等所有你所需要的功能！所以“多機協作”要比“多進程多線程”設計複雜得多。
看到這裏，你是否泄氣了呢？本著“不拋棄，不放棄”的精神，我們還是要勇敢麵對，而且幸好現在也有很多多機協作的解決方案了。流行的有三個：微軟的COM/DCOM、ORG的CORBA、SUN的Java RMI。這些多機協作（或者叫分布式）方案封裝了很多底層的通信、調用、同步等機製，使得我們能夠簡單的實現多機協作。
詳細的方案請各位參考COM、CORBA、RMI的相關文檔。
最後更新：2017-04-02 04:00:23