原文：http://m.shnenglu.com/jaxe/archive/2010/08/30/125258.html

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




　　在大量玩家登陸游戲服務器時，由于有大量的數(shù)據庫訪問請求，即便是有自己實現(xiàn)的CACHE機制，還是會導致服務器耗盡所有的邏輯線程資源，服務器的處理能力將降低成DBMS的處理能力。
　　 
　　  為了不阻塞邏輯線程，可以采用異步數(shù)據庫訪問的方式，即數(shù)據庫操作請求提交給專門的數(shù)據庫處理線程池，然后邏輯線程不再等待數(shù)據庫處理結果，繼續(xù)處理其他，不再阻塞在這里。

　　  抽象的來看，對于一個需要持久化的游戲對象來說，可以考慮它有2個方法，讀取和保存。那么我們抽象一個DBO接口：
　　 
struct IDbo
{
　　 virtual bool SaveToDB(DB*)=0;
　　 virtual bool LoadFromDB(DB*)=0;
};



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




　　  改成數(shù)據庫異步處理后，在想想現(xiàn)在的游戲數(shù)據的保存機制應該是怎樣改進的，為了保障數(shù)據安全，我們希望不只是玩家下線的時候才會保存玩家數(shù)據，而是希望每隔一段時間統(tǒng)一保存所有在線[來源：GameRes.com]玩家的數(shù)據，那么，可以考慮這樣的思路：假設我們有一個GAMEDB服務器，GAMEDB緩存了所有在線玩家的角色數(shù)據，每到保存時間，GAMEDB就將所有在線玩家的數(shù)據(DBO）的副本都統(tǒng)一提交給DB線程池，讓它保存數(shù)據，提交的過程很快，提交完后，GAMEDB的邏輯線程仍能繼續(xù)處理游戲服務器的更新和讀取CACHE的請求。為什么要保存副本呢，DB線程的執(zhí)行保存隊列的過程也許很耗時，但是隊列中的數(shù)據都是GAMEDB提交DBO那個時刻的數(shù)據，這樣就能保證玩家的游戲數(shù)據的完整性。

　　   當然，我這里提的這只是個思路，這里面還有很多細節(jié)沒有討論，例如如果DB線程池正在保存九點鐘時刻保存的數(shù)據，到了十點鐘新的保存時刻時，DB線程池還沒保存完九點鐘時刻的DBO副本隊列，這時應該怎么處理；DBO對象的劃分粒度的問題；DBO隊列的優(yōu)先級的問題等等。