业界时评 | 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会成为下一个高性能的流处理平台。