程序和執行緒的概念可以看作業系統原理,說下個人對伺服器使用程序和執行緒的看法:在保證正常支撐業務的情況下儘量用多程序完成併發簡單說,就是一個伺服器最重要的是穩定性以及可運營性,多程序可以比較好地實現這兩點,比如你程式有bug,某個地方崩潰了,如果是多執行緒,一個執行緒core了是大家一起陪葬的,而多程序就隻影響自己可運營方面,比如更新發布,如果採用多個程序分散式處理業務,多程序可以採用逐步更新的方式,例如,有10個程序在分攤前端的業務請求,則我們可以先透過分流控制,將請求從其中3個分攤到其它7個上,等被分流的3個程序基本空閒了,就停止並更新,然後再對剩餘7個程序做逐步分流和更新工作,也可以很自然完成灰度驗證,先分流較小的業務量到新的3個程序,跑個一兩天,沒問題了再全服更新,有問題了就回退,影響面很小,這種灰度測試的方式能很好地減輕測試的壓力,以及適應現在很多需要快速開發上線的網際網路業務,相當於讓部分使用者幫你測試這說的是多個程序分散式完成同樣的任務,從另個角度說,多程序按業務分離也是比較好的設計,比如一個遊戲,普通刷圖,pk場,商城,聊天什麼的都分開比較好,這樣萬一其中一個出了問題,比如聊天系統不可用或是維護,則對大部分玩家還是影響很少的簡而言之就是,解耦,解耦,解耦用程序來實現併發,單個程序內一般是可以不用多執行緒的,如果有阻塞API,最好先找找協程的方式,不行了再用執行緒池,開幾百幾千執行緒其實沒啥必要,因為CPU核數就那麼多,規避了阻塞呼叫問題就只需看著cpu核數開多程序就好不過凡事也有些例外,就像那個比喻說的,一個女人可以十月懷胎,卻不能十個女人一月合作生出一個孩子,有些時候多執行緒也有它的好處,例如,我們要做一個記憶體資料庫,比如redis這種,大家都知道redis是單執行緒的,那麼為了充分利用多核,我們可以在一個機器上開多個,但是,這樣一來每個程序都只能用到幾分之一的記憶體,如果某個key的資料很大,無法單個程序所接受,就麻煩了,也就是抗單點爆發的能力會差些,因為能力均攤了嘛,這時候就可以選擇一個程序內部用多執行緒,大家共享一個大資源池,在保持抗暴能力的基礎上提供併發計算能力,不過如上所述,執行緒的數量跟核數相配較好,開太多了反而慢其實,這種情況也可以透過多個程序共享一塊shm來實現(或其它資源形式,類推),只是程式設計會相對複雜些,關於執行緒的其它優勢,比如內部通訊只需要傳遞一個指標這種,也可以透過共享記憶體來在程序間實現,而且,資料放在shm也實現了資料邏輯分離,不會出現程序崩潰或停止造成資料丟失的情況了(當然不能崩在操作shm資料的地方,不過這種庫一般都封裝好經過嚴格測試的),資料和邏輯也是需要解耦這樣的問題是開發難度要高不少(想想在共享記憶體怎麼實現紅黑樹之類的),然而有的時候也是很有價值的,我們就搞過。。。
程序和執行緒的概念可以看作業系統原理,說下個人對伺服器使用程序和執行緒的看法:在保證正常支撐業務的情況下儘量用多程序完成併發簡單說,就是一個伺服器最重要的是穩定性以及可運營性,多程序可以比較好地實現這兩點,比如你程式有bug,某個地方崩潰了,如果是多執行緒,一個執行緒core了是大家一起陪葬的,而多程序就隻影響自己可運營方面,比如更新發布,如果採用多個程序分散式處理業務,多程序可以採用逐步更新的方式,例如,有10個程序在分攤前端的業務請求,則我們可以先透過分流控制,將請求從其中3個分攤到其它7個上,等被分流的3個程序基本空閒了,就停止並更新,然後再對剩餘7個程序做逐步分流和更新工作,也可以很自然完成灰度驗證,先分流較小的業務量到新的3個程序,跑個一兩天,沒問題了再全服更新,有問題了就回退,影響面很小,這種灰度測試的方式能很好地減輕測試的壓力,以及適應現在很多需要快速開發上線的網際網路業務,相當於讓部分使用者幫你測試這說的是多個程序分散式完成同樣的任務,從另個角度說,多程序按業務分離也是比較好的設計,比如一個遊戲,普通刷圖,pk場,商城,聊天什麼的都分開比較好,這樣萬一其中一個出了問題,比如聊天系統不可用或是維護,則對大部分玩家還是影響很少的簡而言之就是,解耦,解耦,解耦用程序來實現併發,單個程序內一般是可以不用多執行緒的,如果有阻塞API,最好先找找協程的方式,不行了再用執行緒池,開幾百幾千執行緒其實沒啥必要,因為CPU核數就那麼多,規避了阻塞呼叫問題就只需看著cpu核數開多程序就好不過凡事也有些例外,就像那個比喻說的,一個女人可以十月懷胎,卻不能十個女人一月合作生出一個孩子,有些時候多執行緒也有它的好處,例如,我們要做一個記憶體資料庫,比如redis這種,大家都知道redis是單執行緒的,那麼為了充分利用多核,我們可以在一個機器上開多個,但是,這樣一來每個程序都只能用到幾分之一的記憶體,如果某個key的資料很大,無法單個程序所接受,就麻煩了,也就是抗單點爆發的能力會差些,因為能力均攤了嘛,這時候就可以選擇一個程序內部用多執行緒,大家共享一個大資源池,在保持抗暴能力的基礎上提供併發計算能力,不過如上所述,執行緒的數量跟核數相配較好,開太多了反而慢其實,這種情況也可以透過多個程序共享一塊shm來實現(或其它資源形式,類推),只是程式設計會相對複雜些,關於執行緒的其它優勢,比如內部通訊只需要傳遞一個指標這種,也可以透過共享記憶體來在程序間實現,而且,資料放在shm也實現了資料邏輯分離,不會出現程序崩潰或停止造成資料丟失的情況了(當然不能崩在操作shm資料的地方,不過這種庫一般都封裝好經過嚴格測試的),資料和邏輯也是需要解耦這樣的問題是開發難度要高不少(想想在共享記憶體怎麼實現紅黑樹之類的),然而有的時候也是很有價值的,我們就搞過。。。