# Tumblr：哈希處理每秒 23,000 個博客請求的方式 > 原文： [http://highscalability.com/blog/2014/8/4/tumblr-hashing-your-way-to-handling-23000-blog-requests-per.html](http://highscalability.com/blog/2014/8/4/tumblr-hashing-your-way-to-handling-23000-blog-requests-per.html)  *這是 Tumblr 的 SRE 工程師 [](http://michael.tumblr.com/) [Michael Schenck](http://michael.tumblr.com/) 的特邀帖子。* 在 Tumblr，博客（或 Tumblelog）是我們互聯網上訪問量最高的面孔之一。 tumblelogs 最方便的方面之一是其高度可緩存的特性，這是奇妙的，因為 Tumblr 網絡為我們的用戶提供了很高的視圖/發布比率。 就是說，擴展邊界代理層（更不用說緩存層）對滿足所有這些請求是必需的，這并非完全簡單。 本文介紹了負責博客服務的外圍部分的體系結構，這是我們流量更大的外圍端點之一。 這是我們的方法。 ### 統計信息 * 共有 278 名員工，團隊中有 6 名員工負責 Tumblr 的所有外圍（Perimeter-SRE），包括一名經理。 * 超過 2800 臺服務器中，不到 20％的服務器用于博客服務功能 * 每秒（峰值）超過 23,000 個博客請求 * 每秒（峰值）超過 6,500 個博客緩存清除事件 * 超過 1.96 億個博客 * 超過 930 億個帖子 ### 平臺 * [HAProxy](http://www.haproxy.org/) * [清漆](https://www.varnish-cache.org/) * [鳥](http://bird.network.cz/) ### 我們在哪里-基于地圖的分區 在早期，我們只需要一臺活動和一臺備用代理服務器以及清漆節點。 兩者都很容易管理，監視和高度可用。 但是，由于要滿足所有用戶請求，因此將達到容量限制，并且由于流行而導致停機前，必須準備好下一步步驟（即使不是理想的部署）。 ### 超出單個代理節點 超出單個 活動 代理服務器的數量非常普遍，并且通常涉及 DNS。 像循環 A 記錄這樣基本的東西可能會滿足您的需求，但通常值得花額外的錢進行健康檢查 GSLB 配置（即使您只有一個地理位置）。 DNS 的缺點是，盡管名稱服務器將以相當均勻的速率對每個 IP 進行響應，但不能保證每個查找都將用于相同數量的請求。 用戶 A 可能在一分鐘內向解析的 IP 發出 10 個請求，而機器人 B 可能在同一分鐘內發出 100 個請求。 如果您有兩個 IP，則用戶 A 獲得一個 IP，而機器人 B 獲得另一個 IP，而它們是僅有的兩個發出請求的客戶端，那么您的一個代理的請求速率是另一個的 10 倍。 較低的 TTL 可以減輕此影響，以便 30 秒 TTL 可以平衡兩個代理之間的那 110 個請求。 在最初的 30 秒內，用戶 A 將轉到代理 P1，而機器人 B 將轉到代理 P2。 然后，他們的下一個解決方案可能會交換 IP，以便用戶 A 將其請求發送到代理 P2，而機器人 B 將其請求發送到代理 P1。 在該分鐘窗口結束時，每個代理將處理大約 60 個請求。 TTL 較低的缺點是查找更多，因此 DNS 成本較高（但 DNS 通常是您較便宜的第三方服務之一）。 ### 超出單個清漆節點 雖然 DNS 可以為您增加代理層的時間，但是縮放清漆要復雜一些。 即使您使用單個清漆節點的容量限制圍繞請求并發進行，您也不希望簡單地在循環中添加兩個清漆節點。 這降低了緩存命中率，清除了更多的資源/時間，并且實際上并沒有增加緩存的工作量（僅復制它）。 超出單個清漆節點的最簡單迭代是 靜態分區 。 這涉及確定您的唯一標識符，并在兩個清漆節點之間劃分此空間。 對于 Tumblelogs，這是博客的主機名。 由于 DNS 不區分大小寫，因此您只需要擔心 40 個字符即可。 字母數字（a-z 和 0-9）和四個允許的字符（-_。?）。 因此，對于兩個清漆節點，博客主機名在這兩個緩存節點之間被分割（在第一個字符上）。 ### 均勻分布的分區-通過一致的哈希 前面的兩個示例（DNS 循環和靜態分區）都是朝著正確方向邁出的一步，但是在分區方面卻提供了非常粗糙的粒度。 在足夠小的規模上，這種粒度不一定是有問題的，但是隨著您的流量開始增長，方差變得更加明顯。 結果，減少最不熱和最熱節點處理的流量差異變得越來越重要。 這就是一致性哈希真正可以發揮作用的地方。 ### 分區代理流量 如果您的服務器所處的環境可以影響服務器前面的路由器，用戶和代理服務器之間的路由器的路由表，那么您可以利用等價的多 -路徑路由（ECMP）。 ECMP 使您能夠將代理視為同一哈希環中的多個切片，然后在這些切片之間映射請求者。 這是通過通知到特定目標 IP（高可用性 IP）的多個路徑（代理服務器）的路由基礎結構來實現的。 然后，ECMP 將對請求源進行哈希處理，以確定哪個代理應接收此請求會話的數據包。 典型的 ECMP 實現提供第 3 層（僅 IP）和第 3 + 4 層（IP：端口）哈希選項。 第 3 層意味著來自特定 IP 的所有請求將轉到特定的代理，這可能有助于調試，但與使用單個 NAT IP 的大型網絡不平衡。 第 3 + 4 層通常提供最佳的分發，但是調試特定的客戶端變得更具挑戰性。 有多種方法可以 通知 路由器多個路徑，但是我建議使用 OSPF 或 iBGP 進行動態路由通告。 一個人只需要在環回接口上偵聽高度可用的 IP，啟用內部路由以及將自己的 IP 作為下一躍點廣告到該高度可用的 IP。 我們發現 BIRD 提供了一種輕巧可靠的方式來執行來自代理的路由廣告。 ### 劃分清漆流量 Tumblelog 通過其完全限定的域名（FQDN）進行標識，因此，博客的所有 URI 路徑將始終在該博客 FQDN 下找到。 Tumblelog 的大部分是 tumblr.com 的子域，例如 [engineering.tumblr.com](http://engineering.tumblr.com/) ，但是我們也支持用戶攜帶自己的自定義域名 。 考慮各種 FQDN 時，很明顯，TLD 的變體數量最少，然后是域名（特別是由于絕大多數是 tumblr.com），然后是子域。 因此，我們最重要的位出現在可變長度字符串的最左側。 ### 了解問題域  * 完美-演示將散列函數應用于我們的測試數據集時，其散列函數是否為 完美 * constant_hdr-主機標頭上的一致性哈希（最佳現實結果） * constant_hdr_use_domain_only-基本域名（即 tumblr.com 或 foo.net）上的一致性哈希，只有兩個陣營 tumblr.com 和所有其他域名 * mapbased_firstchar-將主機標頭的第一個字符映射到清漆節點（我們的原始靜態分區實現） * mapbased_hdr-基于主機標頭的映射 雖然一致的散列顯然是 tumblelog FQDN 的最平均分布的領先者，但是我們接著確定散列函數是否合適。 默認情況下，HAProxy 使用 SDBM 哈希函數。 但是，在進一步研究后，通過比較 SDBM，CRC，MD5，DJB2 等，我們確定 DJB2 提供了更好的分布。 這導致我們向 HAProxy 提交了補丁，以使哈希函數可配置（有關更多信息，請參見“感謝”部分）。 ### 比較靜態分區和一致性哈希  這顯示了在移至最佳匹配哈希函數之前和之后，每個清漆節點每秒請求之間的方差變化。 ### 其他注意事項 ### 節點增長 在任一模型中，節點增長將意味著鍵空間移位，從而導致緩存失效。 在一致的哈希模型中，預測將失效的鍵的百分比要容易得多。 基本上為 1 / N（N 是添加新節點之前的緩存節點數）。 使用靜態分區模型，除非您對要從中獲取鍵空間的節點的請求進行分析，否則最糟糕的情況是小于或等于鍵上鍵的總百分比。 您從中獲取鍵空間的節點。 ### 節點故障 使用靜態分區時，除非您提供故障轉移選項，否則單節點故障將導致無法訪問 1 / N 密鑰。 HAProxy 確實允許您擁有一個備用節點，但是現在您可以決定了。 每個密鑰空間有 2N 個緩存節點（一個活動，一個備用）或共享的備用節點。 一種極端情況是 浪費 占硬件的 50％，其中頻譜的另一端（所有活動節點之間共享 1 個備用節點）意味著兩個故障節點導致備用 支持其他活動節點的密鑰空間的 2 倍。 使用一致的哈希，將自動處理節點故障。 刪除一個節點后，將移動 1 / N 個鍵（導致 1 / N 個鍵無效），并且每個剩余的活動節點的鍵空間均勻增加。 ### 正在清除緩存 將清除請求發送到單個清漆節點很容易，但是從多個清漆節點清除也應該很容易。 不必使代理服務器和清除服務器保持同步，最簡單的方法是通過同一代理服務器發送所有清除請求。 拒絕來自非本地 IP 空間的清除嘗試非常重要，以防止任何惡意的批量清除。 ### 獲得的經驗教訓 * 您知道尚未回答的問題的答案。 面對擴展挑戰時，請不要忽視您已經在其他地方使用的模式。 * 通過簡單擴展。 在短期內可能會增加復雜性以克服可伸縮性挑戰，但最終會趕上您。 * 了解您的哈希函數。 您使用的哈希函數與決定如何處理哈希值同樣重要。 * 降級，不失敗。 建議您的代理人監視自己達到后端的能力。 如果不能，則不要停止發布路由，而只是發布非優先級路由（例如，使用 OSPF 會增加路徑成本）。 這樣，如果所有后端都無法正常運行，您仍然可以提供錯誤頁面，而不是無法訪問。 ### 謝謝 ## * [Blake Matheny](http://tumblr.mobocracy.net/) 和 [Andrew Terng](http://andrew.tumblr.com/) 進行了散列函數比較并為 HAProxy 創建了補丁。 * [Bhaskar Maddala](http://maddalab.tumblr.com/) 與 HAProxy 社區合作，以獲取 [此功能已添加到 HAProxy 1.5 版本](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-hash-type) 。 * [Arnoud Vermeer](http://blog.arnoudvermeer.nl/) 和 [Aaron Prat](http://aaronprat.tumblr.com/) 與 ECMP / OSPF 流量分配有關。 ## 相關文章 [ * [關于 HackerNews](https://news.ycombinator.com/item?id=8132473) * [雅虎以 10 億美元的價格收購了 Tumblr 架構](http://highscalability.com/blog/2013/5/20/the-tumblr-architecture-yahoo-bought-for-a-cool-billion-doll.html) * [Tumblr Architecture-150 億頁面瀏覽量一個月，比 Twitter 難擴展](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) 對于任何混亂，我們深表歉意，共有 278 位 Tumblr 員工。 負責 Tumblr 所有外圍（Perimeter-SRE）的團隊由 6 人組成（包括一名經理）。 本文介紹了負責博客服務的外圍部分的體系結構，這是我們流量更大的外圍端點之一。 對于那些不了解哈希的人來說，它會使您變得 O（1）復雜，并且比對普通 b 樹數據庫的搜索要快。 令人驚訝的結果，我想這就是您擴展 tumblr 之類的方式的原因：） 非常有趣的文章。 但是有一個問題：您提到 BIRT 是 IP 平衡器，盡管 Haproxy 也是平衡器，但是對于 TCP / HTTP 級別，不是 IP。 那么負載均衡人員到底是誰呢？ 感謝您分享這個幕后或“后臺”視圖。 “ 1.96 億個博客”數量巨大，接近 1000 億個帖子表明這些博客已被實際使用，而不是像其他平臺那樣，通常一旦注冊就此后一直處于閑置狀態。 從網絡工程的角度來看，這非常有趣。 我猜想您的 HAProxy 框上正在運行 BIRD，然后將散列的流量平衡到 Varnish？ 是否還可以通過 Varnish 服務器從您的邊緣路由器提供網絡圖？ 謝謝！