focus on linux, c/c++, lua

導(dǎo)航

<

2012年1月

>

日

一

二

三

四

五

六

25

26

27

28

29

30

31

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

1

2

3

4

統(tǒng)計

隨筆 - 84
文章 - 0
評論 - 124
引用 - 0

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

搜索

閱讀排行榜

評論排行榜

如何把memcached應(yīng)用到我的項目中

      近日把memcached的相關(guān)協(xié)議看了下，把我的數(shù)據(jù)前端又重新梳理了一遍。開始琢磨著如何把我memcached應(yīng)用到項目中，對于我自己仿造的輪子有點失去信心了。。。如果是對于一個web項目，memcached有很大的發(fā)揮空間，特別是對一些靜態(tài)頁面的緩存，如圖片，文件，視頻等，不需要數(shù)據(jù)的同步，也不會存在從cache中獲得臟數(shù)據(jù)的可能。但是對于我們一個游戲項目，如果按照memcached的協(xié)議去做緩存，玩家第一次登錄的時候，從db獲取，并保存在cache中，以后該玩家的數(shù)據(jù)就直接從cache中獲取。但不同于web服務(wù)，玩家在游戲過程中，身上攜帶的數(shù)據(jù)不停的變化，這樣就會要求數(shù)據(jù)必須從服務(wù)器內(nèi)存同步到數(shù)據(jù)前端的cache,然后前端再通過一種機制存入硬盤的dbms。
      如果說這種方案實施成功的話，當(dāng)然會大大的減輕數(shù)據(jù)庫的壓力，memcached對內(nèi)存管理非常的給力，又可以分布式管理，甚至LRU機制讓下線的玩家依然可以把數(shù)據(jù)放在cache中。這些對于我來說誘惑很大，當(dāng)然這些都是理論上，其實理論上可以多數(shù)都是操蛋的。
      下面說說問題在哪里，先假設(shè)玩家的數(shù)據(jù)是這樣的：

struct user_data

{

int64 u_id (key);

string u_nickname;

int64 u_money;

int64 u_exp;

}

玩家第一次登錄的時候把這些信息全部獲取了，在該玩家下線的時候，u_exp增加了，但是u_money沒變，假設(shè)該時，我做一次數(shù)據(jù)同步，那么我犯愁了，玩家這么多數(shù)據(jù)，我該更新哪條數(shù)據(jù)呢？全部做一次數(shù)據(jù)覆蓋應(yīng)該不是一個好的設(shè)計，因為有可能db沒有提供一個覆蓋所有數(shù)據(jù)的存儲過程，只針對了每個數(shù)據(jù)段的更新提供存儲過程。這里有一個比較次一點的方案就是玩家在每次更新數(shù)據(jù)的時候，就讓cache去通知db也更新一次，這時cache就是把玩家的操作及時的轉(zhuǎn)達給了db,不用為日后的同步做任何tag。這樣下來db的寫操作還是沒有減少，但是讀操作大大的減少了，這也不失為一種折中方案。最近準(zhǔn)備試試這個方案，看下高峰期db的效率能提升多少。

posted on 2012-01-06 15:59 zuhd 閱讀(2638) 評論(8) 編輯收藏引用所屬分類: server

針對數(shù)據(jù)庫編程，需要注意網(wǎng)絡(luò)通信開銷。
1、更新一個字段和更新20個字段，對于數(shù)據(jù)庫來說開銷大頭在網(wǎng)絡(luò)通信上，除非一個IP包裝不下，否者考慮更新一個或多個字段總體來說沒有任何意義。
2、對于持久化，盡量使用批量接口，數(shù)據(jù)庫會很HIGH的。回復(fù) 更多評論

# re: 如何把memcached應(yīng)用到我的項目中 2012-01-09 09:10 zuhd

@zzzdev
你所指的網(wǎng)絡(luò)開銷是指帶寬？一般服務(wù)器和數(shù)據(jù)庫的通訊都是在局域網(wǎng)內(nèi)，不存在什么開銷，你說的批量接口，不懂耶回復(fù) 更多評論

# re: 如何把memcached應(yīng)用到我的項目中[未登錄] 2012-01-10 01:45 楊粼波

用SP可以節(jié)約一點帶寬。不過對于更新數(shù)據(jù)來說，對數(shù)據(jù)庫的消耗確實是大的。而如果只是查詢，那并不存在任何問題。

網(wǎng)絡(luò)開銷基本上不是問題，現(xiàn)在部署上多半都是同局域網(wǎng)的，千兆網(wǎng)卡，甚至光纖，很難造成太大的影響。

數(shù)據(jù)庫主要IO開銷還是在硬盤上，特別是更新數(shù)據(jù)。用memcached，主要也就是減輕磁盤IO的消耗，緩存在內(nèi)存中，減少對磁盤的操作。

像MySQL這樣級別的數(shù)據(jù)庫，可以把數(shù)據(jù)規(guī)模降低，比如分表這種做法。當(dāng)然，這需要數(shù)據(jù)規(guī)模達到一定程度。所以我現(xiàn)在還沒有分表。數(shù)據(jù)庫還能承受。

我現(xiàn)在頭疼兩個東西：
1.批量更新；
2.日志的增長。
日志倒還好，勤快點備份清理就好。
批量更新，可以緩存數(shù)據(jù)到內(nèi)存當(dāng)中，以期減少寫入頻率，但是，始終還是要寫入的，這個負載最終還是無可避免的。回復(fù) 更多評論

# re: 如何把memcached應(yīng)用到我的項目中 2012-01-10 09:11 zuhd

@楊粼波
你要是想減少寫操作，就模擬rpg的做法，玩家下線時統(tǒng)一保存數(shù)據(jù)，或是定時保存數(shù)據(jù)，日志嘛有錢的話單獨用一臺服務(wù)器做。
其實頻繁的讀操作也能把mysql拖的疲憊不堪，關(guān)系數(shù)據(jù)庫快要被淘汰了回復(fù) 更多評論

# re: 如何把memcached應(yīng)用到我的項目中 2012-01-10 10:41 楊粼波

再怎么減少，還是有操作的，只能說是盡量的減少操作量。因為現(xiàn)在的磁盤型硬盤io操作還是非常非常慢的。這種優(yōu)化是非常收益可觀的。

其實我現(xiàn)在也是采用的定時保存，開了數(shù)據(jù)庫的連接池。我有經(jīng)常查看數(shù)據(jù)庫的消耗，多半都是消耗在了批量更新上。現(xiàn)在來看，還是可以承受的。

如果你的MySQL能被查詢所拖垮，那你可以考慮下：能否減少查詢的次數(shù)？如果不可行，那是否應(yīng)該要去分表了？

現(xiàn)在的確KV型的NoSQL數(shù)據(jù)庫興起了，但是就我直覺來說，很長時間內(nèi)關(guān)系型的SQL數(shù)據(jù)庫是不大可能被淘汰的。回復(fù) 更多評論

刷新評論列表

只有注冊用戶登錄后才能發(fā)表評論。


相關(guān)文章: 關(guān)于非阻塞的connect處理一次主從數(shù)據(jù)庫切換的實戰(zhàn) Crontab小結(jié) 坑爹的存儲過程如何把memcached應(yīng)用到我的項目中 core文件的幾種查看方式服務(wù)器開機啟動進程網(wǎng)絡(luò)字節(jié)序的理解 mysql的備份與恢復(fù)的再探討更新manpages

網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

# re: 如何把memcached應(yīng)用到我的項目中 2012-01-06 19:47 zhs007

# re: 如何把memcached應(yīng)用到我的項目中 2012-01-07 09:06 zuhd

# re: 如何把memcached應(yīng)用到我的項目中 2012-01-07 15:02 zzzdev