Elixir 分佈式平臺

概述

分佈式平臺的核心在於併發，容錯。 而 Elixir 的優點正是在於對於併發和容錯的處理。

分佈式模型

1. CSP(Communicating Sequential Process) 模型 :: 多個進程經過管道(channel)進行交互
2. Actor 模型 :: 每一個進程管理本身的內部狀態，經過消息和外界交互

對於 CSP 來講，重點在與 channel，經過 channel 管理併發的任務，並不關心執行任務的執行者。 Actor 模型關心的是任務的執行者(也就是 Actor)，每一個 Actor 都是能夠經過消息和外界交互，根據消息完成任務。

Elixir 採用的是 Actor 模型，golang 的併發是 CSP 模型。

併發

並行(concurrency)常常會和並行(parallelize)的機率混淆，併發是指同時發生，並行是指同時運行， 好比，在一個 4core 的機器上，併發的量可能上萬，可是並行可能只有 4。

Elixir 的併發是由 BEAM VM 來管理的，理論上，一個 BEAM VM 上能夠建立 268,000,000 個進程，基本就能夠當作是無限制。 通常來講，BEAM VM 都是經過少許的調度進程來管理大量的 processes Elixir 的併發進程之間不會共享任何東西(包括內存在內)。

容錯

對錯誤的處理方式，最廣泛的就是 try/catch，這種方式對於單機的系統來講能夠適用，可是對於分佈式系統來講，存在不足之處：

• 分佈式系統涉及多個系統間的交互，try/catch 只能在單點上捕獲異常
• 分佈式系統中可能發生的錯誤每每很難重現，也沒法預測，即便捕獲到異常，也很難預置處理方式，也就是不少異常會致使系統沒法恢復
• try/catch 機制通常都是捕獲錯誤，而後本身處理或者直接往上層拋異常，隨着系統的複雜，異常的層級也會愈來愈多

Elixir 中也有相似 try/catch 的機制，可是它的容錯性不是依靠這種機制來保證的。 Elixir 不是致力於去減小錯誤的發生，而是致力於提供一種機制去減小錯誤的影響，並使得系統可以本身從錯誤中恢復。

Elixir 中經過進程樹來確保整個應用的可用性，少數幾個進程做爲 supervisor，用來監管其餘完成實際業務的進程。 若是進程出現問題，由 supervisor 進程負責重啓或者銷燬。

除了進程樹，對於分佈式系統的容錯，Erlang 的理念是 let it crash 緣由也就是由於在分佈式系統中，不少的錯誤和環境相關，難於重現，而且不少時候在錯誤的基礎上恢復系統至關困難， 遠遠沒有直接重啓來的簡單有效。

固然，let it crash 不是 let everything crash，如下狀況仍是要處理：

-   對於關鍵性的進程，是絕對不能讓它 crash 的，好比有些主幹上的 supervisor
-   能夠預期的錯誤，就要有對應的錯誤處理，不能什麼都靠重啓來解決
-   let it crash 是指把那些沒法預期的錯誤交給 supervisor 來處理

OTP 平臺

OTP 平臺的分佈式系統核心是 process 和 message Elixir 自己也能夠實現很是健壯的分佈式系統，可是藉助 OTP 平臺上已經成熟的組件，能夠更快的建立一個分佈式應用

下面是 OTP 平臺上提供的成熟組件:(各個組件的示例參考：http://www.cnblogs.com/wang_yb/p/5589257.html)

1. agent
2. GenServer
3. GenEvent
4. task
5. supervisor