# 優步變得非常規：使用司機電話作為備份數據中心 > 原文： [http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html)  在[中，Uber 如何擴展其實時市場平臺](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)，最吸引人的提示之一是 Uber 如何使用驅動程序電話作為外部分布式存儲系統進行恢復來處理數據中心故障轉移。 現在我們從 Uber 的 [Nikunj Aggarwal](https://www.linkedin.com/pub/nikunj-aggarwal/20/878/3b4) 和 [Joshua Corbin](https://www.linkedin.com/in/joshuatcorbin) 了解了更多有關該系統的工作原理，他們在 [@Scale](http://www.atscaleconference.com/) 會議上發表了非常有趣的演講： [。Uber 如何將您的手機用作備份數據中心](https://www.youtube.com/watch?v=0EhTOKcwRok)。 Uber 并未使用傳統的后端復制方案，在該方案中，數據庫在數據中心之間同步狀態以實現 [k-safety](https://my.vertica.com/docs/5.0/HTML/Master/10730.htm) 的度量，而 Uber 做了一些不同的事情，他們要做的是將足夠的狀態存儲在驅動程序電話上，以便在數據中心進行故障轉移時 發生故障信息不會在故障轉移上丟失。 為什么選擇這種方法？ 傳統方法會簡單得多。 我認為這是要確保客戶始終擁有良好的**客戶體驗**，并且由于主動出行而丟失行程信息會帶來可怕的客戶體驗。 通過圍繞電話建立他們的同步策略，甚至認為它很復雜且需要大量工作，Uber 能夠保留旅行數據并即使在數據中心發生故障時也能提供無縫的客戶體驗。 使客戶滿意是至關重要的，尤其是在**接近零轉換成本**的市場中。 因此，目標是即使在數據中心故障轉移時也不會丟失行程信息。 使用傳統的數據庫復制策略，由于與[網絡管理系統](http://whatis.techtarget.com/definition/network-management-system)始終必須工作的方式類似的原因，不可能做出此保證。 讓我解釋。 在網絡設備中，狀態信息的權威來源是**，例如分組錯誤，警報，發送和接收的分組等等。 網絡管理系統對諸如警報閾值和客戶信息之類的配置數據具有權威性。 麻煩的是設備與網絡管理系統并不總是保持聯系，因此它們不同步，因為它們彼此獨立地工作。 這意味著在啟動，故障轉移和通信重新連接時，所有這些信息都必須使用復雜的舞蹈在兩個方向上合并，以確保正確性和一致性。** Uber 有同樣的問題，只有設備是智能手機，而手機所包含的權威狀態是出行信息。 因此，在啟動，故障轉移和通信重新連接時，必須保留行程信息，因為電話**是行程信息**的權威來源。 即使失去連接，電話也能準確記錄所有行程數據。 因此，您不希望將行程數據從數據中心向下同步到手機，因為這會清除手機上的正確數據。 正確的信息必須來自電話。 Uber 還從網絡管理系統中吸取了另一招。 他們定期查詢電話以測試數據中心中信息的完整性。 讓我們看看他們是如何做到的... ## 將電話用作數據中心故障存儲的動機 * 不久前，發生故障的數據中心將導致客戶旅行丟失。 現在已解決。 在數據中心發生故障時，客戶可以立即返回旅途，幾乎沒有明顯的停機時間。 * 將旅行的請求，提供給駕駛員的旅行，接受的旅行，上車的乘客以及結束旅行的過程稱為**狀態更改轉換**。 只要行程持續，行程交易就持續。 * 從行程開始起，便在后端數據中心中創建了行程數據。 似乎每個城市都有一個指定的數據中心。 * **數據中心故障的典型解決方案**：將數據從活動數據中心復制到備份數據中心。 很好理解，并且可以很好地工作，具體取決于您的數據庫。 缺點： * 超出了兩個備份數據中心的復雜性。 * 數據中心之間的復制滯后。 * 它需要數據中心之間的恒定高帶寬，特別是如果您的數據庫對數據中心復制沒有很好的支持，或者您尚未調整業務模型來優化增量。 * （一個尚未被談論的好處，對于 Uber 而言可能并不重要，但對于較小的參與者而言可能是重要的，因為駕駛員電話計劃通過不必為數據中心間的帶寬支付那么多錢來補貼帶寬成本。 ） * **具有創造力的應用程序意識的解決方案**：由于與駕駛員電話的持續通信只是將數據保存到駕駛員電話。 優點： * 可以故障轉移到任何數據中心。 * 避免了電話故障轉移到錯誤的數據中心的問題，這將導致丟失所有行程。 * 使用驅動程序電話來保存數據中心備份需要復制協議。 * 與數據中心通信時，會發生所有狀態轉換。 例如，有一個 Begin Trip 或 Begin Drive 請求，這是與手機交換狀態數據并擁有手機存儲數據的絕佳機會。 * 在數據中心故障轉移上，當電話 ping 新數據中心時，需要從電話中請求行程數據。 停機時間非常短。 （沒有有關如何處理數據中心地圖的信息）。 * 挑戰： * 并非駕駛員可以訪問所有保存的行程信息。 例如，一次旅行有很多關于所有騎手的信息，這些信息不應該被公開。 * 必須假設驅動程序手機可能受到攻擊，這意味著必須對數據進行防篡改。 因此，所有數據都在手機上進行了加密。 * 希望保持復制協議盡可能簡單，以便于推理和調試。 * 最小化額外帶寬。 使用基于電話的方法，可以調整要序列化的數據和保留的增量，以最大程度地減少移動網絡上的流量。 * 復制協議 * 一個簡單的鍵值存儲模型用于鍵操作的獲取，設置，刪除，列表。 * 只能設置一次密鑰，以防止意外覆蓋和亂碼消息問題。 * 設置了一次之后，規則版本控制就必須移入密鑰空間。 更新存儲的行程的過程如下：set（“ trip1，version2”，“ yyu”）; delete（“ trip1，version1”）。 這樣做的好處是，如果在設置和刪除之間出現故障，將存儲兩個值，而不存儲任何值。 * 故障轉移解決方案只需通過以下方法在電話和新數據中心之間合并密鑰即可：將存儲的密鑰與駕駛員已知的任何正在進行的行程進行比較； 對于任何丟失的數據，可能會向手機發送一個或多個 *get* 操作。 ## 他們如何獲得系統大規模運行的可靠性 ### 目標 * **確保系統未阻塞，同時仍提供最終的一致性**。 即使系統關閉，系統中的任何后端應用程序也應能夠取得進展。 應用程序應該做出的唯一權衡是，將數據存儲在手機上可能要花費一些時間。 * **能夠在數據中心之間移動而不必擔心已有的數據**。 需要一種在驅動程序和服務器之間協調數據的方法。 * 當故障轉移到該數據中心具有活動驅動程序和行程的視圖的數據中心時，該數據中心中的任何服務都不知道發生了故障。 * 在故障恢復到原始數據中心時，驅動程序和旅行數據過時，這會帶來糟糕的客戶體驗。 * **使其可測試**。 數據中心故障很少見，因此通常很難測試。 他們希望能夠不斷地衡量系統的成功，以便他們可以確信故障轉移在發生時將成功。 ### 流程 * 駕駛員進行更新/狀態更改，例如，載客。 該更新是對調度服務的請求。 * 調度服務更新了行程的行程模型。 該更新將發送到復制服務。 * 復制服務將請求排隊并返回成功。 * 調度服務更新其自己的數據存儲并將成功返回給移動客戶端。 也可能會返回其他數據，例如，如果是 Uber 泳池旅行，則可能需要接載其他乘客。 * 在后臺，復制服務對數據進行加密并將其發送到消息服務。 * 消息服務維護所有驅動程序的雙向通道。 此通道與驅動程序用來與服務進行通信的原始請求通道分開。 這確保了正常的業務運營不會受到備份過程的影響。 * Messenger Service 將備份發送到電話。 * 這種設計的好處： * **應用程序已與復制延遲和故障**隔離。 復制服務將立即返回。 應用程序只需要進行廉價調用（在同一數據中心內）即可復制數據。 * **消息服務支持電話的任意查詢，而不會影響正常的業務運營**。 可以將電話視為基本鍵值存儲。 ### 在數據中心之間移動 * 第一種方法是**在故障轉移**上手動運行腳本，以從數據庫中清除舊狀態。 由于有人必須這樣做，因此該方法具有**手術疼痛**。 由于可以一次或多次在多個城市進行故障轉移，因此腳本變得太復雜了。 * 回想一下，它們的鍵值數據庫中的鍵包含行程 ID 和版本號。 版本號曾經是一個遞增號。 更改為**修改矢量時鐘**。 使用**手機上的矢量時鐘數據可以與服務器**上的數據進行比較。 任何因果關系違規都可以被發現并解決。 這解決了進行中的行程的協調問題。 * 傳統上，已完成的旅行將從手機中刪除，因此復制數據不會無限制地增長。 問題在于，當故障恢復到原始數據中心時，該數據中心將具有陳舊的數據，這可能會導致調度異常。 該修復程序在旅途完成時使用了特殊的[墓碑](https://en.wikipedia.org/wiki/Tombstone_(data_store))鍵。 該版本帶有一個標志，指示旅程已完成。 當復制服務看到該標志時，它可以告訴調度服務該行程已完成。 * 存儲旅行數據非常昂貴，因為它是 JSON 數據的加密大塊。 完成的行程需要更少的存儲空間。 可以將一個星期的已完成旅行與一個活動旅行存儲在同一空間中。 ### 確保 99.99％的可靠性 * 故障轉移系統不斷進行測試，以建立其正常工作以及故障轉移將成功的信心。 * 第一種方法是各個城市的**手動故障轉移**。 然后通過查看日志來查看還原和調試問題的成功率。 * **高手術疼痛**。 每周手動執行此過程無效。 * **糟糕的客戶體驗**。 對于少數未能正確恢復的行程，必須調整票價。 * **低覆蓋率**。 一次只能測試幾個城市，并且由于某些問題僅針對特定城市，這可能是由于具有特定于城市的新功能所致，這些錯誤將被忽略。 * **不知道備份數據中心是否可以處理負載**。 有一個主數據中心和一個備用數據中心。 即使它們的配置相同，您如何知道備份數據中心可以解決雷電群問題，即故障轉移時發生的大量請求。 * 為了解決這些問題，他們**研究了他們要測試的系統中的關鍵概念**。 * **確保調度服務中的所有突變實際上都存儲在電話中**。 例如，司機接客后可能會失去連接，因此復制數據可能不會立即發送到電話。 需要確保最終將數據發送到手機。 * **確保可以將存儲的數據用于復制**。 例如，是否存在任何加密/解密問題。 在合并備份數據時是否有任何問題？ * **確保備份數據中心可以處理負載**。 * 為了監視系統的運行狀況，誕生了監視服務。 * 服務每小時都會從調度服務中獲取所有活動駕駛員和行程的列表。 對于所有驅動程序，消息服務用于獲取復制數據。 * 然后比較數據以查看數據是否符合預期。 這產生了許多良好的健康指標，例如失敗的百分比。 * 按地區和應用程序版本劃分指標對于查明問題有很大幫助。 * **影子恢復**用于測試備份數據中心。 * Monitoring Service 收集的數據被發送到備份數據中心以進行影子恢復。 * **成功率**是通過使用 Dispatch Service 查詢和比較來自主數據中心的快照與活動的驅動程序和來自備份數據中心的行程的數量來計算的。 * 還計算了有關備份數據中心如何處理負載的指標。 * 這種方法可以解決備份數據中心中的任何配置問題。 ## 相關文章 * [關于 Hacker News 3](https://news.ycombinator.com/item?id=10446835) / [關于 HackerNews](https://news.ycombinator.com/item?id=10253158) / [關于 HackerNews 2](https://news.ycombinator.com/item?id=10271850) / [關于 reddit](https://www.reddit.com/r/programming/comments/3mp4al/uber_goes_unconventional_using_driver_phones_as_a/) * [數據服務與 Uber 搭便車](https://www.youtube.com/watch?v=Dg76cNaeB4s) 我在職業生涯中花費了大量時間來構建可在對等數據庫上運行的應用程序，因此我看到了這種好處。 文章未涉及的一件事是，在多大程度上使用手機上的本地數據可以對開發人員提高生產力。 數據字段可以由應用添加，而無需在客戶端/服務器/數據庫堆棧之間協調架構。 對等同步在開發環境中也很方便，因此您的手機可以“修復”在開發筆記本電腦上運行的數據中心。 這樣，您可以從云中的真實數據中心加載數據，重建應用程序，并將其同步到工作臺。 一旦接受了點對點數據模型，許多拓撲選擇就會成為后期綁定。 數據可以根據需要進行分配。 這帶來了各種開發和部署靈活性，例如此處所述的故障轉移彈性。 很好，因此它們不僅是螺絲刀，而且現在也減輕了他們的能源和存儲負擔。 要走的路，布伯。 這種方法不是新方法，也無法解決任何問題。 如果您的數據中心無法處理故障轉移，則不妨鎖上辦公室的門并扔掉鑰匙。 一旦計劃好行程，很明顯電話必須具有離線數據，以確保駕駛員到達目的地不會有問題。 這里的假設是數據中心可能會發生故障，但是設備呢？ 到處都是死區，當您輸入死區時，您的設備將沒有數據，因此如果沒有離線數據，您將陷入死水。 與其花時間和精力來想出這種方案，不如研究如何構建堅如磐石的 DC 更好。 客戶體驗的這場革命不僅為客戶帶來了新的便利，而且被證明是一種成功的商業模式。 例如，Uber 已經從僅在舊金山運營，發展成為全球發展最快的企業之一。 您現在可以在 35 個國家/地區“購物”。 同樣地，像 Lyft 這樣的競爭對手似乎也通過這種新生的客戶體驗劇變而朝著世界統治方向發展。