Twitter 如何使用 Redis 提高可伸缩性

最近，Twitter Cache 团队的工程师 Yu Yao 在 Youtube 发表了一段演讲，介绍了 Twitter 如何使用 Redis 提高系统可伸缩性。High Scalability对这段演讲进行了整理和总结。

Yu Yao 首先解释了为什么 Twitter Cache 团队选择了 Redis，而不是 Memcache。原因在于 Twitter 对网络带宽以及长通用前缀（Long Common Prefix）在使用效率上的考虑。Twitter 主要将 Redis 用于 timeline 服务，而针对这方面的功能，Redis 的表现要优于 Memcache。对于长通用前缀问题，Yu Yao 则谈到 Twitter 处理数据的两种场景：

数据格式需要采用灵活的样式。一个对象拥有确定的属性，但该属性可能存在，也可能不存在。每一个单独的属性需要建立单独的键。这就要求为每个单独的属性发送单独的请求，而在缓存中，可能并不存在所有的属性。 随时间变化所能观察到的度量值样本具有相同的名称，但却具有不同的时间戳。如果要单独存储每个度量值，就可能导致冗长的通用前缀会被存储多次。

针对度量值与灵活样式这两种场景，都需要更多空间。为提高空间的有效性，就需要具有分层的键空间。

根据业务需要，Twitter 为 Redis 增加了两种数据结构：Hybrid List 与 BTree。针对 List 类型，Redis 自身只支持 ziplist 与 linklist。前者对空间的利用更好，后者则更加灵活。因而在不同的场景下，两种 List 类型表现各有利弊。例如当数据量巨大时，ziplist 在添加或删除元素的性能方面表现得不如人意；而 linklist 由于为每个 key 提供了两个指针，就可以更加高效地添加或删除元素，遗憾的是，多余的指针又会带来空间的浪费。由于 Twitter Timeline 数据量非常大，且经常需要对其数据进行写操作，Redis 提供的这两种 List 都不适合。为了鱼和熊掌兼得，Twitter 引入了 Hybrid List。它通过综合 ziplist 和 linklist 的特性，解决了这个问题。本质上，Hybrid List 就是一个存储了多个 ziplist 的 linklist。

引入 BTree 则是为了更好地支持对分级 Key 的区间查询（Range Query）。在 Redis 中，处理二级键（Secondary Key）或二级域（Secondary Field）的方式是使用 hash map。之所以要存储排序后的数据，就是为了更好地执行区间查询。如果二级键或名称无法排序，且数据量较大时，查询就变成了线性的，效率较低。BTree 正是为了解决此问题，它借鉴了 BTree 的伯克利算法，在分级 key 的区间查询方面具有更好的性能。

Yu Yao 在演讲中还谈到了 Twitter 如何对 Redis 集群进行管理，并从数据角度对 Redis 进行了评价。最后，她总结了 Twitter 在这方面的收获与体会：

• 需要预测规模的需求。如果集群越大，客户越多，就越需要进行预测。
• 长尾延迟问题（Tail Latencies Matter）。如果存在多个分区，当其中一个变慢，则整个查询也会变慢。
• 明确的配置对于运维非常重要。Twitter 使用 Mesos 作为 Job Scheduler，对 CPU、内存等资源的管理与监控有助于更好的运维。
• 知道运行时的资源使用状况将大有裨益。
• 将计算推送到数据端。
• Redis 会成为下一个高性能的流处理平台。

感谢郭蕾对本文的审校和策划。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。