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

時間 2019-11-24

原文原文鏈接

Java面試通關手冊（Java學習指南，歡迎Star，會一直完善下去，歡迎建議和指導）：github.com/Snailclimb/…html

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

前言

不論是網絡、內存、仍是存儲的分佈式，它們最終目的都是爲了實現計算的分佈式：數據在各個計算機節點上流動，同時各個計算機節點都能以某種方式訪問共享數據，最終分佈式計算後的輸出結果被持久化存儲和輸出。分佈式做爲分佈式系統裏最重要的一個能力和目標，也是大數據系統的關技術之一。通過多年的發展與演進，目前業界已經存在不少成熟的分佈式計算相關的開源編程框架和平臺供咱們選擇。github

一不得不說的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的代碼十分可靠。

缺點：

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： 一種側重於極低延遲的流處理框架，也是要求近實時處理的工做負載的最佳選擇。該技術可處理很是大量的數據，經過比其餘解決方案更低的延遲提供結果。