分類: 百科 常識詞典 編輯 : 常識 發(fā)布 : 08-13

閱讀 :439

新浪微博的共同好友功能是怎么實現(xiàn)的？SNS一般用的是No-L吧，不知道具體是用哪個數(shù)據(jù)庫？實現(xiàn)這個功能我只能想到是先找出自己的好友ID集合，然后再跟某一個好友的好友ID集合取交集得出共同好友數(shù)，不過感覺這樣效率會不會很低，不知道具體是怎么樣的...貌似連曾經關注過的人也會算到共同好友里面...6 個答案

答案 1：

新浪關注上限2000人，一般人的關注在3、4百人左右，其中互相關注的好友關系估計也就二三百人，做個緩存在Memcac-ed里，每次取兩個id列表做個交集，感覺也可以。另外，我覺得另一種方法可以是將每個人的好友存在Redis的一個sets里，然后用sets的SINTER功能取個交集可能會更高效一點。

答案 2：

效率還可以吧~但是曾經關注的人取消關注之后算在共同好友里就不應該了，有可能是數(shù)據(jù)還沒及時更新

答案 3：

vdisk.weibo/s/sDtG...這個ppt里有對好友，你可能要關注的人，朋友，粉絲等做了分析

答案 4：

新浪微波有redis的集群，blog.nosqlfan/-tml...，可以看看這里，在redis里面求交集是很高效的

答案 5：

注意，這是共同好友，不是共同粉絲。所以這個問題基本跟No-L神馬的沒有關系了，微博肯定會用上MC緩存，實際上的操作都是內存操作。新浪微博關于好友關系的各種計算都基于一個限制：關注的人上限2000那么就好辦了，好友id以key/value形式存儲（id做key），判斷某個id是否在另一個集里存在只需要一次判斷，id做key的好處是isset可以直接返回結果不需要比較兩個id是否相等，最多需要做一次遍歷2000次判斷就能找出共同好友，這個操作在內存里基本上是毫秒級別的消耗。實際上就算直接使用My-L，查詢出兩個人的id列表再用以上的方式求共同好友，效率也不是問題。關于曾經的好友計算出錯的問題，這個在大規(guī)模使用緩存技術的網站里是很正常的，數(shù)據(jù)在緩存里，而新浪的緩存是個集群，更新肯定會存在延遲。如果共同好友數(shù)據(jù)是實時計算的那么這個延遲應該不會超過兩個小時；如果是一段時間里計算好了直接緩存，定時更新（我覺得這種設計的可能性更大），那么你得等到下次-新數(shù)據(jù)的時候才會更新。

答案 6：

Mark一下，同關注。不過個人感覺，兩次單查詢的結果取交集的效率還可以。

下一篇:你會把中國人比成什么樣的果物？（見說明） 下一篇 【方向鍵 ( → )下一篇】

上一篇: Android 上的截屏軟件都要 root 權限呢？ 上一篇 【方向鍵 ( ← )上一篇】