問題描述

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

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

問題解答

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

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

如果要管理贊的用戶，可以自定義數據格式。在用戶數量少的時候把用戶列表整個內嵌到HashSet的值域中。用戶超過比如50人后將其單獨整理出一個Set，在HashSet里保存Set的key。例：

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

由于絕大多數微博贊的用戶均比較少，HashSet可以節省出不少全局空間的key（全局key比HashSet的key更耗內存）。

關于 @賣掉內褲去上網 的回答：若采用in-place quicksort，50個用戶的手動排序效率非常高，因為在這個數據規模下數據緊密存放帶來的緩存友好性遠勝于Redis ZSet相對于手動排序帶來的提升。而贊的用戶升上去后就會自動適應成set或者zset，保證算法時間復雜度。如果還擔心效率，可以把排序好的UID列表重新寫回HashSet的一個value中，以后沒有數據改變的話直接使用。

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

不太推薦LS用HASH來存儲點贊的數據. 因為沒辦法進行排序(如果需要的話. 我想一定需要)

目前 我們是這樣處理的.

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

php$redis->ZADD('t:$tid:liked', time(), $uid); //$tid 為你的微博ID, $uid 為你的點贊人的UID//取出點贊的人(支持按照點贊時間來排序的哦:)).. 按照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 是一個array 哦..//判斷一個用戶是否點贊了這一來哦$redis->ZSCORE('t:$tid:liked', $uid);//取消贊這樣來$redis->ZREM('t:$tid:liked', $uid);//批量取消某短時間內的點贊這樣操作$redis->ZREMRANGEBYSCORE('t:$tid:liked', $start_timestamp, $end_timestamp);//諸如此類的操作, 要比HASH強很多.

恩再PS一下!!!

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

php$pipe = $redis->MULTI(Redis::PIPELINE);$pipe->SET('t:$tid', json_encode($data)) //json這種格式存儲貌似有點廢物. 如果能想到更好的格式的話,不要用JSON, 因為JSON太大了.. 比如MSGPACK這個個是就比JSON要好很多 ->ZADD('t:scores', time(), $tid);$pipe->EXEC();//PIPE 這樣的操作贊爆了. 如果你的REDIS支持事務的話, PIPE就不是一個原子性的操作了//取出數據的話就很好取出了!! $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就是你的數據啦

再再PS一下, 微博評論也是類似的存儲方法. 只是需要約定$redis KEYS的名稱. 比如:c:<評論ID> 怎么和微博數據關聯起來可以這樣:

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

這樣取數據的時候就用PIPELINE方便很多了.

最后啰嗦一句, NOSQL這種數據庫的 KEY 一定要設置好.

保存每個uid是否有必要，還是你覺得新浪微博就是這么搞的？大多數情況，其實大家只是關注一個數字，如果這樣的話，那么用一個數字來存儲就可以了{tid->count}

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

有個優化就是你可以設定一個閾值，比如超過100人點贊，就不再往里面加東西了，而僅僅加一個數字(當然這里需要你再存一個{tid->count})。因為超過1w的微博點贊，沒人回去逐個把每個點贊的人都點開的。。