問題描述

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

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

問題解答

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

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

如果要管理贊的用戶，可以自定義數(shù)據(jù)格式。在用戶數(shù)量少的時(shí)候把用戶列表整個(gè)內(nèi)嵌到HashSet的值域中。用戶超過比如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ù)微博贊的用戶均比較少，HashSet可以節(jié)省出不少全局空間的key（全局key比HashSet的key更耗內(nèi)存）。

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

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

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

目前 我們是這樣處理的.

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

php$redis->ZADD('t:$tid:liked', time(), $uid); //$tid 為你的微博ID, $uid 為你的點(diǎn)贊人的UID//取出點(diǎn)贊的人(支持按照點(diǎn)贊時(shí)間來排序的哦:)).. 按照LSD的說的 HASH取出來的值沒有任何順序的.$uids = $redis->ZREVRANGE('t:$tid:liked', $offset, $max, TRUE); //倒序取值$uids = $redis->ZRANGE('t:$tid:liked', $offset, $max, TRUE); //順序取值//$offset 和 $max 這樣來算$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è)用戶是否點(diǎn)贊了這一來哦$redis->ZSCORE('t:$tid:liked', $uid);//取消贊這樣來$redis->ZREM('t:$tid:liked', $uid);//批量取消某短時(shí)間內(nèi)的點(diǎn)贊這樣操作$redis->ZREMRANGEBYSCORE('t:$tid:liked', $start_timestamp, $end_timestamp);//諸如此類的操作, 要比HASH強(qiáng)很多.

恩再PS一下!!!

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

php$pipe = $redis->MULTI(Redis::PIPELINE);$pipe->SET('t:$tid', json_encode($data)) //json這種格式存儲(chǔ)貌似有點(diǎn)廢物. 如果能想到更好的格式的話,不要用JSON, 因?yàn)镴SON太大了.. 比如MSGPACK這個(gè)個(gè)是就比JSON要好很多 ->ZADD('t:scores', time(), $tid);$pipe->EXEC();//PIPE 這樣的操作贊爆了. 如果你的REDIS支持事務(wù)的話, PIPE就不是一個(gè)原子性的操作了//取出數(shù)據(jù)的話就很好取出了!! $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)論也是類似的存儲(chǔ)方法. 只是需要約定$redis KEYS的名稱. 比如:c:<評(píng)論ID> 怎么和微博數(shù)據(jù)關(guān)聯(lián)起來可以這樣:

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

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

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

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

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

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