輕博客始祖Tumblr：哈希以支撐2.3萬Blog請求/秒

【編者按】Tumblr是目前全球最大的輕博客網站，也是輕博客網站的始祖。當下已有超過1.96億博客，930億帖子，每秒2萬3千請求。近日，該公司網站可靠性工程師Michael Schenck在HighScalablity上公布了其架構設計。

免費訂閱“CSDN大數據”微信公眾號，實時了解最新的大數據進展！

CSDN大數據，專注大數據資訊、技術和經驗的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機器學習、智能算法等相關大數據觀點，大數據技術，大數據平臺，大數據實踐，大數據產業資訊等服務。

以下為譯文

在Tumblr，blog是網站流量最大的一部分。而在tumblelogs中，高度可緩沖成為一個非常重要的特性。鑒于Tumblr支撐的高views/post比率，做到這一點并不容易，下面一起看向blog支撐部分的架構。

狀態

• 278個員工，6個人負責Tumblr的perimeter（Perimeter-SRE），包括一個manager。 
• 超過2800臺服務器，不到20%用于blog支撐
• 峰值期間每秒2.3萬blog請求
• 峰值期間每秒6500個blog緩存清理
• 超過1.96億blog
• 超過930億post

平臺

• HAProxy
• Varnish
• Bird

曾經架構――基于映射的分割

早期，Tumblr運行在一個非常小的規模――1活躍加1備用的proxy 服務器，以及同樣配置的varnish節點。這種規模的Tumblr非常易于管理、監控，服務的可用性也非常高。然而不久后，Tumblr就不得不瘋狂的擴展以應對用戶暴增可能帶來的容量限制。

添加1個獨立的proxy節點

添加一個獨立的proxy服務器非常普遍，同時還涉及了DNS。通常情況下，類似Round-Robin A Record這些基礎的東西可能就會滿足需求，但是很多情況下，一個健康檢查GSLB配置同樣值得你投入，即使是在同一個地理位置下。

DNS的缺點是，域名服務器會以一個恒定的速率對每個IP做出響應，然而問題在于并不能保證每個查找都用于相同數量的請求。在1分鐘內，用戶A對一個Resolved IP進行的請求可能是10次，而用戶B可能會達到100次。如果你有兩個IP，A和B分別使用1個，假設只有這兩個用戶訪問，那么一個proxy 服務器的請求速度可能是另外一個的十倍。

這個問題可以通過Lower TTL來解決，比如一個30 second TTL可以將請求在這兩個proxy 間平衡。在前30秒，A被送到P1，B被送到P2，而在后30秒可能就會置換，在最后每個proxy 服務器處理都會處理大約60個請求左右。Lower TTL的缺點在于會造成更多的查詢，因此會帶來更多的DNS開銷。但是值得慶幸的是，DNS基本上是開銷最低的第三方服務。

添加1個獨立的 varnish節點

當DNS給你帶來更多proxy層上的空間時，varnish的擴展往往會復雜一點。盡管你困擾于并發請求帶來的單varnish節點容量限制，但是簡單添加1個varnish節點并不能達到你的預期需求。這個操作可能會降低cache-hit比率，讓清理在resource/time上更加密集，并不能真正的增加你的緩存容量。

迭代單varnish節點最簡單的方法就是靜態分割，這包括確定你的唯一識別符，并將這些空間在兩個節點中分割。對Tumblelogs來說，這就是blog的主機名稱。鑒于DNS區分大小寫，你只需考慮40個字符，字母數字“a-z”、“0-9”以及“-”、“_”、“.”、“~”4個字符。因此對于兩個varnish節點，blog主機名稱根據首字母在兩個緩存節點中分割。

均勻的分布式分割――通過一致性哈希

前面的兩個例子（DNS round-robin和靜態分割）雖然想法是正確的，但是并未做一個細粒度的分割。在小規模下，這種粒度可能并不會帶來問題。但是隨著流量的增長，差異性逐漸的造成問題。減少least-hot 和most-hot節點間差異至關重要，這里就有了一致性哈希的用武之地。

分割proxy流量

如果你的服務器環境滿足這個條件，即可以改變路由器（建立于用戶和proxy服務器之間）的路由表，那么你可以利用其ECMP的優勢。ECMP可以在一致性哈希環中將proxy分割，然后將請求者們映射到這些分割后的碎片上。通過將多路徑（proxy服務器）路由基礎設施發送給一個特定的IP（高可用IP）來實現這個操作，在這里，ECMP將哈希請求源以確定哪個proxy來接收這個請求會話包。典型的ECMP實現提供了Layer 3 （IP-only）和Layer 3+4（IP:port）哈希選項，Layer 3意味著所有特定IP上的請求都會交由一個制定的proxy，這點非常有利于debug，但是對于使用了單一NAT IP的大型網絡來說并不有利。Layer 3+4則提供了非常經典的分布式特性，但是debug指定客戶端變得非常有挑戰。

這里有非常多的方法來INFORM多路徑路由器，然而我們更推薦使用OSPF或者iBGP來做動態route advertisements。一個只需要監視loopback interface上的高可用IP，允許內部路由，并將其IP作為一個next-hop advertise給高可用IP。同時我們還發現，BIRD是proxy服務器執行route advertisements的一個輕量級及可靠手段。

分割Varnish流量

Tumblelogs由它們FQDN的識別，例如一個blog的所有URI路徑都會在這個blog的FQDN下發現。絕大多數的Tumblelogs都是tumblr.com的子域，比如engineering.tumblr.com，但是Tumblr也允許用戶自定義域名。

當著眼格式的 FQDN時，TLD在最小變化上有著絕對的優勢，然后就是域名，子域名。因此，大部分的有效位都在域名最左端。

理解問題域

• 追求完美――在測試數據集上尋求最完美的哈希
• consistent_hdr――在主機標識上做一致性哈希（現實示例中最好結果）
• consistent_hdr_use_domain_only――在基域名上做一致性哈希（比如 tumblr.com或foo.net），只存在兩種結果tumblr.com和其他
• mapbased_firstchar――將主機表示的第一個字母映射給varnish節點，這也是我們最原始的靜態分割實現
• mapbased_hdr――主語主機表示映射

當一致性哈希被確立為最適合方案時，我們開始聚焦哈希函數是否合適。HAProxy默認使用的是SDBM哈希函數，然而在更深入的調查后，對比了SDBM、CRC、MD5、DJB2等，我們發現DJB2提供了更好的分布。

對比靜態分割和一致性哈希

上圖顯示了每個varnish節點上的變化，對比了使用最佳哈希函數前后

附加思考

節點增長

在這兩種模型中，節點增長都意味著keyspace轉移，因此緩存失效。在一致性哈希模型中，失效key所占的比率更加容易預測。在靜態分割模型中，除下做很具體的統計，很難預測到這個百分比。

節點故障

通過靜態分割，單點故障將導致 1/N的key無法訪問，除非你提供一個故障轉移機制。HAProxy確實允許你擁有一個備份節點，因此你需要做出決策，是否要為每個key space都做活躍和備份緩存節點設置，或者共享一個備份節點。一個極端意味著你將浪費50%的硬件，另一個（共享備用節點）則意味著兩個故障節點就需要備用節點支撐活躍節點的2倍keyspace。

通過一致性哈希，節點故障被自動處理。當一個節點被移除后，那么1/N的key會被轉移同時無效，然后把這些分配到剩余的活躍幾點上。

清理緩存

清理請求可以很簡單的發送到單獨的varnish節點上，那么從多個varnish節點上的清理應該同樣簡單。取代謹慎的保持proxy和清理同步，將所有清理請求發送到相同的proxy顯然更加簡單。同時，需要注意的是，拒絕不同IP空間上的清理請求非常重要，這可以防止惡意的批量清理。

學到的知識

• 有時候，問題的答案比你問題出現的更早。當面對一些擴展性挑戰時，不要在那些已經在其他地方攻克過的問題上浪費時間。
• 保持簡單。通過復雜性來解決擴展性問題必然深受其害。
• 理解你的哈希函數。哈希函數的選擇同樣至關重要。
• Degrade，not fail。讓proxy具備監視自己后端到達情況的能力非常必要。如果出現異常，不要停止advertise路由，繼續advertise非優先級路由。這種情況下，如果你所有的后端都出了問題，那么你仍然可以顯示錯誤頁面。

推薦閱讀

• Blake Mathenyand Andrew Terngfor their hash function comparisons and creating the patch to HAProxy.

• Bhaskar Maddalafor working with the HAProxy community to get this functionality added to the HAProxy 1.5 release.

• Arnoud Vermeerand Aaron Pratfor their work with ECMP/OSPF traffic distribution.

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈