關於分散式計算的一些概念
來自專欄 Java面試通關手冊9 人贊了文章
整理自《架構解密從分散式到微服務》第七章——聊聊分散式計算.做了相應補充和修改。
前言
不管是網路、內存、還是存儲的分散式,它們最終目的都是為了實現計算的分散式:數據在各個計算機節點上流動,同時各個計算機節點都能以某種方式訪問共享數據,最終分散式計算後的輸出結果被持久化存儲和輸出。 分散式作為分散式系統里最重要的一個能力和目標,也是大數據系統的關技術之一。經過多年的發展與演進,目前業界已經存在很多成熟的分散式計算相關的開源編程框架和平台供我們選擇。
一 不得不說的Actor模型
1.1 Actor模型的誕生與發展
Carl Hewitt於1970年發明Actor模型,當時Actor模型的概念遠遠領先於那個時代,知道Erlang這樣基於Actor模型設計的面向並發編程的新語言橫空出世之後,Actor模型才真真火了起來。
1.2 Actor模型是什麼?
Actor是計算機科學領域中的一個並行計算模型,它把Actor當做通用的並行計算原語:一個Actor對接收到的消息做出響應,進行本地決策,可以創建更多的Actor(子Actor),或者發送更多的消息;同時準備接收下一條消息。
在Actor理論中,一切都被認為是Actor,這和面向對象語言里一切都被看成對象很類似。但包括面向對象語言在內的軟體通常是順序執行的,而Actor模型本質上則是並發的。Actor之間僅通過發送消息進行通信,所有的操作都是非同步的,不同的Actor可以同時處理各自的信息,使整個系統獲得大規模的並發能力。
1.3 Actor模型原理簡單介紹
Actor模型簡單原理圖:
根據上圖,每個Actor都有一個Mailbox(郵箱),Actor A 發送給消息給Actor B,就好像Actor A 給Actor B寫了一封郵箱地址為Actor B的郵箱地址的郵件(消息)一樣,隨後平台負責投遞郵件。當郵件Actor B之後,平台就會通知Actor B收取郵件並做出回復,如果有多封郵件,則Actor B按順序處理。很簡單和容易理解的技術,但是蘊含了強大的力量。Actor B收到消息後可能會做那些處理呢?
- 創建其他Actor
- 向其他Actor發送消息
- 指定下一條消息到來的行為,比如修改自己的狀態
在什麼情況下一個Actor會創建子Actor呢?
通常情況是為了並行計算,比如我們有10G的文件要分析處理,我們可以在根Actor里創建10個子Actor,讓每個Actor分別處理一個文件,為此根Actor給每個子Actor發送一個消息,消息里包含分配給它的的文件編號(或位置),當子Actor完成處理後,就把處理好的結果封裝為應答消息返回給根Actor,然後根Actor在進行最後的匯總與輸出,下面是這個過程的示意圖。
一個Actor與其所創建的Actor形成父子關係。在實際編程中,父Actor應該監督其所創建的子Actor的狀態,原因是父Actor知道可能會出現那些失敗情況,知道如何處理他們,比如重新產生一個新的子Actor 來重做失敗的任務,或者某個Actor失敗後就通知其他Actor終止任務。
1.4 Actor模型的優缺點
通過上面對Actor模型原理的簡單分析,我們來總結一下Actor模型的優缺點。
優點:
1)將消息收發、線程調度、處理競爭和同步的所有複雜邏輯都委託給了Actor框架本身,而且對應用來說是透明的,我們可以認為Actor只是一個實現了Runnable介面的對象。關注多線程並發問題時,只需要關注多個Actor之間的消息流即可。
2)符合Actor模型的程序很容易進行測試,因為任意一個Actor都可以被單獨進行單元測試。如果測試案例覆蓋了該Actor所能響應的所有類型的消息,我們就可以確定該Actor的代碼十分可靠。
缺點:
1) Actor完全避免共享並且僅通過消息來進行交流,使得程序失去了精細化並發調控能力,所以不適合實施細粒度的並行且可能導致系統響應時延的增加。如果在Actor程序中引入一些並行框架,就可能會導致系統的不確定性。
2)儘管使用Actor模型的程序 比使用線程和鎖模型的程序更容易調試,Actor模型仍會碰到死鎖這一類的共性問題,也會碰到一些Actor模型獨有的問題(例如信箱移溢出)。
二 初始AKKA
2.1 AKKA簡介
Akka 是一個用 Scala 編寫的庫,用於簡化編寫容錯的、高可伸縮性的 Java 和 Scala 的 Actor 模型應用。它已經成功運用在電信行業。系統幾乎不會宕機(高可用性 99.9999999 % 一年只有 31 ms 宕機)。
Akka雖然是Scala寫成的,但是由於Scala最終還是編譯為Java位元組碼運行在JVM上,所以我們可以認為Akka屬於Java領域。
Akka處理並發的方法基於Actor模型。在Akka里,Actor之間通信的唯一機制就是消息傳遞。
Akka官方宣傳是這樣介紹Akka的:
- 是對並發、並行程序的簡單的高級別的抽象
- 是非同步、非阻塞、高性能的事件驅動編程模型
- 是非常輕量級的事件驅動處理(1GB內存可容納約270萬個actors)
2.2 為什麼要用Akka?
Akka是一個運行時與編程模型一致的系統,為以下目標設計:
- 垂直擴展(並發)
- 水平擴展(遠程調用)
- 高容錯
使用Akka帶來的好處:
- AKKA提供一種Actor並發模型,其粒度比線程小很多,這意味著你可以在項目中使用大量的Actor。
- Akka提供了一套容錯機制,允許在Actor出錯時進行一些恢復或者重置操作
- AKKA不僅可以在單機上構建高並發程序,也可以在網路中構建分散式程序,並提供位置透明的Actor定位服務
三 使用面很廣的Storm
與前面提到的Actor面向消息的分散式計算式模型不同,Apache Storm提供的是面向連續的消息流(Stream)的一種通用的分散式計算解決框架。
2.1 Storm簡介
Apache Storm是一種側重於極低延遲的流處理框架,也是要求近實時處理的工作負載的最佳選擇。該技術可處理非常大量的數據,通過比其他解決方案更低的延遲提供結果。
Storm作為實時流式計算中的佼佼者,因其良好的特性使其使用場景非常廣泛。
Zookeeper作為分散式協調服務框架,因其完善的數據一致性保證特性使其成為各框架必備組件。
2.2 Storm的應用場景
1)日誌處理: 監控系統中的事件日誌,使用 Storm 檢查每條日誌信息,把符合匹配規則的消息保存到資料庫。
2)電商商品推薦: 後台需要維護每個用戶的興趣點,主要基於用戶的歷史行為、查詢、點擊、地理信息等信息獲得,其中有很多實時數據,可以使用 Storm 進行處理,在此基礎上進行精準的商品推薦和放置廣告。2.3 Storm與Hadoop的關係
Hadoop 是強大的大數據處理系統,但是在實時計算方面不夠擅長;Storm的核心功能就是提供強大的實時處理能力,但沒有涉及存儲;所以 Storm 與 Hadoop 即不同也互補。
Storm與Hadoop應用場景對比:
Storm: 分散式實時計算,強調實時性,常用於實時性要求較高的地方
Hadoop:分散式批處理計算,強調批處理,常用於對已經在的大量數據挖掘、分析
三 MapReduce及其引發的新世界
3.1 MapReduce簡單介紹
與前面介紹的Actor模型一樣,MapReduce本質上也是一種很古老的並行計算模型,它的名字起源於LISP類函數式語言里的map和reduce操作。MapReduce的計算模型非常簡單,它的思想就是「分而治之」,Mapper負責「分」,即把複雜的大任務分解為若干個小任務來處理,彼此之間沒有依賴關係,以便可以分布到多個計算節點上實現高度的並行計算能力;Reducer則負責對map階段的結果進行匯總和輸出。
我們通過一個最簡單的統計詞頻的案例看一下,MapReduce的簡單原理:
3.2 MapReduce與Spark以及Storm孰優孰劣
Hadoop傳統意義上就是離線數據處理平台。但是2.0之後就不一樣了,因為多了yarn資源管理器(可能是收到了分散式資源調度系統Mesos的啟發),Spark和Storm都可以搭建在Hadoop之上,用yarn進行調度。這是大數據處理中目前最流行的三個計算框架。
Mapreduce: 適用於離線計算。這個框架充分利用了磁碟,處處存在著排序和合併。所以適合於實時性不高的離線計算。
Spark: 相對於Hadoop的MapReduce會在運行完工作後將中介數據存放到磁碟中,Spark使用了存儲器內運算技術,能在數據尚未寫入硬碟時即在存儲器內分析運算。Spark在存儲器內運行程序的運算速度能做到比Hadoop MapReduce的運算速度快上100倍,即便是運行程序於硬碟時,Spark也能快上10倍速度。Spark允許用戶將數據載入至集群存儲器,並多次對其進行查詢,非常適合用於機器學習演算法。
Storm: 一種側重於極低延遲的流處理框架,也是要求近實時處理的工作負載的最佳選擇。該技術可處理非常大量的數據,通過比其他解決方案更低的延遲提供結果。
關於三者的一些概括總結
Hadoop: 離線分析框架,適合離線的複雜的大數據處理
Spark:內存計算框架,適合在線、離線快速的大數據處理Storm: 流式計算框架,適合在線的實時的大數據處理我是Snailclimb,一個以架構師為5年之內目標的小小白。 歡迎關注我的微信公眾號:"Java面試通關手冊"(一個有溫度的微信公眾號,期待與你共同進步~~~堅持原創,分享美文,分享各種Java學習資源)
最後,就是使用阿里雲伺服器一段時間後,感覺阿里雲真的很不錯,就申請做了阿里雲大使,然後這是我的優惠券地址.
推薦閱讀:
※阿里最年輕合伙人胡喜:骨子裡沒點技術理想主義干不來自主研發
※基於靈活高速的存儲系統Alluxio 訓練深度學習模型
※深度解析 | 基於DAG的分散式任務調度平台:Maat
※Alluxio實戰手冊之設置(Configuration)篇