最簡單的游戲服務(wù)器只有一個進程，就是單點。如果這個過程退出，整個游戲世界都會消失。游戲服務(wù)器托管。在這個過程中，由于需要處理并發(fā)的客戶端數(shù)據(jù)包，有很多選擇方法:

每次接收到用戶會話時，都會建立一個線程。這個用戶會話往往是用客戶端的TCP連接來表示的，這樣每次調(diào)用一個包從套接字中讀寫，都可以使用阻塞模式，編碼直觀簡單。游戲客戶端的線程數(shù)和連接數(shù)一樣多。但是這種方案也有明顯的缺點，就是服務(wù)器容易產(chǎn)生大量的線程，很難控制內(nèi)存占用，線程切換也會造成CPU的性能損失。更重要的是，多線程下讀寫同一塊數(shù)據(jù)需要處理鎖問題，這可能會使代碼變得非常復雜，造成各種死鎖bug，影響服務(wù)器的穩(wěn)定性。

為了節(jié)省線程的創(chuàng)建和釋放，建立了線程池。當每個用戶會話建立后，應(yīng)用到線程池以供處理線程使用。當用戶會話結(jié)束時，線程不會退出，而是將該線程的使用“釋放”給線程池。線程池可以很好的控制線程數(shù)量，防止用戶激增對服務(wù)器造成連接沖擊，形成排隊機制。但是線程池本身的實現(xiàn)比較復雜，需要嚴格遵守“應(yīng)用”和“釋放”線程的調(diào)用規(guī)則，否則會出現(xiàn)線程泄漏，耗盡線程池。

在游戲行業(yè)，為了獲得高性能，使用Linux的epoll作為網(wǎng)絡(luò)API是一種常見的選擇。游戲服務(wù)器進程中最常見的阻塞調(diào)用是網(wǎng)絡(luò)IO，所以使用epoll后，整個服務(wù)器進程可能會變得完全沒有阻塞調(diào)用，所以只需要一個線程。這樣徹底解決了多線程的鎖問題，簡化了并發(fā)編程的難度。但是“所有通話不得阻塞”的約束條件并不是那么容易遵守的。比如一些數(shù)據(jù)庫API被阻塞；另外，單個進程、單個線程只能使用一個CPU，無法充分利用目前多核多CPU服務(wù)器中的CPU資源。異步編程是基于“回調(diào)”的，這就導致很多回調(diào)函數(shù)被定義，一個進程中的邏輯是用幾個不同的回調(diào)函數(shù)來寫的，這對代碼的讀取是非常不利的。對于這個編碼問題，coroutine可以更好的幫助，所以現(xiàn)在流行異步和Coroutine的結(jié)合。無論如何，異步單線程模型仍然是許多團隊的首選，因為它性能好，不需要并發(fā)思維。

這是一個基于異步單線程模型的演化模型。這個模型一般有三種類型的線程:主線程、IO線程和邏輯線程。這些線程在內(nèi)部都以完全異步的方式運行，它們通過一個無鎖的消息隊列相互通信。有不懂的請咨詢夢飛服務(wù)器了解。