# 一點點：建立一個可處理每月 60 億次點擊的分布式系統的經驗教訓 > 原文： [http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html](http://highscalability.com/blog/2014/7/14/bitly-lessons-learned-building-a-distributed-system-that-han.html)  您是否想知道 [有點](http://bitly.is/1g3AhR6) 賺錢嗎？ 一個 [URL 縮短器](http://en.wikipedia.org/wiki/URL_shortening) 不會那么難寫，對吧？ bitt 的首席應用開發人員 [Sean O'Connor](http://linkd.in/1nt6KTN) 回答了如何立即在 [中產生一點可賺錢的問題 他在](http://bit.ly/1iuEAlb) [培根會議](http://devslovebacon.com/) 上發表的 演講。 肖恩說，寫一個可行的 URL 縮寫很容易，寫一個可縮放且高度可用的 URL 縮寫并不容易。 Bitly 不會通過“縮短服務”服務獲利，而是在分析產品上獲利，該產品將 URL 點擊數據與他們從網絡上抓取的數據融合在一起，以幫助客戶了解人們在網絡上關注的內容 。 ， Analytics 產品最初是一種用于爬網 Web 服務器日志的后端服務。 日志包含來自帶注釋的鏈接的數據以及 cookie 數據，以指示單擊鏈接的頁面，在何處單擊，鏈接的內容等。但是，所有鏈接都回到了網站的域。 建立鏈接與您的域到另一個域以使第三者可以進行分析的想法是一個可怕的主張，但這也是一種天才。 盡管此話題不是關于尖銳的體系結構的，但它是對分布式系統的性質以及如何解決分布式系統的大難題的有思想的探索。 也許我從他的演講中最喜歡的一課是這個（我的光澤）： **SOA +隊列+異步消息傳遞確實很強大** 。 這種方法可以隔離組件，讓工作同時進行，讓盒子獨立發生故障，同時使組件仍然易于推理。 我也非常喜歡他的解釋，說明為什么事件樣式消息比命令樣式消息更好。 我從來沒有聽過這樣的話。 肖恩（Sean）從真實的經驗談起。 如果您想從單一思維方式轉變為多思維方式，那么此演講非常值得一看。 ， 因此，讓我們看看 Sean 對分布式系統有何感想…… ## 統計信息 * 每月有 60 億點擊 * 6 億個每月縮短 * 公司內 50 名員工和大約 20 名工程師 * 400 臺服務器。 并非所有 400 臺服務器都在處理重定向。 約 30 臺服務器處理來自外界的所有傳入流量，包括縮短，重定向，api 請求，Web ui 等.400 臺服務器的其余部分專用于存儲和組織用戶數據或提供各種形式的處理和分析（數據庫）的各種服務 ，指標，網頁抓取，文本分析等）。 * 每月抓取一億個網頁。 ## 來源 * [經驗教訓，了解建筑物的分布式系統](http://devslovebacon.com/conferences/bacon-2014/talks/lessons-learned-building-distributed-systems-at-bitly) ## 平臺 [ 請注意，這些只是談話中提到的內容，而不是完整的列表。 * HDFS * S3 * Nagios * 實時使用的實時分布式消息系統是 [Nsq](https://github.com/bitly/nsq) 。 * 稍微使用 [主機池](https://github.com/bitly/go-hostpool) 來管理主機池。 * 談話的結尾已結束，但提到使用了很多不同的數據庫。 ， ## 關于分布式系統的性質 * 任何真正高度可用的東西都將被固有地分發。 為了達到一定程度的可用性，您必須具有地域多樣性。 根據定義，如果您在不同區域中具有獨立的操作系統，則必須將其分發。 * 創建分布式系統的舊方法。 創建抽象，讓您假裝實際上沒有分發。 * 例如，NetApp 會產生無限磁盤的錯覺。 * Oracle，是一個高度可用的數據庫，可讓您假裝世界與實際不同。 * 兩者都可以解決實際問題，但是兩者都很昂貴，因此請另辟 different 徑。 * 新方法。 通過接受分布式系統的固有特性來解決問題，并將其內置到它們作為工具提供的抽象中。 * 您對事物的看法發生了重大變化。 由于您的抽象與所構建內容的實際情況更加緊密一致，因此您可以進行更強大的折衷，從而更高效地完成工作。 * 帶有 1x RAM 的 4 盒總是比帶有 4x RAM 的 1 盒便宜。 這意味著分布式系統是擴展和實現高可用性的方法。 * 分布式系統出現問題，因為您要從一臺計算機遷移到 N 臺計算機。 * **組件的并發** 。 機器 A 與機器 B 同時工作。這就是獲得水平縮放的方式。 功能強大，但代價是需要在機器之間進行協調。 例如，在鎖定數據時，使框彼此等待，您將不再并發。 * **缺少全局時鐘** 。 每個盒子的時鐘都不完美。 如果有一臺以上的機器，那么每臺機器都會有自己的時間感。 這意味著無法根據時間對在不同計算機上發生的事件進行排序。 如果事件之間相隔 1 或 2 秒，則他們不知道先發生哪些事件。 * **獨立故障** 。 如果方框 A 失敗，則方框 B 應該繼續工作。 * 有些問題（例如分析）太大，無法在一臺計算機上處??理。 或至少這樣的機器不會在預算內。 ## 實施分布式系統的策略 ### 面向服務的體系結構 沒有一個整體式的應用程序。 網絡上有數十種相互通信的小型服務。 * 這是一種抽象，非常類似于代碼中的功能，但是是系統級的。 * 不必將系統的所有細節都保留在腦海中。 可以只注意 API 邊界和合同。 * 強大的開發和運營能力。 * Bitly 是一家擁有 6 年歷史的公司，并且具有很多代碼。 您無需查看每一行代碼。 您只使用該服務。 * 設計良好的服務僅幾百行代碼。 * 在操作上，很容易確定哪個系統有問題。 然后，您可以深入研究該系統以查找問題。 * 故障現在意味著功能減少而不是停機。 通常，每個服務都旨在回答特定問題。 由于如果其中之一發生故障，它們將完全與自己的持久層隔離，那么唯一丟失的就是回答該問題的能力，但是總體而言，服務仍處于運行狀態。 出現故障的度量系統永遠不會影響 URL 縮短請求。 ， ### 異步消息傳遞 * 發送消息而無需等待回復。 * 真的很容易在組件之間放置隊列。 如果框 A 正在向框 B 發送郵件，并且框 B 出現問題，則框 B 恢復后，這些郵件將排隊并且可以進行處理。 * 處理錯誤的更多選項。 如果包裝盒出現問題，該消息將稍后處理。 方框 A 不必了解或關心方框 B 的麻煩。 * 不利的一面是，將執行的操作更自然地建模為同步請求。 * URL 縮短請求是一個完全同步的過程，因為： * **速度**。 希望盡快返回答復。 例如，不想處理隊列備份。 * **一致性**。 不想將相同的縮寫網址提供給多個用戶。 而是提供一個錯誤而不是一個無效的鏈接。 * 指標系統完全異步。 單擊一個小鏈接后，它會翻譯并通過 HTTP 返回。 有關轉換的數據會彈出到分析和其他下游系統的隊列中。 如果在處理指標方面有一點延遲，那就不是世界末日了。 * 可以將消息視為命令或事件。 * 命令說“做 X”。 * 一個事件說“ X 發生了”。 * 事件比命令更有用。 * **可以更好地隔離系統**。 命令意味著知道誰接收命令，否則將毫無意義。 說了些什么意味著您不必在乎誰在使用消息。 只要宣告發生了 X，其他服務就可以增加統計信息或執行任何操作。 * **事件自然映射為讓多個使用者處理消息**。 將位 URL 解碼為 HTTP 重定向后，會將消息發送到多種服務：將其保存到 HDFS 和 S3 的存檔服務，實時分析服務，長期歷史記錄分析，注釋服務。 解碼服務只需要發布事件，而無需了解下游服務。 下游服務只是收到一個事件，他們不在乎發送方式或發送者。 * **添加新消費者很容易**。 可以創建新服務，并且可以注冊活動，而制作人不知道或不在乎。 服務處理事件的方式的變化同樣也不是生產者所關心的。 生產者和消費者是孤立的，只能通過事件指定的合同進行聯系。 ## 使服務發揮出色 * **在服務**之間使用背壓。 如果某個服務繁忙，則應告知其他請求服務以限制其請求，從而減少它們在出現問題的服務上的負擔。 例如，指數補償。 幫助防止通過系統的級聯錯誤。 還可以幫助系統更快地恢復。 例如，依賴緩存的服務需要一個預熱期，如果請求的服務在預熱期間沒有回退，則數據庫可能會崩潰。 * **繞過故障**。 例如，服務之間的負載平衡。 Bitly 使用 [主機池](https://github.com/bitly/go-hostpool) 管理主機池。 客戶端向主機請求服務。 然后，客戶端會在每個請求上告訴 hostpool 請求是否失敗。 基于此反饋，主機池可以管理主機分配以路由到更健康的主機。 ## 監視 [ * 使用一臺或兩臺服務器，不難知道何時發生故障，但是當您擁有數百臺服務器時，就需要幫助。 * **使用 Nagios 之類的工具檢查服務器運行狀況**。 檢查統計信息，例如“盒子是否在交換？” * **運行完整性檢查**。 例如，服務正在響應，但是返回的數據已損壞。 * **集中記錄**。 之所以重要，是因為您可以跨多個主機檢測故障。 如果一個用戶造成了您所有的錯誤，那么通過在機器之間跳來跳去將很難檢測到。 集中式日志使檢測整體問題變得更加容易，例如所有錯誤都來自一個 ip 地址。 * **人機界面**。 您如何在正確的時間向正確的人獲取正確的信息。 如何從工具中公開信息？ * 例如， Nsq 有一個不錯的管理界面，可提供有關隊列行為的反饋。 這樣您就可以看到隊列正在備份，但這是因為一個主機。 * 部署系統的 Web UI。 使部署和查看部署歷史記錄變得容易。 如果 Nagios 快要瘋了并且剛剛部署了某人，則可能與他們有關。 ## 經驗教訓 [ * **知識就是力量** 。 您越了解工作性質，可以做出更好的決策，工作效率就越高。 效率意味著您可以以更低的成本制造更大，更快的系統。 * **構建處理泄漏抽象的內容** 。 如果您正在使用抽象層來隱藏系統的基礎分布式特性，那么它將最終冒泡。 您的代碼必須理解并處理所有泄漏。 * **如果可以將** 全部放在一個盒子中。 如果您不需要分布式系統，請不要構建一個。 它們復雜且建造昂貴。 * **在面向服務的體系結構中，故障意味著功能減少而不是停機**。 * **SOA +隊列+異步消息傳遞確實很強大** 。 這種方法可以隔離組件，讓工作同時進行，讓盒子獨立發生故障，同時使組件仍然易于推理。 * **當速度和一致性至關重要時，請使用同步請求。** 。 給用戶一個錯誤，而不是緩慢或錯誤的答案。 * **事件樣式消息比命令樣式消息** 更好。 它們允許更好地隔離系統之間，并自然支持多個使用者。 幫助保持服務重點，而不用擔心服務超出預期范圍。 * **注釋而不是過濾器** 。 生產者級別的篩選器基于對下游服務關心的假設進行烘烤。 例如公共鏈接與私有鏈接。 從流中過濾出私人鏈接意味著對私人鏈接感興趣的服務將無法獲得所需的鏈接。 相反，請使用鏈接是私有鏈接還是公共鏈接來注釋事件，并讓服務僅在他們關心的事件類型上運行。 * **服務應該相互配合** 。 使用反壓可防止服務過載，并繞過故障服務。 * **如果沒有 Nagios 檢查，則幾乎可以確定是** 。 您只是還不知道。 * **工具應將信息公開給人類** 。 在正確的時間向正確的人提供正確的信息。 ## 相關文章 * [關于黑客新聞](https://news.ycombinator.com/item?id=8031606) 假設所有負載平均分布在 8 個高峰時段，即每秒僅 17 個請求（6000000000/400/30/8/3600）。 他們在用 400 臺服務器做什么？ 考慮到縮短的請求幾乎不會導致負載，因此每秒 17 個請求是什么。 每個 CPU 內核應為> 100，并每秒。 這里是原始演講的作者。 真的很受寵若驚。 首先，對文章進行了較小的更正，是?20 名工程師（50 人公司）而不是 50 名工程師。 第二個建議：tobi，并非所有 400 臺服務器都在處理重定向。 約 30 臺服務器處理來自外界的所有傳入流量，包括縮短，重定向，api 請求，Web ui 等。其余 400 臺服務器專用于各種服務，包括存儲和組織用戶數據或提供各種形式的處理和分析（數據庫） ，指標，網頁抓取，文本分析等）。 @tobi 400 可能包括質量保證和生產環境，并且將分布在 HDFS /數據庫集群，隊列處理器，應用服務器等上。此外，該帖子似乎表明他們正在使用商品硬件，這可能意味著它們的主機不在 不是多租戶。 tobi，“ 400 臺服務器”！= 400 臺 Web 服務器。 是的，加上單擊！=流程，并且在 8 個小時內完全均勻地加載是一個可怕的假設（考慮到即使在 Twitter 高峰期間，他們也希望獲得低延遲的同步響應，而互聯網上沒有“營業時間”之類的東西）。 這是一個仍然人為但更現實的示例： [6000000000（點擊）x 4（每次點擊的平均進程數）] / [400/3]（每個進程平均 3 個服務器層） / 30（每月天數） / 24（小時） 每天） * 10（峰值時間突發） / 3600（每小時秒數） 在突發期間沒有故障的情況下，向任何特定服務器提供 700 msgs /秒的速度。 6B req / sec == 200M / day 平均值 盡管這可以達到?3000 / sec，但必須意識到平均值和峰值相差很大。 您不能為平均水平設計架構師。 峰值可以提高 10 倍。 像這樣的分布式系統最大的麻煩就是一致性：確保不會將相同的短 URL 分配給兩個不同的 URL。 我想您可以通過規范化和哈希 URL 并在哈希上共享來緩解這種情況... 適用于所有 API 和 Web 的 30 臺服務器非常合理。 用于分析和相關服務的 370 臺服務器（占 92.5％）揭示了賺錢的地方。 我同意，僅 1 核 CPU 可以很好地滿足 17 rps 的要求。 @bitlydevs，您應該閱讀 snabswitch 如何僅通過一個節點即可提供 10M rps。 http://highscalability.com/blog/2014/2/13/snabb-switch-skip-the-os-and-get-40-million-requests-per-sec.html “帶有 1x RAM 的 4 盒總是比帶有 4x RAM 的 1 盒便宜。” 怎么/為什么？ 是的，在這里聽 santosh，老兄顯然知道更好