微博关系服务与Redis的故事

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

　　风起

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

　　业务方存在两种查询：

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

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

　　云涌

　　2011年微博进行平台化改造过程中，业务提出了新的需求：在核心接口中增加了“判断两个用户的关系”的步骤，并增加了“双向关注”的概念。因此两个用户的关系存在四种状态：关注，粉丝，双向关注和无任何关系。为了高效的实现这个需求，平台引入了 Redis 来存储关系。平台使用 Redis 的 hash 来存储关系：key 依然是 uid.suffix，关注列表，粉丝列表及双向关注列表各自有一个不同的 suffix，value 是一个hash，field 是 touid，value 是 addTime。order by addTime 的功能则由 Service 内部 sort 实现。部分大V的粉丝列表可能很长，与产品人员的沟通协商后，将存储限定为“最新的5000个粉丝列表”。

微博关系存储Redis结构

需求实现：

• 查询用户关注列表：hgetAll uid.following ，then sort
• 查询用户粉丝列表：hgetAll uid.follower，then sort
• 查询用户双向关注列表：hgetAll uid.bifollow，then sort
• 判断两个用户关系：hget uidA.following uidB && hget uidB.following uidA

　　后来又增加了几个更复杂的需求：“我与他的共同关注列表”、“我关注的人里谁关注了他”等等，就不展开来讲了。

　　平台在刚引入 Redis 的一段时间里踩了不少坑，举几个例子：

• 运维工具和流程从零开始做，运维成熟的速度赶不上业务增长的速度：在还没来得及安排性能调优的工作，fd 已经达到默认配置的上限了，最后我们只能趁凌晨业务低峰期重启 Redis 集群，以便设置新的 ulimit 参数
• 平台最开始使用的 Redis 版本是 2.0，因为 Redis 代码足够简单，从引入到微博起，我们就开始对其进行了定制化开发，从主从复制，到写磁盘限速，再到内存管理，都进行了定制。导致的结果是，有一段时间，微博的线上存在超过5种不同的 Redis 修改版，对于运维，bugfix，升级都带来了巨大的麻烦。后来由田风军 @果爸果爸 为内部 Redis 版本提供了不停机升级功能后，才慢慢好转。
• 平台有一个业务曾经使用了非默认 db ，后来费了好大力气去做迁移
• 平台还有一个业务需要定期对数据进行 flush db ，以腾出空间存储最新数据。为了避免在 flush db 阶段影响线上业务，我们从 client 到 server 都做了大量的修改。
• 平台每年长假前都会做一些线上业务排查，和故障模拟（2013年甚至做了一个名叫 Touchstone 的容灾压测系统）。2011年十一假前，我们用 iptables 将 Redis 端口的所有包都 drop 掉，结果 client 端等了 120 秒才返回。于是我们在放假前熬夜加班给 client 添加超时检测功能，但真正上线还是等到了假期回来后。