阅读: 309
答案 1：
新浪关注上限2000人，一般人的关注在3、4百人左右，其中互相关注的好友关系估计也就二三百人，做个缓存在Memcac-ed里，每次取两个id列表做个交集，感觉也可以。另外，我觉得另一种方法可以是将每个人的好友存在Redis的一个sets里，然后用sets的SINTER功能取个交集可能会更高效一点。答案 2：
效率还可以吧~但是曾经关注的人取消关注之后算在共同好友里就不应该了，有可能是数据还没及时更新答案 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列表再用以上的方式求共同好友，效率也不是问题。关于曾经的好友计算出错的问题，这个在大规模使用缓存技术的网站里是很正常的，数据在缓存里，而新浪的缓存是个集群，更新肯定会存在延迟。如果共同好友数据是实时计算的那么这个延迟应该不会超过两个小时；如果是一段时间里计算好了直接缓存，定时更新（我觉得这种设计的可能性更大），那么你得等到下次-新数据的时候才会更新。答案 6：
Mark一下，同关注。不过个人感觉，两次单查询的结果取交集的效率还可以。分享常识给亲友.
下一篇:有哪些针对男人购物的分享社区呢？ 下一篇 【方向键 ( → )下一篇】
上一篇: Android 上的截屏软件都要 root 权限呢？ 上一篇 【方向键 ( ← )上一篇】
快搜