http://www.nosqlnotes.net/wp-content/uploads/Distributed_System_Engineering_Practice.pdf

分布式系統工程實踐 楊傳輝 日照 淘寶 ? 分布式系統工程實踐 ................................ ................................ ................................ ....................... 1 1 引言 ................................ ................................ ................................ ................................ ........... 3 2 基礎知識 ................................ ................................ ................................ ................................ ... 3 2.1 硬件基礎 ................................ ................................ ................................ ....................... 4 2.2 性能估算 ................................ ................................ ................................ ....................... 4 2.3 CAP ................................ ................................ ................................ ................................ 6 2.4 一致性模型 ................................ ................................ ................................ ................... 7 2.5 NOSQL 與 SQL ................................ ................................ ................................ ............... 9 2.6 Two - Phase commit ................................ ................................ ................................ ...... 10 2.7 Paxos ................................ ................................ ................................ ........................... 11 3 關鍵技術實現 ................................ ................................ ................................ ......................... 12 3.1 網絡編程框架 ................................ ................................ ................................ ............. 12 3.2 HA 與 Replication ................................ ................................ ................................ ........ 13 3.3 分裂 ................................ ................................ ................................ ............................. 14 3.4 遷移 ................................ ................................ ................................ ............................. 15 3.5 負載均衡 ................................ ................................ ................................ ..................... 16 3.6 Chubby ................................ ................................ ................................ ........................ 16 3.7 分布式事務 ................................ ................................ ................................ ................. 17 3.8 Copy - on - write 與 Snap shot ................................ ................................ ........................ 17 3.9 操作日志與 checkpoint ................................ ................................ .............................. 19 3.10 列式存儲與壓縮 ................................ ................................ ................................ ..... 19 4 通用存儲系統分類 ................................ ................................ ................................ ................. 20 5 典型存儲系統工程實現 ................................ ................................ ................................ ......... 21 5.1 單機存儲引擎 ................................ ................................ ................................ ............. 21 5.1.1 隨機訪問存儲引擎 ................................ ................................ ......................... 21 5.1.2 通用存儲引擎 ................................ ................................ ................................ . 22 5.1.3 單機存儲優化 ................................ ................................ ................................ . 23 5.2 SQL 數據庫 ................................ ................................ ................................ ................. 23 5.3 線上最終一致性系統 ................................ ................................ ................................ . 24 5.4 線上弱一致性系統 ................................ ................................ ................................ ..... 26 5.5 半線上及線下系統 ................................ ................................ ................................ ..... 29 5.5.1 兩層結構 ................................ ................................ ................................ ......... 29 5.5.2 GFS ................................ ................................ ................................ ................... 30 5.5.3 Bigtable ................................ ................................ ................................ ............ 31 6 通用計算系統分類 ................................ ................................ ................................ ................. 32 7 典型計算系統工程實現 ................................ ................................ ................................ ......... 33 7.1 MapReduce Offlin e ................................ ................................ ................................ ..... 33 7.2 Online 計算 ................................ ................................ ................................ ................. 34 7.2.1 流式計算 ................................ ................................ ................................ ......... 34 7.2.2 并行數據庫的 SQL 查詢 ................................ ................................ ................. 35 7.2.3 數據倉庫復雜查詢 ................................ ................................ ......................... 36 8 應用 ................................ ................................ ................................ ................................ ......... 38 8.1 電子商務類 ................................ ................................ ................................ ................. 38 8.2 搜索類 ................................ ................................ ................................ ......................... 38 8.3 社交類 ................................ ................................ ................................ ......................... 39 8.4 郵箱類 ................................ ................................ ................................ ......................... 40 8.5 圖片及視頻類 ................................ ................................ ................................ ............. 40 8.6 數據倉庫類 ................................ ................................ ................................ ................. 40 8.7 云服務類 ................................ ................................ ................................ ..................... 41 9 工程實現注意事項 ................................ ................................ ................................ ................. 41 9.1 工程現象 ................................ ................................ ................................ ..................... 41 9.2 規范制訂 ................................ ................................ ................................ ..................... 42 9.3 經驗法則 ................................ ................................ ................................ ..................... 42 9.4 質量控制 ................................ ................................ ................................ ..................... 42 9.4.1 測試第一 ................................ ................................ ................................ ......... 42 9.4.2 代碼 Review ................................ ................................ ................................ .... 42 9.4.3 服務器程序的資源管理 ................................ ................................ ................. 43 10 致謝 ................................ ................................ ................................ ................................ . 43 11 參考文獻 ................................ ................................ ................................ ......................... 43 11.1 書籍類 ................................ ................................ ................................ ..................... 43 11.2 論文類 ................................ ................................ ................................ ..................... 43 11.2.1 分布式理論 ................................ ................................ ................................ ..... 43 11.2.2 Google 系列 ................................ ................................ ................................ .... 44 11.2.3 Dynamo 及 P2P 系列 ................................ ................................ ...................... 44 11.2.4 存儲系統 ................................ ................................ ................................ ......... 44 11.2.5 計算系統 ................................ ................................ ................................ ......... 44 11.2.6 其它 ................................ ................................ ................................ ................. 44 11.3 網頁類 ................................ ................................ ................................ ..................... 45 11.3.1 個人博客類 ................................ ................................ ................................ ..... 45 11.3.2 專題類 ................................ ................................ ................................ ............. 45 11.3.3 其它 ................................ ................................ ................................ ................. 45 1 引言 NOSQL 的資料很 多， 不過不成體系，讓分布式系統開發工程師無所適從 。筆者 根據過去 跟 著陽老師 開發類似 Google GFS/MapReduce/Bigtable 的系統以及對 Dynamo, PNUTS 等典型系 統的理解 嘗試梳理流行的分布式存儲和計算系統 的分類，設計及實現 。 本文結構安排如下： ? 基礎知識： 一個大規模數據處理系統工程師必備的基礎知識； ? 關鍵技術實現：工程實踐中遇到的典型問題的解決思路； ? 通用存儲系統分類 ：講述筆者 關于存儲系統 如何劃分的個人觀點； ? 典型存儲系統工程實現：選取 典型的 存儲 系統講述 大致實現； ? 通用計算系統分類 ：講述筆者對于計算系統如何劃分的個人觀點； ? 典型計算系統工程實現： 講述典型計算系統的大致實現； ? 應用：存儲 & 計算 系統應用的一些實例； ? 工程實現注意事項： 總結設計和開發過程中 可能犯的一些錯誤； ? 致謝及參考資料：列出一些值得看的論文和網頁資料； 每個章節涉及的話題都很大，由于筆者的水平實在是非常 非常 有限，只能說是盡力把自己知 道并能夠說明白的寫下來， 作為自己對過去工作的回憶 。 把其中任何一個話題講明白都 遠遠 超出了我的能力范疇 ，寫錯的地方在所難免， 各位同學發現問題 盡管笑一笑， 當然，歡迎任 何形式的討論， 我會盡量和更多的同學討論來不斷完善這個文檔。 本文只是一個 初始 綜述， 后續 將 細化每一個問題 并發表到博客中。 2 基礎知識 本章描述工程實現需要的一些基礎知識，由于篇幅的關系，只抽取一些認為對理解和設計大 規模系統必要的基礎知識 進行 描述 。另外， 假設讀者 了解 NOSQL 基 本概念，做過 或者看過 一兩個類似的系統，閱讀過 GFS/Bigtable/Paxos 相關的論文。 分布式理論有一個特點是：大 致的做法是很容易想到的，但是完全沒 有問題的做法非常難想，理解理論的用處就 在于區分 出想法的問題在哪兒以及實現的難度。 2.1 硬件基礎 分布式系統開發工程師需要了解硬件的大致價格，熟記硬件的性能。 硬件 大致 性能如下： 標記為紅色性能參數比較常用，其中，磁盤的性能指標專指分布式平臺專用的大容量 SATA 磁盤，尋道時間為 8~10ms ，順序讀取速率為 40~50MB 。 某些應用 使用 SAS 磁盤或者 Flash 盤，性能較好，評估時需查看硬件的性能參數。磁盤和網絡都有一個特征，一次讀寫的數據 量越大性能越好，這是由硬件特征及底層軟件算法決定的，如 tcp 慢連接和磁盤尋道時間長。 2.2 性能估算 給定一個問題，往往會有多種設計方案，而方案評估的一個重要指標就是性能，如何在系統 設計時估算而不是程序執行時測試得到性能數據是系統架構設計的重要技能。性能估算有如 下用途： 1) 多種設計方案選擇； 2) 評價程序實現是否足夠優化； 3) 向框架 / 服務提供方提出性能要求的依據； L1 c ache reference 0.5ns Branch mispredict 5ns L2 cache reference 7ns Mutex lock/unlock 100ns Main memory reference 100ns Send 1M bytes over 1Gbps network 10ms Read 1M sequentially from memory 0.25ms Round trip within data center 0.5ms Disk seek 8~10ms Read 1MB sequentially from disk 20~25ms 很多同學喜歡 通過查看程序運行時 CPU 及網絡的使用情況來評價程序是否足夠優化， 這 也是一種很重要的方法。然而，這種方法掩蓋了不優化的實現，如 O(N) 的算法被錯誤實現 成 O(N^2) ，網絡收發冗余數據等。 性能評估需要假設程序的執行環境，如集群規模及機器配置，集群上其它服務占用資源的比 例。 對硬件性能指標有了初步認識以后，我們可以做出一些簡單的判斷，如： 某 K - V 引擎 RD ： 我們的 K - V 引擎 單 客戶端同步讀取每秒可以達到 18000/s 。 問：是否批量讀取？ 答：是，每批讀取 10 個記錄。 由于 tcp Round trip 時間為 0.5ms ，讀取請求個數的理論極限為 2000/s ，而 上例中 K - V 引 擎的 RD 卻說單客戶同步讀取可以達到 18000/s ，可以斷定 該 RD 指的是批量讀取方式。且這 已經是單機能夠做到的極限值了。 下面我們通過幾個實例說明如何進行性能評估。 1. 1 GB 的 4 字節整數 ， 內存 排序時間為多少？ 拿到這個問題，我們往往會計算 CPU 運算次數，如快排的運算次數為 1.4 * N * log(N) ， 其中 1.4 為快排的系數，再根據 CPU 的運算頻率計算出排序耗時。不過這種方法很土也不是 很準， Jeff Dean 告訴我們可以這樣估算：排序時間 = 比較時間（分支預測錯誤） + 內存訪 問時間。快排過程中會發生大量的分支預測錯誤，所以比較次數為 2^28 * log (2^28) ≈ 2^33 ， 其中約 1/2 的比較會發生分支預測錯誤，所以比較時間為 1/2 * 2 ^ 32 * 5ns = 21s ，另外，快 排每次找到分割點都需要一遍內存移動操作，而內存順序訪問性能為 4GB/s ，所以內存訪問 時間為 28 * 1GB / 4GB = 7s 。因此，單線程排序 1GB 4 字節整數總時間約為 28s 。 2. Bigtable 設計的性能指標分析 假設 Bigtable 總體設計中給出的性能指標為 : 系統配置： 50 臺 4 核 8GB 內存 12 路 SATA 硬盤，同樣數量的客戶端； Table ： row name ： 16 - byte ， column ： 16 - byte ， value ： 1KB ； 64KB data block ； no compression ； R andom reads (in disk) ： 1KB/item*300item/s*50=15MB/s Random reads (in memory) ： 1KB/item*4000item/s*50=200MB/s Random writes ： 1KB/item*2000item/s*50=100MB/s S equential reads(in disk) ： 1KB/item*1000item/s*50=50MB/s Sequential writes ： 1KB/item*2000item/s*50=100MB/s 先看磁盤中的隨機讀取性能，由于在 Bigtable 的設計中每個隨機讀取 都要讀取一個 64KB 的大塊，而磁盤中讀取 64KB 數據時間為：磁盤尋道時間 + 讀取時間 = 10 ms + 64KB / 50MB/s = 12 ms 。所以每秒讀取 300 個記錄 指多客戶端讀取或者單客戶端異步 / 批量讀取 。由于每臺 機器有 12 個 SATA 大容量磁盤，隨機讀的理論值為 12 * 1s / 12ms = 10 00 個 /s 。設計為每秒 讀取 300 個是考慮到有負載平衡等因素簡單地打了一個折扣 。 再看內存中的隨機讀取。一般來說，內存操作都是每秒 1W~10W 。由于網絡發送小數據 有較多 overhead 且 Bigtable 內存操作有較多的內存開銷，所以保守設計為單機每秒讀取 4000 個記錄。 其它的可類似分析。性能分析可能會很復雜，因為不同的情況下決定性能的瓶頸不一樣， 有的時候是網絡，有的時候是磁 盤，有的時候甚至是機房的交換機。這種性能分析的經驗是 需要慢慢積累的。 最后，我們再看看某一個 MapReduce 應用的例子 。 MapReduce 可以簡單地分為幾個過 程： Map 處理時間 + shuffle 和排序時間 + reduce 處理時間，雖然 shuffle 、 map 處理和排序 可以部分并行，但性能估算的時候不必考慮。假設 50 臺機器，原始輸入為 50G ， 例中 MapReduce 應用的 map 函數 處理時間為 100s ， reduce 函數 處理時間為 60s ， shuffle 的中間 結果數據量為 300G ， reduce 輸出的最終結果大小 為 600M 。 Map 處理時間 = 輸入讀取時間 + Map 函數 處理時間 + 輸出中間結果時間 其中，輸入讀取時間 = 50G / 2.5G = 25s (50 臺機器，假設每臺機器讀取帶寬為 50M/s) ， M ap 函數 處理時間 = 60s ， 輸出中間結果時間 = 300G / 15G = 20s (50 臺機器，每臺機器 12 個磁盤，假設用滿 6 個 磁盤，帶寬為 6 * 50M = 300M) 所以， Map 處理時間 = 25s + 60s + 20s = 105s Shuffle 和排序時間 = shuffle 時間 + 排序時間 其中， shuffle 時間 = 300G / 2G = 150s (50 臺機器，假設每臺機器的讀取和寫入帶寬均為 40M ，單機總帶寬為 80M) 排序時間 = 單機排序 6G 的時間，假設每條記錄為 1KB = 排序比較時間 + 訪問時間， 約為 25s 所以， shuffle 和排序的時間 = 150s + 25s = 175s Reduce 處理時間 = reduce 函數 處理時間 + 最終結果輸出時間 其中， reduce 函數 處理時間 = 100s ， 最終結果輸出時間 = 600M / 500M (50 臺機器，單機寫 DFS 假設時間為 10M/s) = 1s ( 忽略 ) 所以， 例中的 MapReduce 應用 運行一遍大致需要的時間 = Map 處理時間 + shuffle 和排 序時間 + Reduce 處理時間 = 105s + 175s + 100s = 380s ，當然， MapReduce 過程中還有框架 的開銷和其它應用的影響，我們可以簡單地認為影響為 20% ，所以總時間 = 380s + 380s * 20% = 456s ，約為 7~8 min 。 當然， MapReduce 應用 實際的性能估算不會如此簡單，實際估算時需要考慮每臺機器上 啟動的 Map 和 Reduce 個數等因素，且需要根據實驗的結果不斷地驗證和重新調整估算。但 是，我們至少可以保證，估算的結果和實際不會相差一個數量級，估算結果可以用來指導初 期的設計和 Map/Reduce Worker 的個數、 Map/Reduce 任務數選擇，評估應用的可優化空間 并作為向 MapReduce 框架提供小組提出需求的依據。 性能估算是大規模系統設計中較難掌握的技能，開始性能估算時可能估計得很不準，不過不 要氣餒，通過在項目中不斷練習，大規模系統的分析和設計能力 才能做到有理可依 。 2.3 CAP CAP 是一個很時髦的概念 ， 然而， 對于設計和實現大規模分布式系統而言，只需要在腦海里 面有一個粗略的概念即可。 我們先看看 CAP 是怎么回事。 CAP 理論由 Berkerly 的 Brewer 教授提出 ，在最初的論文中 ， 三者含義如下： ? 一致性 ( C onsistency) ： 任何一 個讀操作總是能讀取到之前完成 的寫操作結果 ； ? 可用性 ( A vailability) ： 每一個操作總是能夠在確定的時間內返回； ? 分區可容忍性 (Tolerance of network P artition) ：在出現網絡分區的情況下，仍然能夠滿足一 致性和可用性； CAP 理論認為，三者不能同時滿足，并給出了證明，簡單闡述如下： 假設系統出現網絡分區 為 G1 和 G2 兩個部分，在一個寫操作 W1 后面有一個讀操作 R2 ， W1 寫 G1 ， R2 讀取 G2 ， 由于 G1 和 G2 不能通信，如果讀操作 R2 可以終結的話，必定不能讀取寫操作 W1 的操作結 果。 然而， 這種對一致性及可用性的定義方法在工程實踐上意義不大， CAP 理論只是粗略地告訴 我們 “天下沒有免費的午餐”。 比如 Availability 的定義， 10 秒鐘停服務和 1 個小時停服務在 工程實踐中完全是兩個概念。因此 ，我們往往會修改 CAP 的 定義如下： ? 一致性 ( C onsistency) ： 讀操作 總是能讀取到之前完成的寫操作結果，滿足這個條件的系統 稱為 強一致系統，這里的“之前”一般對同一個客戶端而言，但可能是一個客戶端的多個 Session ； ? 可用性 ( A vailability) ： 讀寫操作在 單臺 機器發生故障的情況下仍然能夠 正常執行，而不需要 等到機器重啟或者機器上的服務分配給其它機器才能執行； ? 分區可容忍性 (Tolerance of network P artition) ： 機房停電 或者機房間網絡故障 的時候仍然能 夠滿足一致性和可用性； 工程實踐對網絡分區考慮較少， 一般可以認為：一致性和寫操作的可用性不能同時滿足， 即 如果要保證強一致性，那么出現機器故障的時候，寫操作需要等機器重啟或者機器上的服務 遷移到別的機器才可以繼續。 2.4 一致性模型 Amazon 的 CTO 專門在官網中闡述了一致性模型， 足見其重要性，可以認為， 一 致性要求 直 接決定了存儲系統設計和實現的復雜度。 為了更好的描述客戶端一致性，我們通過以下的場景來進行，這個場景中包括三個組成部分： ? 存儲系統 存儲系統可以理解為一個黑盒子，它為我們提供了可用性和持久性的保證。 ? Process A Process A 主要實現從存儲系統 write 和 read 操作 ? Process B 和 Process C Process B 和 C 是獨立于 A ，并且 B 和 C 也相互獨立的，它們同時也實現對存儲系統的 write 和 read 操作。 下面以上面的場景來描述下不同程度的一致性： ? 強一致性 強一致性（即時一致性） 假如 A 先寫入了一個值到存儲系統，存儲系統保證后續 A,B,C 的讀取操作都將返回最新值 ? 弱一致性 假如 A 先寫入了一個值到存儲系統，存儲系統不能保證后續 A,B,C 的讀取操作能讀取到 最新值。此種情況下有一個 “ 不一致性窗口 ” 的概念，它特指從 A 寫入值，到后續操作 A,B,C 讀取到最新值這一段時間。 ? 最終一致性 最終一致性是弱一致性的一種特例。假如 A 首先 write 了一個值到存儲系統，存儲系統 保證如果在 A,B,C 后續讀取之前沒有其它寫操作更新同樣的值的話，最終所有的讀取操 作都會讀取到最 A 寫入的最新值。此種情況下，如果沒有失敗發生的話， “ 不一致性窗 口 ” 的大小依賴于以下的幾個因素：交互延遲，系統的負載，以及復制技術中 replica 的 個數（這個可以理解為 master/salve 模式中， salve 的個數）。 一致性 模型 的變體如下： ? Causal consis tency （因果一致性） 如果 Process A 通知 Process B 它已經更新了數據，那么 Process B 的后續讀取操作則讀取 A 寫入的最新值，而與 A 沒有因果關系的 C 則可以最終一致性。 ? Read - your - writes consistency 如果 Process A 寫入了最新的值，那么 Process A 的后續操作都會讀取到最新值。但是其它用 戶可能要過一會才可以看到。 ? Session consistency 此種一致性要求客戶端和存儲系統交互的整個會話階段保證 Read - your - writes ，數據庫分庫 以后 一般會提供這種一致性保證，使得同一個 Session 的讀寫操作發送到同一臺數據庫節點 。 ? Monotonic read consistency 此種一致性要求如果 Process A 已經讀取了對象的某個值，那么后續操作將不會讀取到更早 的值。 ? Monotonic write consistency 此種一致性保證系統會序列化執行一個 Process 中的所有寫操作。 為了便于后續的說明， 我們修改 Amazon CTO 關于最終一致性的定義 。 Dynamo 通過 NWR 策略提供的最終一致性主要是針對 Dynamo 的多個副本而言的，它們之間保持最終一致。不 過對于用戶，我們假設 N=3, W=2, R=2 的一種情況，用戶 先調用 W1 寫 A 和 B 兩個副本后成 功返回，接著調用 W2 寫 B 和 A 兩個副本后成功返回，可能出現在副本 A 上 W1 先于 W2 執 行，而在副本 B 上 W2 先于 W1 執行，雖然副本 A 和 B 都 能夠 通過執行滿足交換律的合并操 作，比如基于 ” last write wins ” 的策略進行合并使得最終副本 A 和 B 上的數據完全一致， 但是 可能出現一些異常情況，比如副本 A 和 B 所在的機器時鐘不一致，合并的結果是 W1 把 W2 給覆蓋了 ， W2 的操作結果消失了 。這顯然 與用戶的期望是不一致的。 為了方便后續對系統進行劃分， 我們 把 Amazon Dynamo 這種需要依賴操作合并，可能 會丟失數據的模型從最終一致性模型中排除出去 。 最終一致性 模型要求同一份數據同一時 刻只能被一臺機器修改， 也就是說機器宕機 時需要停很短 時間寫服務 。 Amazon Dynamo 提 供的一致性模型我們歸類到一般的弱一致性模型中。 2.5 NOSQL 與 卑 NOSQL 可以認為是選取了 SQL 特性的子集， 在擴展性和用戶接口友好 兩個 方面做了一 個權衡。 “越多選擇，越多迷茫” ，實踐經驗告訴我們，如果將 SQL 的 功能完全暴露給用戶， 用戶一定會使用一些我們不希望的功能，比如多表 join ，外鍵，等 等 。 NOSQL 的意義在于 ， 我們預先定義一些特性，這些特性滿足某一個應用的需求，并且 只滿足這些特性使得我們的 系統很容易擴展。 SQL 定義了一個功能全集， NOSQL 根據應用特點選取幾種特定的應用定義 不同的特性集合 ，以適應互聯網數據量高速膨脹的需求。 一般來說， NOSQL 的應用會比 SQL 的應用更加注意可用性， 所以 NOSQL 應用對外表現 為經常可以選擇最終一致性模型 。不過，從通用系統的角度看，這里的最終一致性指：大多 數操作允許讀取老的數據 ，少數操作仍然希望讀取最新的數據，并且應用不希望出現數據丟 失的情況。 所以，不能因為 NOSQL 就容忍數據丟失的情況，雖然這會極大地加大系統設計 和實現的難度。 另外， NOSQL 不等于必須用 MapReduce 做計算模型，雖然二者經常結對出現，不過本 質上是不相關的。 NOSQL 比較常見的模型包括： ? KV 模型 ：只支持最簡單的針對 <key, value> 對的操作 ? 支持簡單 table schema 的模型，如 Bigtable 模型 由于 NOSQL 相對 SQL 而言更加注重擴展性、成本等， NOSQL 有一些共同 的設計原則： ? 假設失效是必然發生的 ： NOSQL 注意擴展性和成本，機器數變多時，原本屬于異 常現象的機器故障變成一種正常現象， NOSQL 也采用一些比較便宜的普通 PC 機， 要求通過軟件的方法處理錯誤。 ? 限定應用模式。從最為簡單的 KV 應用模型，到復雜的支持用戶自定義 schema 的 Bigtable 模型， NOSQL 支持的接口永遠不可能和 SQL 相比。一般來說， NOSQL 系統 都只支持隨機讀和順序讀 ，少量系統支持表索引，類似外鍵這種影響擴展性且不實 用的功能基本是不需要支持的。 ? 擴容： 數據庫擴容一般是成倍增加機器的，而 NOSQL 系統一般是一臺 或者少量幾 臺構成一個機器組加入系統。 一般有兩種 數據分布方法，一種是一致性 Hash ，這 個算法在 Dynamo 論文中有詳細的介紹，另外一種方法是將整個表格分成連續的小 段，每個小段是一個子表，由全局管理機器負責將每個小段分配到新加入的數據讀 寫服務機器。 用一個例子說明取舍 SQL 的部分特性帶來的好處。比如單機 SQL 的 add 操作，這是 非 常容易的，然而，在多機上的實現變得非常困難。 因為我們需要操作多個副本，可能出現某 些 操作成功，某些永遠不成功的情況，我們只能通過一些鎖的方法來解決，比如分布式事務 的兩階段悲觀鎖或者另外一種 樂觀鎖。 Mysql 團隊也有部分同學開始通過削減 SQL 模型不必要的特性來滿足互聯網數據高速增 長的需求，它們發起了一個叫做 Drizzle 的項目。 Drizzle 誕生于 MySQL （ 6.0 ）關系數據庫的 拆分。在過去幾個月里，它的開發者已經移走了大量非核 心的功能（包括視圖、觸發器、 已編譯語句、存儲過程、查詢緩沖、 ACL 以及一些數據類型），其目標是要建立一個更精簡、 更快的數據庫系統。 個 group 同一時刻總是有一個 Master 節點作為代表， Slave 節點上的狀態與 Master 不一致時 以 Master 為準。 工程實踐中，分裂仍然是很復雜的，因此國 內幾 乎所有的分布式存儲系統都采用預先切 分 好 tablet 的方法。只要切分 得比較細，系統支撐一兩年是沒有問題的，等到出現問題時可 以整個系統停服務對數據重新劃分。 3.4 遷移 我們仍然假設整個大表按照類似 Bigtable 中的方法被劃 分為很多的子表 tablet 。 子表遷 移在 集群主控機的指導下進行，遷移的做法和分裂有很多共通 之處。 假設機器 A 需要將子表遷移到機器 B ，遷移的做法與單機 子表分裂 時 拷貝數據的方法類 似。分為兩個階段，第一個階段將機器 A 的待遷移子表的數據拷貝到 機器 B ， 這個階段新來 的修改操作只記錄操作日志；第二個階段停止寫服務，將第一個階段 拷貝數據過程中接收到 的修改操作拷貝到機器 B ；數據遷移完成時主控機修改被遷移子表的位置信息，整個遷移過 程結束。 同樣，如果單機存儲引擎支持快照功能，整個流程會更加容易和高效。 Bigtable 的遷移依賴于底層 GFS 提供可靠的文件存儲 ， Bigtable 寫操作的操作日志持久 化到 GFS 中，且每個 tablet 由一臺 Tablet Server 提供服務。當 Tablet Server 出現宕機或者負 載平衡 需要執行子表遷移操作時， 只需要停止源 Tablet Server 對待遷移 tablet 的服務并在目 的 Tablet Server 上重新加載 tablet 即可。 由于 Bigtable 有 GFS 提供可靠存儲，我們可以認為 Tablet Server 服務節點是無狀態的。 我們 在這里提出 一種設計方案：將機器分成一個一個的 group ，每一個子表都在某個 group 的每臺機器 存放一個備份 ，同一個時刻 一個 group 中只有一臺機器提供寫服務，其它 機器都提供讀服務。 將子表從 group A 遷移到 group B 其實就是將子表從 group A 中的 Master 機器遷移到 group B 中的 Master 機器，整個過程由集群的主控機來協調。 下面我們考慮一下 遷移過程中發生的各種異常情況： 1, 遷移的第一個階段 group A 中 Master 宕機： group A 中某臺與 Master 保持 強同步的 Slave 接替 Master 對外服務， 整個遷移過程 失敗結束 ； 2, 遷移的第二個階段 group A 中 Master 宕機： group A 中某臺與 Master 保持強同步的 Slave 接替 Master 對外服務，整個遷移過程失敗結束 ； 3, 遷移過程中 group B 中 Master 宕機：整個遷移過程失敗結束； 4, 拷貝數據完成后集群主控機修改子表位置信息失敗：此時被遷移 tablet 在 group A 和 group B 中的數據完全一樣，任意一個 group 提供服務均可； 5, 遷移完成后 group A 中 Master 宕機： group A 中某臺與 Master 保持強同步的 Slave 接 替 Master 對外服務， 這個 Slave 可能 不 知道子表已經遷移的信息。 子表遷移后客戶端寫操作 需要重新建立連接，這個過程會請求集群的主控機， 但是 group A 的機器可能使用老數據繼 續提供讀服務，這就需要 Master 將子表遷移信息告知 group A 中的其它機器。 上述的機器同構的做法有一個問題： 增加副本需要 全部 拷貝 一臺機器 存儲的 數據， 如果 數據總量為 1TB ，拷貝限速 20MB/s ，拷貝時間為十幾個小時，另外， 子表遷移 的 工程實現 也比較麻煩 。 因此 ， 工程上多數系統靜態分配好每個子表所在的機器并且不遷移，如數據庫 sharding 預先分配好每一份數據所在的機器。 另外一種做法是設計的時候 分離靜態數據和修 改數據，定期合并，遷移的時候只遷移靜態數據，這個思想在 淘寶最近研發的 Oceanbase 系統里面有所體現。 3.5 負載均衡 負載平衡是一個研究課題，難點在于負載平衡的策略和參數 調整，工程化的難度不大， 和數據挖掘相關的 項目有些類似，需要不斷地做假設并做實驗驗證。 負載平衡有兩種思路，一種是集群總控機根據負載情況全局調度，另一種思路是采用 DHT 方法。 第二種思路可以參考 Amazon Dynamo 的論文 ， DHT 算法中每個節點分配的 token 決定 了數據及負載的分布。 假設 DHT 環中有 S 個節點，一種比較好的 token 分配方法是將整個 Hash 空間分成 Q 等份， Q >> S ， token 分配維持每個節點分配 Q/S 個 token 的特性。當節點 下線時，需要將它所服務的 token 分配給其它節點，從而保持每個節點包含 Q/S 個 token 的 特性；同樣，當新節點上線時，也需要 從集群中已有的節點獲取 token 使得最終維持每個節 點 Q/S 個 token 的特性。 第一種 思路需要工作機通過 heartbeat 定時將讀、寫個數，磁盤，內存負載等信息 發送 給主控機，主控機根據負載計算公式 計算出需要遷移的數據放入到遷移隊列中等待執行 。 負 載平衡的時候需要注意控制節奏，比如一臺工作機剛上線的時候，由于負載最輕，如果主控 機 將大量的數據遷移到新上線的機器，由于遷移過程不能提供寫服務，整個系統的對外表現 性能會因為新增機器而變差。 一般來說，從新機器加入到集群負載達到比較均衡的狀態需要 較長一段時間，比如 30 分鐘到一個小時。 3.6 Chubby Chubby 是 Google 的 Paxos 實現， Paxos 靠譜的實現不多， Chubby 毫無疑問是做的最優秀的 。 Chubby 通過類似文件系統接口的方式給用戶暴露分布式鎖服務。 我們先看看應用是如何使 用 Chubby 服務的。 在 GFS/Bigtable 論文中，我們至少能夠看到有如下幾處 使用了 Chubby 。 1, Master 選舉。 Master 宕機時， 與 Master 保持強同步的 Slave 切換為 Master 繼續提供服務。 在這個過程中， Master 和 Slave 都定時向 Chubby 請求成為 Master 的鎖， Master 鎖有一個 Lease 的期限，如果 Master 正常，一定會在 Master 鎖沒有過期的時候申請延長鎖的時間，繼續提 供服務。當 Master 宕機且鎖的 Lease 過期時， Slave 將搶到 Master 鎖 切換為 Master 。 2, tablet 服務。為了保證強一致性，一個 tablet 同一時刻只允許被一個 Tablet Server 加載 提 供服務。每個 tablet server 啟動時都向 Chubby 服務獲取一個鎖，每當 Master 發現 tablet server 出現異常時，它也嘗試獲取該 Tablet server 的鎖。 Master 和 Tablet Server 二者只有一個節點 能夠獲取到鎖，如果鎖被 Master 獲取，可以確定 Tablet Server 已經宕機，此時可以將它服 務的 tablet 分配給其它機器。 3, 存儲 Bigtable 表格的 sche ma 信息。 由于 Chubby 可以認為是一個一致的共享存儲，并且 schema 的訪問壓力不大， Chubby 可以存儲 schema 信息。 我們再來看看 Chubby 內部大致是如何實現的。 Chubby 一般有五臺機器組成一個集群，可以 部署成兩地三機房，這樣任何一個機房停電都不影響 Chubby 服務。 Chubby 內部的五臺機器 需要通過實現 Paxos 協議選取一個 Chubby Master 機器，其它機器是 Chubby Slave ，同一時 刻只有一個 Chubby Master 。 Chubby 相關的數據，比如鎖信息，客戶端的 Sessio n 信息都需 要同步到整個集群，采用半同步的做法，超過一半的機器成功就可以回復客戶端。每個 Chubby Master 和 Chubby Slave 都希望成為 Chubby Master ， Chubby Master 有一個 Lease 期限， 如果 Chubby Master 正常，它將在 Lease 快到期的時候延長 Lease 期限，如果 Chubby Master 宕機， Chubby 集群內部將觸發一次 Paxos 選舉過程。 每個 Chubby Slave 都希望自己成為 Chubby Master ，它們類似于 Paxos 協議中的 Proposer ，每 個 Chubby 集群中的節點都是 Acceptor ，最后可以確保只有一個和原有的 Chubby Master 保持完全同步的 Chubby Slave 被 選取為新的 Chubby Master 。 當然，無論是 Paxos 選舉還是 Session ，鎖信息同步， Chubby 集 群內部機器故障檢測都遠沒有這么簡單，這里的實現也是筆者的揣測，如果有同學感興趣， 可以參考 Berkerly DB 中半同步（包括選舉過程）的實現，這部分代碼是由 Google 內部開源 出來的。 3.7 分布式事務 對于分布式事務，大多數情況下我們應該想的是如何回避它，兩階段鎖的方法不僅效率 低，而且實現特別復雜。 有的時候，我們需要和業務方一起探討如何規避分布式事務。 這里 我們會用到 流行的概念 BASE ， 即基本可用，柔性狀態，柔性一致和最終一致等。對一個 “ 基 本可用 ” 系統來說，我們需要把系統中的所有功能點進行優先級的劃分， 比如轉賬業務和淘 寶的收藏夾業務兩者對一致性的要求 肯定 是不同的。 柔性狀 態對用戶來說是一個完整的系統， 它的一致性是不允許有任何損失的，就是說用戶支付了 10 塊錢，那么他的帳戶上必然是只 扣掉了 10 塊錢；但是對于系統內 部的狀態，我們可以采用一種柔性的策略，比如說系統內 分布了 ABC 三個功能模塊，我們允許它們在某一時刻三個模塊的狀態可以不一致。我們會 通過業務和技術的手段，比如說異步機制或者批處理方式來保證系統通過柔性狀態一致來獲 得可用性。 目前底層 NOSQL 存儲系統實現分布式事務的只有 Google 的系統， 它在 Bigtable 之上用 Java 語言開發了一個系統 Megastore ，實現了兩階段鎖，并通過 Chubby 來避免兩階段鎖協 調者宕機帶來的問題。 Megastore 實現目前只有簡單介紹，還沒有相關論文。 在這個問題上， 我們只能說是 Google 的同學工程能力太強了，我們開發 NOSQL 系統的時候還是走為上策。 3.8 Copy - on - write 與 湡獨 Copy - on - write 技術在互聯網公司使用比較多，這時因為大多數應用的讀寫比例接近 10 : 1 ， Copy - on - write 讀操作不用加鎖，極大地提高了讀的效率，特別是現在服務器一般都 有 8 個或者 16 個核。 Copy - on - write 技術還帶來了一個好處，那就是 Snapshot 的時候不需要 停服務，而 Snapshot 功能對于分布式文件系統非常重要。 Copy - on - write 技術 在樹 形結構中比較容易實現，假如我們實現一個支持 Copy - on - write 的 B 樹，基本可以用來 作為 大多數管理結構的內部數據結構，比如 GFS 的 chunk 管理，文件 名管理， Bigtable 中的子表管理。 Copy - on - write 的示意圖如下： 的是建立一張全局的索引表，索引和數據相互獨立，這樣做的優點是可以根據索引直接定位 到主鍵，缺點是 索引維護成本較高。 對于給定主鍵或者索引 列值 的查詢， 直接將請求發送到 相應的數據節點 ；否則，將請求發送 到所有的數據節點。與并行數據庫類似，由合并節點來生成 最終結果。 數據倉庫存儲子系統 處理機器故障問題， 可以采用 5.4 中的線上最終一致性系統實現。 大致的架構如下： M a s t e r S l a v e S l a v e D a t a S e r v e r G r o u p M a s t e r S l a v e S l a v e D a t a S e r v e r G r o u p M e r g e r M e r g e r M e r g e r M e r g e r 數 據 訪 問 中 間 層 R e a d c l i e n t R e a d c l i e n t R e a d c l i e n t C o n f i g M a s t e r U p d a t e r U p d a t e r C o n f i g S l a v e r e p l i c a t i o n H e a r t b e a t & C o n t r o l W r i t e c l i e n t W r i t e c l i e n t H e a r t b e a t & C o n t r o l W r i t e d a t a W r i t e d a t a G e t d a t a l o c a t i o n G e t d a t a l o c a t i o n H e a r t b e a t & C o n t r o l H e a r t b e a t & C o n t r o l 如上圖， 通過 Updater 節點將數據寫入數據節點，數據節點 按照 Data Server Group 的形式組 織， 通過 Master/Slave 備份來保證可靠性 ，同一個 Data Server Group 中 Master 出現故障后 由 Slave 接替其繼續提供服務，保證可用性。 客戶端的查詢操作在 Merger 節點上執行，它 合并相應 Data Server Group 中的數據分片并進行 limit, order by, group by 等操作。 當出現負 載不均衡時， Config Master 將指導數據分片從負載高的 Data Server Group 遷移到負載低的 Data Server Group 。 8 應用 本章講述筆者對于一些典型應用的存儲問題的理解，這里必須聲明：任何一個應用涉及的知 識都遠超過筆者的能力范疇，后續的內容只是闡述個人很膚淺的理解，漏洞很多，請諒解。 8.1 電子商務類 阿里巴巴引領著電子商務的方向。以淘寶為例， 淘寶面臨的存儲相關問題包括 賣家商品， 交易信息， 用戶信息，用戶評價， 用戶收藏，購物車 ，圖片 等等，并且 淘寶累積存儲了 不同 業務系統收集的 海量 業務數據，比如 訪問點擊、交易過程、商品類目屬性以及呼叫中心客服 內容等 。 淘寶大多數存儲系統的特點是：數據量大，記錄條數特別多， 單點記錄不大， 讀寫比例 高 ，且可能要求事務。 由于訪問量特別大，以前采用 Oracle + 小型機的解決方案，對于不 需要事務的需求，可以通過 Mysql sharding 的方式實現 。 我們正在做的 Oceanbase 系統 巧妙 地 利用讀寫比例大且單條記錄一般比較小的特點， 將動態更新的數據放在 單機 內存中并通過 強同步保證可靠性及可用性，動態數據定期與靜態數據合并。 淘寶的小文件 存儲系統 TFS 已經開源了，目前主要是用來存儲海量圖片文件。 淘寶 TFS 處理百億級別的圖片存儲，數據量 PB 級別， 這個問題屬于 5.4 中提到的線上最終一致性系 統的范疇， 不過通用系統的解決方案過于復雜，性價比不高。于是，淘寶天才的工程師們利 用圖片應用的特點設計了通用的 小文件存儲系統 TFS ( TFS 開源 ) 。 圖片存儲系統 的特點主要有 兩個 ： 1, 用戶 一次性準備好文件所有數據 并 提交到文件系統，每個文件打開后一次性寫入所 有數據并關閉； 2, 用戶不關心文件的名字， 用戶不會指定某個文件進行寫操作， 可以等到 文件寫成功 后生成文件名并由客戶端保存。 TFS 利用這兩個特點大大地簡化了文件系統寫流程和元數據管理服務器的設計，而這也 正是海量文件系統最為復雜之處。 淘寶是一個開放、共享的數據公司，還通過數據倉庫提供各種數據給客戶。 目前使用了 Oracle RAC 集群提供服務，當然，也通過 Hadoop + HIVE 進行一些線下的預處理。 淘寶的主搜索其實是一個實時搜索， 賣家 更新的商品信息需要秒級別反映到用戶的搜索 結果中。 淘寶的主搜索是很靈活的，可以根據 商 品類別，賣家名稱，商品屬性等進行搜 索， 因此，主搜索的存儲系統需要建立不同維度的索引信息， 主搜索使用內部的 iSearch 產品， 機器被分成 56 組，每組 14 臺，組內機器存儲相同的數據。 商品更新 發生在 Oracle 商品庫 中 ， 并以異步的方式同步到主搜索 索引 系統。 8.2 搜索類 搜索類公司的核心競爭力 ，或者說 互聯網公司的 核心競爭力都 可以認為 就是數據以及對 數據的處理 能力，比如商業價值挖掘，用戶意圖挖掘等。 搜索類最成功的當然就是 Google ， 它能取得現在的成功很大程度上得益于底層的 GFS/MapReduce/Bigtable 等 帶來的大規模數 據處理能力。 搜索 流程大致包括： 抓取、數據分析、建立索引 及 索引服務 。 通過 spider 將網頁抓取過 來后存儲到本地的分布式存儲系統 ，即網頁庫中。 網頁庫的業務邏輯并不復雜，無非就是對 某一個網頁或者一批網頁， 如某個域名下的所有網頁的查詢 ，刪除一批網頁或者更新網頁相 關的信息，比如權重等。 但是網頁庫的數據量太大，假設需要處理 500 億網頁，每個網頁平 均存儲大小為 5 0KB ， 那么，網頁庫的 大小為 50GB * 50KB = 2.5PB ，這已經 遠遠超出了關系 型數據庫的處理能力。 網頁庫應用為半線上應用，采用 GFS 加 Bigtable 的方案最為合適。不 過為了規避 復雜性，可以簡單地將 網頁庫通過 Hash 的方法分布到多臺機器組成的分布式集 群中， 并通過支持 MapReduce 來進行 線下挖掘， Rank 調研等。 將網頁庫的內容進行 一系列的處理，比如計算 PageRank ，網頁去 重，最終將生成倒排 表用于 線上服務。 搜索命令的處理大致分成兩步：第一步從倒排表中找出匹配的網頁索引 信息，第二步根據索引信息從網頁庫中獲取網頁內容。 倒排表有一個特點就 是讀取量 特別大， 要求延遲很小，且 倒排表一般是定時生成的，也就是說，倒排表中的數據基本是靜態的 。 倒 排表的 問題域和存儲系統有些差別，這是因為 每個關鍵詞對應的網頁信息非常多， 需要分散 到多臺機器以便 后續的計算。因此 ，主流的搜索引擎一般將機器分成多個 group ，每個 group 可能包含幾十臺機器，存儲相同的數據 ，每個查詢請求都發送到 所有的 group ，每個 group 中選擇一臺機器 進行計算，計算 完成后合并最終結果。 8.3 社交類 ? IM 類 IM 類應用需要存儲的數據有兩類：用戶數據及消息數據。 用戶數據 的存儲比較簡單 ， 假設每個用戶的信息為 10K ，有 10 億用戶，用戶數據量為 10K * 1 GB = 1 0 TB ，可以使用 5.4 中的線上最終一致性系統方案或者 專用的根據用戶 id 進行數據劃分的方案。 消息 分為兩種， 在線消息和離線消息 ，其中，離線消息存儲時一個必要的功能，而在線 消息是一個 plus ， 它和離線消息在數據量上有巨大差距， 可以選擇不在服務器端存儲 。 個人 消息和群消息也有一些區別。 個人消息處理比較簡單， 而群的消息處理 和 SNS 中訂閱好友 動態 有些類似。 SNS 中用戶更新動態時 ，系統會將這個動態更新 推送給用戶的所有好友，而 在 IM 中，用戶往群里面發送一條消息，有兩種處理方法：第一種方法是推送給群里面的所 有用戶，第二種方法是直接保存到群中。 采用第一種方法 群 消息的數據量會增大很多倍， 采 用第二種方法減少了群消息的數據量，不過幾十上百個用戶同時讀取群消息，即使群消息是 順序 存儲的，最后 在磁盤上 也變成了 隨機跳讀。 另外一種折衷的方案是對在線用戶采用第一 種方法，離線用戶采用第二種方法，即只將群消息推送給在線用戶， 離線用戶上線后 主動拉 取群 離線消息。 ? SN S & 微博客 前面已經提到了 SNS & 微博客 的消息推送功能 ，這是 通過將消息推送給所有的好友實現 的，可以開發一個 類似 Active MQ 的 支持發布 / 訂閱機制的消息隊列。 另外，微博客支持實 時搜索， 例如新浪微博中搜索關注人說的話， 這 和郵件系統的搜索類似，只需要對用戶訂閱 的消息進行字符串匹配。 微 薄中的一個難點問題是某些用戶被關注程度特別高， 如果采用推 送的方式 將 對系統產生很大的壓力， 個人認為可以采用推拉結合的方式。

總結

以上是生活随笔為你收集整理的分布式系统工程实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。