關於分散式計算的一些概念

通關手冊（Java學習指南，歡迎Star，會一直完善下去，歡迎建議和指導）：

整理自《架構解密從分散式到微服務》第七章——聊聊分散式計算.做了相應補充和修改。

前言

不管是網路、記憶體、還是儲存的分散式，它們最終目的都是為了實現計算的分散式：資料在各個計算機節點上流動，同時各個計算機節點都能以某種方式訪問共享資料，最終分散式計算後的輸出結果被持久化儲存和輸出。 分散式作為分散式系統裡最重要的一個能力和目標，也是大資料系統的關技術之一。經過多年的發展與演進，目前業界已經存在很多成熟的分散式計算相關的開源程式設計框架和平臺供我們選擇。

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模型獨有的問題（例如信箱移溢位）。

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:分散式批處理計算，強調批處理，常用於對已經在的大量資料探勘、分析

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: 流式計算框架，適合線上的實時的大資料處理