假期7天學會Elixir，掌握函數式編程與 Actor 模型
為什么你一定需要學習 Elixir?
Elixir 是一門基于 erlang 開發的新語言，復用了 erlang 的虛擬機以及全部庫(站在已經生存了20多年巨人的肩膀上)，定義了全新的語法以及構造了現代語言必不可少生態環境—包管理器，測試工具，formatter等。使用 Elixir，你可以方便的構建可用性高達99.9999以及天然分布式的程序(代碼隨手一寫就是穩定的分布式)，可以秒開成千上萬 Elixir 里專屬的進程(比起系統的進程更輕量級)，處理高并發請求等等。
Elixr/Erlang 天然支持分布式， 而作者 Joe Armstrong 在論文中是這樣認為的：幾乎所有傳統的編程語言對真正的并發都缺乏有力的支持 —— 本質上是順序化的，而語言的并發性都僅僅由底層操作系統而不是語言提供。而用對并發提供良好支持的語言(也就是作者說的面向并發的語言 Concurrency Oriented Language) 來邊寫程序，則是相當容易的：
- 從真實世界的活動中識別出真正的并發活動
- 識別出并發活動之間的所有消息通道
- 寫下能夠在不同消息通道中流通的所有消息
Elixir 是怎么樣的語言?
Elixir 是函數式語言，與 java，C++等過程式語言不通，沒有變量?；蛘哒f，變量全都imutable(不可改變)。通過學習Elixir， 你可以學習多一種編程范式。
python 中你是這樣子處理列表的：
- mylist = []
- mylist.append('Google')
- mylist.append('Facebook')
- print mylist #結果是['Google', 'Facebook']
Elixir 中是這樣子的：
- myList = []
- myList = List.insert_at(myList, 0, "Google")
- myList = List.insert_at(myList, 1, "Facebook")
- IO.inspect myList
elixir 中這不是正常的寫法，不過我只是用這些例子來介紹異同點。
注意到，在面向對象思維的語言中，處理列表，是 用對象的方法，mylist.append: 對象.動作來處理;而函數式因為變量是不可變的，是要 List.append(mylist, xx), 對象模塊.動作(哪個對象)來處理，同時會返回修改后的新對象。
數據不可變，好處就是在高并發中，并不會因為狀態多且不斷變化，引致debug 異常困難——本來人的大腦就不適應多線程。
不可變，就意味著 for 與 while循環用不了，因為不存在變量 不斷 變化，達到某值就中止循環~因此，你只能用遞歸來實現 while。
但是不怕，Elixir 提供了強大無比的抽象， each 函數，map 函數，reduce 函數，all? 函數(判斷列表所有值是否滿足此條件)，group 函數(類似數據庫的 group) 等等，只有你想不到。相比之下，golang 真的是乏善可陳。
Go 語言的創始人之一，Unix 老牌黑客羅勃?派克(RobPike)的忠告：
所以說，沒有泛型就是不行的。。。
管道
是的，類似 linux 的管道 |，把處理結果傳遞給下一個函數。
- 1..100
- |> Enum.map(fn x-> x+1 end)
- |> Enum.filter(fn x-> rem(x, 2)==0 end)
- |> Enum.filter(fn x-> rem(x, 3)==0 end)
- |> Enum.filter(fn x-> rem(x, 5)==0 end)
- |> IO.inspect
與以下的 代碼相比，python是否相形見絀?
- numbers = range(1, 100)
- numbers = map( (lambda x: x+1), numbers )
- numbers = filter( (lambda x: x%2 == 0), numbers )
- numbers = filter( (lambda x: x%3 == 0), numbers )
- numbers = filter( (lambda x: x%5 == 0), numbers )
- print(numbers)
再來一個例子，來自Dave Long 的博客 Playing with Elixir Pipes[1] ：
代碼的作用是：取出請求的頭部 x-twilio-signature 簽名，并且校驗是否有效。
沒有管道時，代碼是這樣子的：
- signature = List.first(get_req_header(conn, "x-twilio-signature"))
- is_valid = Validator.validate(url_from_conn(conn), conn.params, signature)
- if is_valid do
- conn
- else
- halt(send_resp(conn, 401, "Not authorized"))
- end
加上管道：
- signature = conn
- |> get_req_header("x-twilio-signature")
- |> List.first
- if conn
- |> url_from_conn
- |> Validator.validate(conn.params, signature)
- do
- conn
- else
- conn |> send_resp(401, "Not authorized") |> halt
- end
邏輯就非常清晰了。還可以這樣子寫：
- signature = conn
- |> get_req_header("x-twilio-signature")
- |> List.first
- conn
- |> url_from_conn
- |> Validator.validate(conn.params, signature)
- |> if(do: conn, else: conn |> send_resp(401, "Not authorized") |> halt)
進程 Actor Model
輕量級的進程
在 Elixir 里，Elixir進程(以下簡稱進程，與系統進程區分開)是輕量級的進程，與操作系統的概念相差不多，只不過 Elixir 進程運行在虛擬機中。那為什么 Elixir 進程更快呢?
- Erlang 進程的堆棧是動態分配、隨使用增長的，新建一個 Erlang 進程的開銷遠比系統進程 / 線程小得多，開銷就像在 OO 語言中建立一個新對象般簡單。
- 普通進程 / 線程的內存管理是基于頁的，而頁對于一個函數 + 一點點零碎來說都太大了。而實際中 OS 分配給普通進程的初始棧可以達到 Megabytes 級別。
- Erlang 進程之間是隔離的，沒有共享狀態，所有的消息都是異步的，不會繼承大量的已有狀態。
- Erlang 進程的調度是在 Erlang VM 內發生的，跟 OS 層沒啥關系，無需普通進程 / 線程切換時的各種開銷
- Erlang 進程的切換是一種類似直接 “跳轉” 的方式，以 O(1) 復雜度實現。Erlang 調度器會管理這些切換，大概只需要幾十個指令和數十納秒的時間。普通線程的切換會需要數百上前納秒，OS 調度器的運作復雜度可能是 O(logn) 或者 O(log(logn))。如果有上萬個線程，這個時間將會大幅提升。來自知乎[2]
像指揮交響樂隊一樣，指揮你的 Elixir 進程
對于Elixir 進程，你可以方便的用一個進程(supervisor)去管理子進程，supervisor會根據你設定的策略，來處理意外掛掉的子進程(這種情況不多的是，錯誤處理稍微做不好就會掛) ， 策略有：
- one_for_one：只重啟掛掉的子進程
- one_for_all：有一個子進程掛了，重啟所有子進程
- rest_for_one：在該掛掉的子進程 創建時間之后創建的子進程都會重啟。
老夫敲代碼就是一把梭!可不，只要重啟就行。
實質上，這是有論文支持的: 在復雜的產品系統中，幾乎所有的故障和錯誤都是暫態的，對某個操作進行重試是一種不錯地解決問題方法——Jim Gray的論文[3]中指出，使用這種方法處理暫態故障，系統的平均故障間隔時間(MTBF)提升了 4 倍。
因此，你就可以創建一課監控樹，根節點就是啥事都不做，只負責監控的進程。其他都是它的子進程，如果不是 coredump(幾乎不發生)，那么根節點就不可能會掛;因此其他子進程就會正確的被處理。
當然，這有前提：5 秒內重啟超于 3 次，就會不再重啟，讓進程掛掉。為什么呢?因為重啟是為了讓進程回到當初啟動時的穩定態，既然穩定態都不穩定了，重復做重啟是沒有意義的，這時迫切需要人來處理。
方便的通信
一切皆消息。
進程間通信，就像微風一樣自然。你所監管的進程而來的信息，調用的庫的消息，全部都可以自己來 handle 并作相應處理。甚至還有抽象好的 GenServer 來讓你專門處理消息與狀態邏輯。
定時器?不需要的，我們甚至可以自己發送消息來實現更好的定時器：
Process.send_after 會在 xx 秒后發消息到指定的進程，通過這個功能，不斷往自己發消息，從而實現定時器的功能。請看實現：
- defmodule Periodically do
- require Logger
- use GenServer
- def start_link do
- GenServer.start_link(__MODULE__, %{})
- end
- def init(state) do
- schedule_work(:do_some_work)
- {:ok, state}
- end
- def handle_info(:do_some_work, state) do
- doing_now()
- schedule_work(:do_some_work)
- {:noreply, state}
- end
- defp schedule_work(update_type) do
- Process.send_after(self(), update_type, 30*1000)
- end
- end
相較于 setTimeOut 之類的，好處是什么?
Elixir 自帶工具，可以查看所有進程的狀態并管理，上面把 Periodically 作為一個進程啟動起來了，自然可以管理他：P
let it crash 思想的提出與實現。
程序不可能處理一切錯誤，因此程序員只要力所能及的處理顯然易見的錯誤就好了，而那些隱藏著的，非直覺性的錯誤，就讓他崩掉吧 —— 本來就很有可能是極少見的錯誤，經常出現的?就需要程序員人工處理了，這是緊急情況，就算 try catch 所有錯誤也無法避免，因為系統已經陷入崩潰邊緣了，茍延殘喘下去只是自欺欺人。
要注意的是 let it crash ，并不是說你用 golang，C++ 等語言打包個二進制，用 supervisorctl 等工具監控，錯誤就讓他馬上崩，掛了自動重啟 - = -
模式匹配與宏
這個相較于平常我們的賦值語言比較新穎，介紹的篇幅過長。
請看http://szpzs.oschina.io/2017/01/30/elixir-getting-started-pattern-matching/ 以及https://elixir-lang.org/getting-started/pattern-matching.html
通過模式匹配，我們可以避免 if else 的嵌套地獄;可以利用語言自己的匹配來做 搜索，
宏可以讓你實現自定義的 DSL(當然太強大的功能自然導致濫用出 bug)，可以屏蔽掉很多不優雅的細節。
以上就是 Elixir 的簡單介紹，建議諸位學習一下 Elixir，洗刷一下自己的 OO 以及過程式編程思維。
本文轉載自微信公眾號「山盡寫東西的cache」，可以通過以下二維碼關注。轉載本文請聯系山盡寫東西的cache公眾號。
