問(wèn)題描述

比如說(shuō)有一個(gè)微博的TID是1。 UID為1,2,3,4,5,6，7,8,9的用戶(hù)都給這個(gè)微博點(diǎn)贊了。用redis緩存框架存儲(chǔ)的話(huà)如何存儲(chǔ)。微博可能有幾十萬(wàn)個(gè)。如果用

key->set(value) 這種形式的話(huà) key是微博ID的標(biāo)示 value是 [1,2,3,4,5,6，7,8,9]這種形式，這樣的話(huà)有多少個(gè)微博就有多少個(gè)K-V存儲(chǔ)。我想知道這樣會(huì)有什么弊端嗎？或者有什么更好的方法嗎？

問(wèn)題解答

可以采用多個(gè)HashSet存儲(chǔ)。每一條微博只是HashSet內(nèi)的一個(gè)子key。增加贊的數(shù)量可以采用HIncrBy命令。把TID分塊，使得每個(gè)HashSet內(nèi)的key不超過(guò)100個(gè)。官方文檔表示HashSet在內(nèi)部元素小于一百個(gè)的時(shí)候采用線(xiàn)性存儲(chǔ)與掃描，跟同數(shù)據(jù)規(guī)模下樹(shù)形結(jié)構(gòu)相比效率更高，更省內(nèi)存。

例如：TID為123456的微博存在z:1234的HashSet中，其key為56。假設(shè)最新的微博活躍程度也較高，那么絕大多數(shù)情況下被調(diào)用的HashSet只有區(qū)區(qū)幾個(gè)，對(duì)CPU的緩存很友好。

如果要管理贊的用戶(hù)，可以自定義數(shù)據(jù)格式。在用戶(hù)數(shù)量少的時(shí)候把用戶(hù)列表整個(gè)內(nèi)嵌到HashSet的值域中。用戶(hù)超過(guò)比如50人后將其單獨(dú)整理出一個(gè)Set，在HashSet里保存Set的key。例：

bash# 內(nèi)嵌UID的情況hget z:1234 56> '1,2,3,4'...# 使用set的情況hget z:1234 56> 'UIDlist:10'smembers UIDlist:10> 1) '1'> 2) '2'> ...

由于絕大多數(shù)微博贊的用戶(hù)均比較少，HashSet可以節(jié)省出不少全局空間的key（全局key比HashSet的key更耗內(nèi)存）。

關(guān)于 @賣(mài)掉內(nèi)褲去上網(wǎng) 的回答：若采用in-place quicksort，50個(gè)用戶(hù)的手動(dòng)排序效率非常高，因?yàn)樵谶@個(gè)數(shù)據(jù)規(guī)模下數(shù)據(jù)緊密存放帶來(lái)的緩存友好性遠(yuǎn)勝于Redis ZSet相對(duì)于手動(dòng)排序帶來(lái)的提升。而贊的用戶(hù)升上去后就會(huì)自動(dòng)適應(yīng)成set或者zset，保證算法時(shí)間復(fù)雜度。如果還擔(dān)心效率，可以把排序好的UID列表重新寫(xiě)回HashSet的一個(gè)value中，以后沒(méi)有數(shù)據(jù)改變的話(huà)直接使用。

究竟采用set還是zset還是要看樓主的需求。set加入一個(gè)成員的復(fù)雜度為O(1)，zset是O(log N)，但set就沒(méi)有排序功能了。

不太推薦LS用HASH來(lái)存儲(chǔ)點(diǎn)贊的數(shù)據(jù). 因?yàn)闆](méi)辦法進(jìn)行排序(如果需要的話(huà). 我想一定需要)

目前 我們是這樣處理的.

可以使用ZSET有序集合進(jìn)行存儲(chǔ). 理論上說(shuō)一個(gè)ZSET中, 10W以?xún)?nèi)的數(shù)量并無(wú)任何鴨梨. 也就是說(shuō)一條微博點(diǎn)贊的人數(shù)再10W以?xún)?nèi)(這是不可能的).

php$redis->ZADD('t:$tid:liked', time(), $uid); //$tid 為你的微博ID, $uid 為你的點(diǎn)贊人的UID//取出點(diǎn)贊的人(支持按照點(diǎn)贊時(shí)間來(lái)排序的哦:)).. 按照LSD的說(shuō)的 HASH取出來(lái)的值沒(méi)有任何順序的.$uids = $redis->ZREVRANGE('t:$tid:liked', $offset, $max, TRUE); //倒序取值$uids = $redis->ZRANGE('t:$tid:liked', $offset, $max, TRUE); //順序取值//$offset 和 $max 這樣來(lái)算$pagesize = 20;$offset = ($page > 1) ? ($page - 1) * $pagesize : 0;$max = ($page * $pagesize) - 1;//一次性取出所有的這樣取.$total = $redis->ZCARD('t:$tid:liked');$uids = $redis->ZREVANGE('t:$tid:liked', 0, $total - 1, TRUE);//拿到的$uids 是一個(gè)array 哦..//判斷一個(gè)用戶(hù)是否點(diǎn)贊了這一來(lái)哦$redis->ZSCORE('t:$tid:liked', $uid);//取消贊這樣來(lái)$redis->ZREM('t:$tid:liked', $uid);//批量取消某短時(shí)間內(nèi)的點(diǎn)贊這樣操作$redis->ZREMRANGEBYSCORE('t:$tid:liked', $start_timestamp, $end_timestamp);//諸如此類(lèi)的操作, 要比HASH強(qiáng)很多.

恩再PS一下!!!

如果需要用到NOSQL這樣的數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)類(lèi)似微博的數(shù)據(jù)的話(huà), 可以這樣存儲(chǔ):).

php$pipe = $redis->MULTI(Redis::PIPELINE);$pipe->SET('t:$tid', json_encode($data)) //json這種格式存儲(chǔ)貌似有點(diǎn)廢物. 如果能想到更好的格式的話(huà),不要用JSON, 因?yàn)镴SON太大了.. 比如MSGPACK這個(gè)個(gè)是就比JSON要好很多 ->ZADD('t:scores', time(), $tid);$pipe->EXEC();//PIPE 這樣的操作贊爆了. 如果你的REDIS支持事務(wù)的話(huà), PIPE就不是一個(gè)原子性的操作了//取出數(shù)據(jù)的話(huà)就很好取出了!! $tid = $reids->ZREVRANGE('t:scores', 0, 100);$pipe = $redis->MULTI(Redis::PIPELINE); foreach($tid as $key=> $value){ $pipe->GET('t:$value');}$list = $pipe->EXEC();//$list就是你的數(shù)據(jù)啦

再再PS一下, 微博評(píng)論也是類(lèi)似的存儲(chǔ)方法. 只是需要約定$redis KEYS的名稱(chēng). 比如:c:<評(píng)論ID> 怎么和微博數(shù)據(jù)關(guān)聯(lián)起來(lái)可以這樣:

t:$tid:comments:scores (ZSET timestmap 評(píng)論ID);

這樣取數(shù)據(jù)的時(shí)候就用PIPELINE方便很多了.

最后啰嗦一句, NOSQL這種數(shù)據(jù)庫(kù)的 KEY 一定要設(shè)置好.

保存每個(gè)uid是否有必要，還是你覺(jué)得新浪微博就是這么搞的？大多數(shù)情況，其實(shí)大家只是關(guān)注一個(gè)數(shù)字，如果這樣的話(huà)，那么用一個(gè)數(shù)字來(lái)存儲(chǔ)就可以了{(lán)tid->count}

如果非要保存，建議還是用{tid->set(uid)}來(lái)保存

有個(gè)優(yōu)化就是你可以設(shè)定一個(gè)閾值，比如超過(guò)100人點(diǎn)贊，就不再往里面加?xùn)|西了，而僅僅加一個(gè)數(shù)字(當(dāng)然這里需要你再存一個(gè){tid->count})。因?yàn)槌^(guò)1w的微博點(diǎn)贊，沒(méi)人回去逐個(gè)把每個(gè)點(diǎn)贊的人都點(diǎn)開(kāi)的。。