近日把memcached的相關協議看了下，把我的數據前端又重新梳理了一遍。開始琢磨著如何把我memcached應用到項目中，對于我自己仿造的輪子有點失去信心了。。。如果是對于一個web項目，memcached有很大的發揮空間，特別是對一些靜態頁面的緩存，如圖片，文件，視頻等，不需要數據的同步，也不會存在從cache中獲得臟數據的可能。但是對于我們一個游戲項目，如果按照memcached的協議去做緩存，玩家第一次登錄的時候，從db獲取，并保存在cache中，以后該玩家的數據就直接從cache中獲取。但不同于web服務，玩家在游戲過程中，身上攜帶的數據不停的變化，這樣就會要求數據必須從服務器內存同步到數據前端的cache,然后前端再通過一種機制存入硬盤的dbms。 如果說這種方案實施成功的話，當然會大大的減輕數據庫的壓力，memcached對內存管理非常的給力，又可以分布式管理，甚至LRU機制讓下線的玩家依然可以把數據放在cache中。這些對于我來說誘惑很大，當然這些都是理論上，其實理論上可以多數都是操蛋的。 下面說說問題在哪里，先假設玩家的數據是這樣的：
玩家第一次登錄的時候把這些信息全部獲取了，在該玩家下線的時候，u_exp增加了，但是u_money沒變，假設該時，我做一次數據同步，那么我犯愁了，玩家這么多數據，我該更新哪條數據呢？全部做一次數據覆蓋應該不是一個好的設計，因為有可能db沒有提供一個覆蓋所有數據的存儲過程，只針對了每個數據段的更新提供存儲過程。這里有一個比較次一點的方案就是玩家在每次更新數據的時候，就讓cache去通知db也更新一次，這時cache就是把玩家的操作及時的轉達給了db,不用為日后的同步做任何tag。這樣下來db的寫操作還是沒有減少，但是讀操作大大的減少了，這也不失為一種折中方案。最近準備試試這個方案，看下高峰期db的效率能提升多少。
posted on 2012-01-06 15:59 zuhd 閱讀(2638) 評論(8) 編輯 收藏 引用 所屬分類: server
加個bool isUpdate;的標志不就完了么 回復 更多評論
我現在就是這么做的，從心理上一直覺得它很丑陋 回復 更多評論
針對數據庫編程，需要注意網絡通信開銷。 1、更新一個字段和更新20個字段，對于數據庫來說開銷大頭在網絡通信上，除非一個IP包裝不下，否者考慮更新一個或多個字段總體來說沒有任何意義。 2、對于持久化，盡量使用批量接口，數據庫會很HIGH的。 回復 更多評論
@zzzdev 你所指的網絡開銷是指帶寬？一般服務器和數據庫的通訊都是在局域網內，不存在什么開銷，你說的批量接口，不懂耶 回復 更多評論
用SP可以節約一點帶寬。不過對于更新數據來說，對數據庫的消耗確實是大的。而如果只是查詢，那并不存在任何問題。網絡開銷基本上不是問題，現在部署上多半都是同局域網的，千兆網卡，甚至光纖，很難造成太大的影響。數據庫主要IO開銷還是在硬盤上，特別是更新數據。用memcached，主要也就是減輕磁盤IO的消耗，緩存在內存中，減少對磁盤的操作。像MySQL這樣級別的數據庫，可以把數據規模降低，比如分表這種做法。當然，這需要數據規模達到一定程度。所以我現在還沒有分表。數據庫還能承受。我現在頭疼兩個東西：1.批量更新；2.日志的增長。日志倒還好，勤快點備份清理就好。批量更新，可以緩存數據到內存當中，以期減少寫入頻率，但是，始終還是要寫入的，這個負載最終還是無可避免的。 回復 更多評論
@楊粼波 你要是想減少寫操作，就模擬rpg的做法，玩家下線時統一保存數據，或是定時保存數據，日志嘛有錢的話單獨用一臺服務器做。 其實頻繁的讀操作也能把mysql拖的疲憊不堪，關系數據庫快要被淘汰了 回復 更多評論
再怎么減少，還是有操作的，只能說是盡量的減少操作量。因為現在的磁盤型硬盤io操作還是非常非常慢的。這種優化是非常收益可觀的。其實我現在也是采用的定時保存，開了數據庫的連接池。我有經常查看數據庫的消耗，多半都是消耗在了批量更新上。現在來看，還是可以承受的。如果你的MySQL能被查詢所拖垮，那你可以考慮下：能否減少查詢的次數？如果不可行，那是否應該要去分表了？現在的確KV型的NoSQL數據庫興起了，但是就我直覺來說，很長時間內關系型的SQL數據庫是不大可能被淘汰的。 回復 更多評論
Powered by: C++博客 Copyright © zuhd