上個周末看了下MySQL，安裝了一個試了下，重點看了c測試程序已經mysql.h中的API，發(fā)現(xiàn)好簡單，目前公司的游戲計劃也是用mysql，但是要設計好一個給游戲使用的數(shù)據(jù)庫模塊，也不是簡單的處理一下api就能了事的，游戲數(shù)據(jù)庫由于存取特別頻繁，在我看來，他的設計主要解決下面幾個問題：
1、數(shù)據(jù)緩存的功能
想想那么平凡的數(shù)據(jù)存取，完全依賴數(shù)據(jù)庫的直接操作，這個性能是可想而知的，所以應該建立起游戲服務器和數(shù)據(jù)庫之間的一個橋梁（暫且命名為數(shù)據(jù)庫前端），游戲服務器只跟數(shù)據(jù)庫前端交互，數(shù)據(jù)庫前端自己具有數(shù)據(jù)持久化的策略，不依賴于游戲服務器的操作。數(shù)據(jù)庫前端在第一次取出原始數(shù)據(jù)后（如一個角色登錄時的數(shù)據(jù)），將進行本地緩存，下次存取數(shù)據(jù)都是在本地進行，并不需要更新到數(shù)據(jù)庫中，至于何時更新到數(shù)據(jù)庫可以有數(shù)據(jù)庫前端自行決定（當然也不排除游戲服務器發(fā)出持久化的通知）。
2、增量更新的功能
其實好多數(shù)據(jù)的提交中，有很大一部分的數(shù)據(jù)是沒有改變的，如果在從前端提交數(shù)據(jù)到數(shù)據(jù)庫的時候采取相應的增量更新的辦法，應該對性能會有所提升，尤其是在幾個游戲服務器操作同一個數(shù)據(jù)庫的時候，因為異步的原因，增量更新能夠保證數(shù)據(jù)的正確性。
3、拋包策略
游戲服務器有很多數(shù)據(jù)實在太過頻繁，但是有些類型的數(shù)據(jù)的重要性一般，所以中途丟失一些也問題不大，在服務器數(shù)據(jù)交換比較頻繁的時候完全可以拋棄一些，加快存取速度（不過有了前端后是不是可以忽略這點）。
4、數(shù)據(jù)分流功能
主要體現(xiàn)在游戲服務器的一些不同類型的數(shù)據(jù)存取可以通過不同的幾個異步隊列進行處理，這樣即使由于數(shù)據(jù)庫的某些操作延時，也只影響到操作所在隊列，不會影響其他隊列。
5、靈活的多前端，多數(shù)據(jù)庫等支持
實現(xiàn)游戲服務器，數(shù)據(jù)庫前端，游戲數(shù)據(jù)庫之間的多對多關系，便于靈活的運用。
寫完后個人感覺達到第1，2點后，這個數(shù)據(jù)庫前端功能就已經比較強勁了。