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

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

免費(fèi)訂閱“CSDN大數(shù)據(jù)”微信公眾號，實(shí)時了解最新的大數(shù)據(jù)進(jìn)展！

CSDN大數(shù)據(jù)，專注大數(shù)據(jù)資訊、技術(shù)和經(jīng)驗(yàn)的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機(jī)器學(xué)習(xí)、智能算法等相關(guān)大數(shù)據(jù)觀點(diǎn)，大數(shù)據(jù)技術(shù)，大數(shù)據(jù)平臺，大數(shù)據(jù)實(shí)踐，大數(shù)據(jù)產(chǎn)業(yè)資訊等服務(wù)。

以下為譯文

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

狀態(tài)

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

平臺

• HAProxy
• Varnish
• Bird

曾經(jīng)架構(gòu)――基于映射的分割

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

添加1個獨(dú)立的proxy節(jié)點(diǎn)

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

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

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

添加1個獨(dú)立的 varnish節(jié)點(diǎn)

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

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

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

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

分割proxy流量

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

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

分割Varnish流量

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

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

理解問題域

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

當(dāng)一致性哈希被確立為最適合方案時，我們開始聚焦哈希函數(shù)是否合適。HAProxy默認(rèn)使用的是SDBM哈希函數(shù)，然而在更深入的調(diào)查后，對比了SDBM、CRC、MD5、DJB2等，我們發(fā)現(xiàn)DJB2提供了更好的分布。

對比靜態(tài)分割和一致性哈希

上圖顯示了每個varnish節(jié)點(diǎn)上的變化，對比了使用最佳哈希函數(shù)前后

附加思考

節(jié)點(diǎn)增長

在這兩種模型中，節(jié)點(diǎn)增長都意味著keyspace轉(zhuǎn)移，因此緩存失效。在一致性哈希模型中，失效key所占的比率更加容易預(yù)測。在靜態(tài)分割模型中，除下做很具體的統(tǒng)計，很難預(yù)測到這個百分比。

節(jié)點(diǎn)故障

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

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

清理緩存

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

學(xué)到的知識

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

推薦閱讀

• 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.

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈