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

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

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

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

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