浩毛的博客

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

    在大量玩家登陸游戲服務(wù)器時(shí)，由于有大量的數(shù)據(jù)庫訪問請(qǐng)求，即便是有自己實(shí)現(xiàn)的CACHE機(jī)制，還是會(huì)導(dǎo)致服務(wù)器耗盡所有的邏輯線程資源，服務(wù)器的處理能力將降低成DBMS的處理能力。
    
     為了不阻塞邏輯線程，可以采用異步數(shù)據(jù)庫訪問的方式，即數(shù)據(jù)庫操作請(qǐng)求提交給專門的數(shù)據(jù)庫處理線程池，然后邏輯線程不再等待數(shù)據(jù)庫處理結(jié)果，繼續(xù)處理其他，不再阻塞在這里。
     抽象的來看，對(duì)于一個(gè)需要持久化的游戲?qū)ο髞碚f，可以考慮它有2個(gè)方法，讀取和保存。那么我們抽象一個(gè)DBO接口：
   

   
     然后把設(shè)計(jì)方案改成下面這種：

 

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

     PS:這篇文章里的架構(gòu)其實(shí)就是一個(gè)GAMEDB服務(wù)器，里面的邏輯處理就是GAMEDB的邏輯處理。你可以把這篇文章理解成：一個(gè)GAMEDB服務(wù)器 的實(shí)現(xiàn)思路。。。