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

  • 张逸

2014 年 9 月 15 日

话题:语言 & 开发架构

最近,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)关注我们,并与我们的编辑和其他读者朋友交流。

语言 & 开发架构