破茧对于微博关系服务，最大的挑战还是容量和访问量的快速增长，这给我们的 Redis 方案带来了不少的麻烦： 第一个碰到的麻烦是 Redis 的 hgetAll 在 hash size 较大的场景下慢请求比例较高。我们调整了 hash-max-zip-size，节约了1/3的内存，但对业务整体性能的提升有限。最后，我们不得不在 Redis 前面又挡了一层 memcache，用来抗 hgetAll 读的问题。 第二个麻烦是新上的需求：“我关注的人里谁关注了他”，由于用户的粉丝列表可能不全，在这种情况下就不能用关注列表与粉丝列表求交集的方式来计算结果，只能降级到需求的字面描述步骤：取我的关注人列表，然后逐个判断这些人里谁关注了他。client 端分批并行发起请求，还好 Redis 的单个关系判断非常快。 第三个麻烦，也是最大的麻烦，就是容量增长的问题了。最初的设计方案，按 uid hash 成 16 个端口，每台 64G 内存的机器上部署 2 个端口，每个业务 IDC 机房部署一套。后来，每台机器上就只部署一个端口了。再后来，128G 内存的机器还没有进入公司采购目录，64G 内存就即将 OOM 了，所以我们不得不做了一次端口扩容：16端口拆64端口，依然是每台 64G 内存机器上部署 2 个端口。再后来，又只部署一个端口。再后来，升级到 128G 内存机器。再后来，128G 机器上出现 OOM 了！现在怎么办？ 化蝶为了从根本上解决容量的问题，我们开始寻找一种本质的解决方案。最初选择引入 Redis 作为一个 storage，是因为用户关系判断功能请求的数据热点不是很集中，长尾效果明显，cache miss 可能会影响核心接口性能，而保证一个可接受的 cache 命中率，耗费的内存与 storage 差别不大。但微博经过了 3 年的演化，最初作为选择依据的那些假设前提，数据指标都已经发生了变化：随着用户基数的增大，冷用户的绝对数量也在增大；Redis 作为存储，为了数据可靠性必须开启 rdb 和 aof，而这会导致业务只能使用一半的机器内存；Redis hash 存储效率太低，特别是与内部极度优化过的 RedisCounter 对比。种种因素加在一起，最终确定下来的方向就是：将 Redis 在这里的 storage 角色降低为 cache 角色。 前面提到的微博关系服务当前的业务场景，可以归纳为两类：一类是取列表，一类是判断元素在集合中是否存在，而且是批量的。即使是 Redis 作为 storage 的时代，取列表都要依赖前面的 memcache 帮忙抗，那么作为 cache 方案，取列表就全部由 memcache 代劳了。批量判断元素在集合中是否存在，redis hash 依然是最佳的数据结构，但存在两个问题：cache miss 的时候，从 db 中获取数据后，set cache 性能太差：对于那些关注了 3000 人的微博会员们，set cache 偶尔耗时可达到 10ms 左右，这对于单线程的 Redis 来说是致命的，意味着这 10ms 内，这个端口无法提供任何其它的服务。另一个问题是 Redis hash 的内存使用效率太低，对于目标的 cache 命中率来说，需要的 cache 容量还是太大。于是，我们又祭出 “Redis定制化”的法宝：将 redis hash 替换成一个“固定长度开放hash寻址数组”，在 Redis 看来就是一个 byte 数组，set cache 只需要一次 redis set。通过精心选择的 hash 算法及数组填充率，能做到批量判断元素是否存在的性能与原生的 redis hash 相当。 通过微博关系服务 Redis storage 的 cache 化改造，我们将这里的 Redis 内存占用降低了一个数量级。它可能会失去“最大的单个业务Redis集群”的头衔，但我们比以前更有成就感，更快乐了。 作者简介唐福林（@唐福林），微博技术委员会成员，微博平台资深架 构师，致力于高性能高可用互联网服务开发，及高效率团队建设。从2010年开始深度参与微博平台的建设，目前工作重心为微博服务在无线环境下 的端到端全链路优化。业余时间他是一个一岁女孩的爸爸，最擅长以45°凉开水冲泡奶粉。 感谢张龙对本文的审校。 |
