dbmgr資料緩衝實現方式

在遊戲伺服器的開發中，在資料庫的前端常常採用一個資料服務器用來緩衝遊戲資料，並批量提交事務來提高整套系統的整體效能。
請參考   < 系統架構之一（RPG遊戲常用架構）> 中描述的dbmgr
在這裡我描述一種經過實踐並在大型遊戲項目中使用的dbmgr採用的緩衝策略:


dbmgr 採用記憶體資料庫fastdb來緩衝非日誌類的資料，
對於象玩家狀態等這些資料始終緩衝在fastdb的記憶體資料庫中
對於日誌類的流水表那些更新進DB後，就不會在FASTDB儲存了。


dbmgr收到事務請求後，先組織一個事務對象，對象裡麵包括了對當前事務中所有庫表對象的更新操作
同時在fastdb記憶體資料庫中執行事務，並將事務對象儲存到交易記錄隊列中。
dbmgr啟動單獨的線程定時從交易記錄隊列中批量取出事務對象更新到DB中



這種方案存在的問題：如果DB出現故障的情況下，dbmgr的記憶體會被寫的越來越大，可能會出現大量資料同步不到DB的風險，
另dbmgr程式崩潰，會導致未同步到DB的資料丟失。 往往某些項目從商業上來說可能允許一定時間範圍內的資料回檔故障，
我們在設計上可以要求必須在這個時間範圍內同步到DB，一旦超過這個時間，就只能警示，並停止系統運營，直到恢複正常。
對於那種不允許任何資料丟失，不可能容忍資料回檔的項目，那麼就必須即時同步到DB中了，當然即時同步到DB中時，也可以將
大量事務集中到一起採用批量事務提交，來提高整套系統的輸送量。


dbmgr在同步資料到DB中時，採用多個線程同時批量提交事務的方式，線程個數，每個批量事務中允許事務最多的個數，
這些都可以通過配置參數根據系統內容，軟硬體設定來調整以獲得最優效果。



在這個項目中 為了簡單起見所有的事務控制由dbmgr來控制，dbmgr不允許請求方來開始事務，結束事務，每一個請求就是一個事務，
如果要做的複雜些允許要求者控制事務的話 ，dbmgr中要加進事務狀態管理。以及處理各種事務異常的情況，例如要
有一個定時檢查事務狀態的功能， 例如某些情況下，用戶端啟動了一個事務，但一直沒有調用結束事務， 或網路斷了，
這些情況要自動識別並復原事務。