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

---

Yu Yao首先解釋了為什麼TwitterCache團隊選擇了Redis，而不是Memcache。原因在於Twitter對網路頻寬以及長通用字首（Long CommonPrefix）在使用效率上的考慮。Twitter主要將Redis用於timeline服務，而針對這方面的功能，Redis的表現要優於Memcache。對於長通用字首問題，Yu Yao則談到Twitter處理資料的兩種場景：

資料格式需要採用靈活的樣式。一個物件擁有確定的屬性，但該屬性可能存在，也可能不存在。每一個單獨的屬性需要建立單獨的鍵。這就要求為每個單獨的屬性傳送單獨的請求，而在快取中，可能並不存在所有的屬性。 
隨時間變化所能觀察到的度量值樣本具有相同的名稱，但卻具有不同的時間戳。如果要單獨儲存每個度量值，就可能導致冗長的通用字首會被儲存多次。
針對度量值與靈活樣式這兩種場景，都需要更多空間。為提高空間的有效性，就需要具有分層的鍵空間。

根據業務需要，Twitter為Redis增加了兩種資料結構：HybridList與BTree。針對List型別，Redis自身只支援ziplist與linklist。前者對空間的利用更好，後者則更加靈活。因而在不同的場景下，兩種List型別表現各有利弊。例如當資料量巨大時，ziplist在新增或刪除元素的效能方面表現得不如人意；而linklist由於為每個key提供了兩個指標，就可以更加高效地新增或刪除元素，遺憾的是，多餘的指標又會帶來空間的浪費。

由於TwitterTimeline資料量非常大，且經常需要對其資料進行寫操作，Redis提供的這兩種List都不適合。為了魚和熊掌兼得，Twitter引入了Hybrid List。它通過綜合ziplist 和linklist的特性，解決了這個問題。本質上，HybridList就是一個儲存了多個ziplist的linklist。

引入BTree則是為了更好地支援對分級Key的區間查詢（Range Query）。在Redis中，處理二級鍵（SecondaryKey）或二級域（Secondary Field）的方式是使用hashmap。之所以要儲存排序後的資料，就是為了更好地執行區間查詢。如果二級鍵或名稱無法排序，且資料量較大時，查詢就變成了線性的，效率較低。BTree正是為了解決此問題，它借鑑了BTree的伯克利演算法，在分級key的區間查詢方面具有更好的效能。

Yu Yao在演講中還談到了Twitter如何對Redis叢集進行管理，並從資料角度對Redis進行了評價。最後，她總結了Twitter在這方面的收穫與體會：

• 需要預測規模的需求。如果叢集越大，客戶越多，就越需要進行預測。
• 長尾延遲問題（Tail Latencies Matter）。如果存在多個分割槽，當其中一個變慢，則整個查詢也會變慢。
• 明確的配置對於運維非常重要。Twitter使用Mesos作為Job Scheduler，對CPU、記憶體等資源的管理與監控有助於更好的運維。
• 知道執行時的資源使用狀況將大有裨益。
• 將計算推送到資料端。
• Redis會成為下一個高效能的流處理平臺。