Erlang進程之錯?

前陣子erlang-china關於erlang該不該具有靜態特性討論的如火如荼，期間拋出了一個在erlang開發中遲早會遇到的問題：在一個擁有成千上萬併發process的系統中，某些process具有舉足輕重的位置，如其記錄log信息，提供某個核心查詢功能，這樣的情況下，無數的進程訪問一個進程，導致這個核心進程消息隊列異常增大，相應速度下降，timeout接踵而來，最後導致系統當掉。

這樣的情況，在其他語言的開發中也會遇到，只是在erlang的世界中，其似乎更加明顯，更加值得“批評”。
因爲erlang號稱是適應“高併發，分佈式，大規模系統”，這個小小的應用場景erlang就出了亂子，能不批評麼？

Erlang虛擬機調度器中，追求的哲學是每個進程都有均等的擁有資源的能力。

讓我們從虛擬機跳到現實社會中來。有一些老大，瘋狂的擄奪佔有資源，他們認爲自己可以利用這些資源做出最有意義的事情。
這樣下去可能會導致幾個問題：
1）他們真的對了麼？
2）小人物沒有得到任何資源，難道就要餓死麼？
3）老大掛掉了怎麼辦？資源還能有效的回收麼？會不會很麻煩？
這個現實世界的問題，可以簡單的映射到erlang的世界，需不需要有特權進程！
現實的世界證明，這個老大是靠不住的，衆生皆追求平等自由，所以目標就是讓每個人都有各種各樣的權力。erlang也是如此。

我曾經跟帖說出三個解決方案：
1，將這個核心進程，複製幾份，作爲一個整體獲取更多的執行機會，更多的io
2，提升進程的優先級別（process_flag(priority, max)），或者降低其他非關鍵進程的執行機會(yield)
3，將核心進程放入一個獨立的node，讓它自由的運轉

採用了方案1 ，因爲其簡單，不需要傷筋動骨，不需要系統大的改動，只是封裝出一個behaviour,根據scheduler的數目N，拷貝出N個進程，調用的時候，根據當前scheduler id選擇對應的進程。
方案1的確是一個簡陋的方案，但不是一個值得推崇的方案。

我們應該選擇方案3，其符合架構上的拓展（功能分割），可以平滑的走向分佈式。採用這種方法，web前端(erlang)的目的就是接受用戶請求，可以同時處理上萬的連接，這些進程是同類型的均等的。連接需要的處理操作，通過各種服務器節點(erlang)來處理。
這樣我們的web server可以有1M個進程，而服務器節點可以只有100個進程，每個部分都充分利用機器性能，不會因爲數量問題產生不快。

以後記住當某個進程“吃不消”的時候，首先考慮是你的架構上出問題了麼？如果沒有，那麼就認真的分析分析各部分的處理能力，讓最“累”的工作有更多的人分擔。
隨着系統不斷進行，你也更加的熟悉你的系統，這添一磚那加一瓦，讓他更好的提供服務。

Erlang進程真的沒錯，簡單纔是美.