新浪微博的共同好友功能是怎麼實現的？

05-05

SNS一般用的是NoSQL吧，不知道具體是用哪個資料庫？實現這個功能我只能想到是先找出自己的好友ID集合，然後再跟某一個好友的好友ID集合取交集得出共同好友數，不過感覺這樣效率會不會很低，不知道具體是怎麼樣的...貌似連曾經關注過的人也會算到共同好友裡面...

新浪關註上限2000人，一般人的關注在3、4百人左右，其中互相關注的好友關係估計也就二三百人，做個緩存在Memcached里，每次取兩個id列表做個交集，感覺也可以。

另外，我覺得另一種方法可以是將每個人的好友存在Redis的一個sets里，然後用sets的SINTER功能取個交集可能會更高效一點。

注意，這是共同好友，不是共同粉絲。

所以這個問題基本跟NoSQL神馬的沒有關係了，微博肯定會用上MC緩存，實際上的操作都是內存操作。新浪微博關於好友關係的各種計算都基於一個限制：關注的人上限2000

那麼就好辦了，好友id以key/value形式存儲（id做key），判斷某個id是否在另一個集里存在只需要一次判斷，id做key的好處是isset可以直接返回結果不需要比較兩個id是否相等，最多需要做一次遍歷2000次判斷就能找出共同好友，這個操作在內存里基本上是毫秒級別的消耗。

實際上就算直接使用MySQL，查詢出兩個人的id列表再用以上的方式求共同好友，效率也不是問題。

關於曾經的好友計算出錯的問題，這個在大規模使用緩存技術的網站里是很正常的，數據在緩存里，而新浪的緩存是個集群，更新肯定會存在延遲。如果共同好友數據是實時計算的那麼這個延遲應該不會超過兩個小時；如果是一段時間裡計算好了直接緩存，定時更新（我覺得這種設計的可能性更大），那麼你得等到下次刷新數據的時候才會更新。

應該是用redis存儲的，http://blog.nosqlfan.com/html/3295.html這是新浪微博唐福林關於新浪微博開放平台Redis實踐做的分享，可以參考下

新浪微波有redis的集群，http://blog.nosqlfan.com/html/2692.html，可以看看這裡，在redis裡面求交集是很高效的

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

Mark一下，同關注。

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