新浪微博关系服务与Redis的故事

　　新浪微博的工程师们曾经在多个公开场合都讲到过，微博平台当前在使用并维护着可能是世界上最大的Redis集群，其中最大的一个业务，单个业务使用了超过10T的内存，这里说的就是微博关系服务。

　　2009年微博刚刚上线的时候，微博关系服务使用的是最传统的Memcache+MySQL的方案。Mysql按uidhash进行了分库分表，表结构非常简单：

　　业务方存在两种查询：

　　♦查询用户的关注列表：select touid from table where fromuid=？order by addTime desc

　　♦查询用户的粉丝列表：select fromuid from table where touid=？order by addTime desc

　　两种查询的业务需求与分库分表的架构设计存在矛盾，最终导致了冗余存储：以fromuid为hashkey存一份，以touid为hashkey再存一份。memcachekey为fromuid.suffix，使用不同的suffix来区分是关注列表还是粉丝列表，cachevalue则为PHPSerialize后的Array。后来为了优化性能，将value换成了自己拼装的byte数组。

　   关注关系产生的四种关系状态

　　关注

　　粉丝

　　双向关注(互粉)

　　无关系

　　需求分析

　　在微博中，每一个用户都会有一个关注列表，一个粉丝列表。用户可以查看自己的关注，粉丝列表，也可以查看别人的关注，粉丝列表。并且，要展示列表里每个人与当前查看者的关注状态。状态的可能性就是上面讲到得四种关系状态。

　　问题可以分两种情况来看：

　　1、看自己的关注，粉丝列表

　　2、看别人的关注，粉丝列表

　　看自己的关注，粉丝列表：

　　这种情况相对简单一点。比如看自己的关注列表，列表里的人的与自己的关系状态不可能是“无关系”和“粉丝”。只可能是“关注”和“双向关注”。同样，粉丝列表也只有两种状态。

　　看别人的关注，粉丝列表：

　　这是最复杂的情况，假如看别人关注列表，列表里的人和自己可能有上述全部四种关系状态。

　　从集合的图来分析

　　如上图所示。左边的圆表示用户的关注列表，右边的圆表示粉丝列表，下边的圆表示的是要查看的列表(集合)。分别用follow,fans,find来表明这三个集合。

　　当查看自己的列表时，其实表示find集合是上面集合中某一个的子集。例如查看自己粉丝，表示find是fans的子集，查看自己的关注，表示find是follow的子集。

　　查看别人的列表时，此时图中产生了三个集合的交集。要查询集合中的用户可能是在你的粉丝，关注集合中，也可能不在。就是说可能是任何一种关系状态，问题的根本就是，我们要计算出每一个用户与当前用户的关系状态。要求解四种关系状态，我们必然要求出图中下部分的三个小交集。

　　1.要查询的集合与我的互粉交集

　　2.要查询的集合与我的关注交集

　　3.要查询的集的与我的粉丝交集

　　不在这三个小交集中的用户就是无关系状态的用户。

　　假如我们采用如下一套命名:

　　关注集合

　　follow:userID粉丝集合fans:userID

　　互粉集合(临时)

　　fofa:userID要查询的集合(临时)find:userID

　　要查询的集合与我的关注交集(临时)

　　find_inter_follow:userID要查询的集的与我的粉丝交集(临时)find_inter_fans:userID

　　要查询的集合与我的互粉交集(临时)

　　find_inter_fofa:userID

　　find中其他就是未关注

　　使用Sorted Set存储关系

　　score用来存储关注的时间，每个用户存储两个集合。follow:userID存储用户的关注，fans:userID存储用户的粉丝。于是我们可以设计一个函数来求出这些状态的集合。

　　函数返回：

　　求出以上四个集合，就可以进行关系状态判断，先判断是否互粉，如果不是互粉，再判断是否是我关注的，如果不是，再判断是否是我的粉丝。如果都不是就是无关系。这样就能把状态求出来了。

　　以上函数已经求出了所需要的集合，然后就是关系状态判断了。

　　小编结语：

      更多内容尽在课课家教育！