Linux多進程模型比多線程更容易實現熱部署嗎？

01-16

用多線程模型實現熱部署的難點和痛點在哪裡呢？

如果你指的是不停服務而更新二進位文件的話，那麼要做的事情有（錯誤檢查略）：

更新二進位文件-&>用新的二進位文件啟動服務-&>新老服務同時存在-&>老服務停止接受新的請求-&>所有請求處理完之後老服務退出-&>新的二進位文件單獨服務

使用多進程或者多線程模型，都需要經過這幾個步驟，要說難易程度的話，兩者應該在伯仲之間，並沒有太大的區別。

FB的這個項目facebookgo/grace · GitHub或許值得參考。

你有幾台伺服器硬體？

這些機器有沒有正常的重啟計劃？

沒有業務場景+環境約束，這個問題不好談啊

最簡單的來說，實現一個卡拉OK模式的服務，工作超過N秒或者超過M次執行就重啟，只要別重啟失敗，不管多進程多線程都容易熱更新

樓主不如好好分析一下進程和線程的區別。

再用這些區別去放到你需要的部署環節去考慮優劣。

區別和聯繫： 1、進程是獨立運行的實體，有獨立的資源分配； 2、同一進程的線程之間共享進程的資源； 3、所有的進程至少有一個執行線程； 4、線程的創建和切換代價比進程的小；線程間的通信方法： 1、同一進程的線程之間通信的最簡單辦法就是使...

是，因為進程級別熱置換可靠性可操作性更好，隔離性更好，更簡單。

如apache vs nginx, 通常App伺服器比Web伺服器佔用資源多，簡單的例子，如PHP跑在apache線程內，那麼釋放apache資源也就意味著釋放php資源，實際上redeploy是重新釋放php資源占絕大部分。但nginx就不同，web伺服器進程和app伺服器進程是分離的，需要熱部署的時候，只需要作app進程的swap或者簡單web伺服器進程重定向就可以了（要熱置換運行中的線程就沒那麼方便了），靈活性大一點，又因為在進程級別做操作，主要是對OS控制台來說可控性更好，可以做到0 downtime。也不用糾結線程安全等問題。

你要哪個規格的熱不熟？

如果系統容災設計妥當，主備一鍵熱切換，重點不在糾結進城線程上吧。