actor模型跟nginx中worker_process的相同和差異有哪些？

02-05

actor模型跟nginx中worker_process的相同和差異有哪些？

並發模型有兩種，一種是並行工作者模型，一種是流水線模型。

一、所謂並行工作者模型，舉個例子來說，就好比汽車廠裡面的工人，每個工人專門負責一輛車子的生產，從頭到尾負責左右的工作。就好像是線程，拿到了一個請求，後面這個請求的所有工作都由這個線程來處理，直到所有這個請求的所有工作都結束。

nginx的workprocessor應該就是這種模型，某個linux進程拿到了用戶請求，然後負責這個請求的處理，高級點的地方就是用了非阻塞的IO，就好比這個汽車工人手頭有好幾輛車在處理，某輛車噴漆需要等待，那麼這個工人就去他負責的另一輛車上裝發動機。這種模型非常常見，比如Java裡面的Executor框架，只需要把Task交給某個線程來執行就ok了。

這種模型的好處是什麼呢？那就是，他很簡單，邏輯清晰，任務交給某個線程就可以了，並且可以很簡單的增加工作者來提高並行度（CPU足夠的情況下），或者使用非阻塞的IO（比如Nginx，這樣workprocessor數量只需要和cpu數量接近就可）。

但是這有什麼問題呢？最大的問題就是存在共享狀態，在訪問共享狀態的時候會存在竟態，處理不好還會發生死鎖。而進行同步又會造成性能損失甚至導致線程切換造成開銷。當然也有很多方法來避免這種問題，比如非阻塞演算法和不可變對象。

還有一個問題就是每個工作者內部無法保存這些共享狀態，導致每次都要重新讀取這些狀態，最直觀的就是cpu緩存失效，Java內存模型對這塊講的比較多。

二、還有一種模型指的是流水線模型，還是拿上面那個汽車工人的例子來說。

現在汽車廠改進生產流程，使用了生產線來進行生產，對於一輛汽車，將他分成許多道工序，每個工人負責其中的一個工序。當某個工人完成了噴漆工作，油漆還沒幹，這時候他不等待油漆干，就轉而開始另一輛車的噴漆工作，並把這輛車交給下一道工序。這輛車在流水線上油漆就就幹掉了，到了下一道工序了就可以直接工作了。

同時，整個工廠只需要一條生產線就可以快速生產，意味著某輛汽車的生產過程中的工具設備他只需要一套就夠了。如果是並行工作者，那就意味著有幾個工人就要幾套工具，這個成本太大，當然你也可以少幾套工具，大家共享幾套工具，但這也有同步的問題，都要用某個工具時必須等別人用完了才能用。

Actor模型就是一種流水線模型。

流水線模型可以很好地解決並行工作者的一些問題。首先最大的好處就是共享狀態消失了，由於某個請求都按步驟分給多個線程處理了，可以做到某個步驟只有一個線程在處理，這樣也就意味著共享狀態消失了。其次，共享狀態的消失，使得每個線程還可以緩存自己這個步驟處理所需的狀態，避免狀態的反覆讀取。

唯一的壞處就是寫代碼的人很痛苦，讀代碼的人也痛苦。要把某個請求按流程進行切分（切分的時機常常是出現阻塞的時候，比如IO，然後使用無阻塞IO），分布到不同的線程上，相當於把處理流程的代碼分開了，這個複雜度就上去了，相比前面那中所有業務代碼都寫一起，然後由多個線程執行，讀代碼的人看了流水線模型的代碼估計也要吐了。

當然，每個模型沒有誰好誰壞之分。孰好孰壞，到底用哪個模型，還是取決於你具體做什麼。

我想，這就是題主要問的問題吧？

沒有共同點

nginx 的 worker process 是系統進程, 一個 worker process 可以處理大量的並發連接但只有一個線程.

actor 是一種對象, 每個 actor 的並發處理數為 1, 但它很輕量, 可以大量創建.

其實有相似的地方：

Actor模型里，每個actor都可以被其它actor管理

Nginx中，master進程可以管理其它workers進程，master和worker之間的通信就類似於actor之間的通信。

這能扯上什麼關係