在游戲服務器中，處理玩家登陸需要向數據庫查詢玩家的賬號和密碼，玩家上線和下線需要對玩家的角色數據從數據庫中讀取和保存。可以說，相對于游戲邏輯處理來說，數據庫操作是一種相對很慢的操作，即便你通過使用多個線程多個數據庫連接來提高數據庫操作的處理能力，但是，在高并發高負載的服務器應用中，這樣仍然會是相當的負載瓶頸。設想這樣一種設計方案，見下圖：

    在大量玩家登陸游戲服務器時，由于有大量的數據庫訪問請求，即便是有自己實現的CACHE機制，還是會導致服務器耗盡所有的邏輯線程資源，服務器的處理能力將降低成DBMS的處理能力。
    
     為了不阻塞邏輯線程，可以采用異步數據庫訪問的方式，即數據庫操作請求提交給專門的數據庫處理線程池，然后邏輯線程不再等待數據庫處理結果，繼續處理其他，不再阻塞在這里。
     抽象的來看，對于一個需要持久化的游戲對象來說，可以考慮它有2個方法，讀取和保存。那么我們抽象一個DBO接口：
   

   
     然后把設計方案改成下面這種：

 

     改成數據庫異步處理后，在想想現在的游戲數據的保存機制應該是怎樣改進的，為了保障數據安全，我們希望不只是玩家下線的時候才會保存玩家數據，而是希望每隔一段時間統一保存所有在線玩家的數據，那么，可以考慮這樣的思路：假設我們有一個GAMEDB服務器，GAMEDB緩存了所有在線玩家的角色數據，每到保存時間，GAMEDB就將所有在線玩家的數據(DBO）的副本都統一提交給DB線程池，讓它保存數據，提交的過程很快，提交完后，GAMEDB的邏輯線程仍能繼續處理游戲服務器的更新和讀取CACHE的請求。為什么要保存副本呢，DB線程的執行保存隊列的過程也許很耗時，但是隊列中的數據都是GAMEDB提交DBO那個時刻的數據，這樣就能保證玩家的游戲數據的完整性。
      當然，我這里提的這只是個思路，這里面還有很多細節沒有討論，例如如果DB線程池正在保存九點鐘時刻保存的數據，到了十點鐘新的保存時刻時，DB線程池還沒保存完九點鐘時刻的DBO副本隊列，這時應該怎么處理；DBO對象的劃分粒度的問題；DBO隊列的優先級的問題等等。

     PS:這篇文章里的架構其實就是一個GAMEDB服務器，里面的邏輯處理就是GAMEDB的邏輯處理。你可以把這篇文章理解成：一個GAMEDB服務器 的實現思路。。。