今天和人電話聊了很長的技術問題，人家是成都臥龍工作室的，技術應該是很行的，但是在幾個問題上我們的見解不一。
一個單線程能不能形成幾萬的併發。
這個問題首先就是個錯誤的提法，換個說法：nginx是不是就可以達到幾萬的併發。
兩個問題犯的是相同的錯誤。
所有的併發都是針對業務處理的，業務簡單點，像對於一些靜態網頁的處理，或者是無IO的事務，單線程和nginx都是可以達到幾萬的併發的。
可是這兄弟對單線程能達到幾萬的併發還是表示不可想象。
前面一個單線程服務器博文就可以達到2W的併發，另外nginx的單進程模式其實就是單線程模式，對靜態網頁的處理輕鬆達到幾W的併發。
另外一個問題就是服務器的架構。
服務器的的架構無非兩種：
單線程事件模型，將事件與事務放在同一個線程中處理，用多進程方式進行負載分擔，如nginx。
多線程模型，將事件與事務分隔開來，或者事件也分隔開來。
你能說上面的模型哪個好哪個不好麼。
長期接觸過搞服務器的人，各種各樣的有，我發現經常有這樣的一個情況，就是喜歡自我滿足，比如，上次一個朋友硬說nginx比apache好，還從事件模型，緩存，架構上把nginx給我狠狠的補了一回課，結果我問了一句，你看過apache的代碼麼，你對apache瞭解多少。
如果有朋友堅持認爲nginx比apache好的，無非是因爲nginx的事件模型可以多路複用，那麼負載，伸縮性，模塊動態處理這些有沒有了解過呢，有爭議的朋友可以在評論裏說說。
有人常用多線程模型，就覺得要比單線程好，覺得單線程的服務器很低級，對單線程的服務器嗤之以鼻，卻又說不出讓人信服的道理，我覺得人不能停留在一個既定的認識水平上，而應該去往深處探索，而不是爲了工作而工作。
這樣想來，臥龍的遊戲服務器想必是個多線程模型。
回到正題，之前有篇架構博文裏畫了一個圖，圖中土黃色的管子代表高性能的模塊，紅色的管子代表低性能的模塊，這個圖可以明確什麼是瓶頸，現在咱們再舉個數據：
高性能的模塊每秒處理能力爲1W， 低性能的模塊每秒處理能力爲1K，如圖
如果要讓服務器的處理能力達到1W，先說說第二種模型，則業務層的線程至少要有10個，如圖
而如果採用第一種模型，則通過分擔負載的方式讓每個進程的負載均勻降低，用10個進程就可以了，如圖
這樣看來，兩種模型能幹相同的事，還能說孰優孰劣麼，只能說大家更熟悉哪一種模型了，可能第二種模型裏涉及到線程的同步，互斥，然後內存的分配與管理上要複雜一些，從架構上來說，應該儘量避免這樣的做法，因這無論從開發週期還是測試周期，都會延長，容易陷入一些複雜的應用場景中。
其實這兩種模型我都經歷過，前幾年喜歡用第二種，設計過一些多線程的技術方案比如內存池，曾經以爲這些很不錯，自從上一個項目用了第一種方案後，就發現其實單線程的優點還是有很多的，人員的開發分工上也簡單很多，架構邏輯、進程的控制、擴容管理、災難恢復上都要簡單很多。
這樣想來，其實nginx選擇這樣的單純線程其實不是並無道理的吧。