微信号:infoqchina

介绍:有内容的技术社区媒体

【实战】Twitter如何使用Redis提高可伸缩性

2014-09-16 10:20 InfoQ

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

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

数据格式需要采用灵活的样式。一个对象拥有确定的属性,但该属性可能存在,也可能不存在。每一个单独的属性需要建立单独的键。这就要求为每个单独的属性发送单独的请求,而在缓存中,可能并不存在所有的属性。

随时间变化所能观察到的度量值样本具有相同的名称,但却具有不同的时间戳。如果要单独存储每个度量值,就可能导致冗长的通用前缀会被存储多次。

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

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

引入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 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 R语言入门第五讲:使用matrix创建矩阵 “全栈这个概念坑害了多少开发者 40+个对初学者非常有用的PHP技巧(二) Devops2.0工具集黑宝书-读书笔记之5-实施部署流水线-初始化阶段P1 [知乎]想走网络安全这条路,大学期间,应注意哪些方面的学习?