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