Schemaless架構(二):Uber基於MySQL的Trip資料庫

ber的Schemaless資料庫是從2014年10月開始啟用的，這是一個基於MySQL的資料庫，本文就來探究一下它的架構。本文是系列文章的第二部分；第一部分是關於Schemaless的設計。

在《Mezzanine項目——Uber的超級大遷移》一文中，我們描述了如何將Uber的核心trip數據從一個單獨的Postgres實例遷移到Schemaless這個可擴展與高可用的資料庫中。然後對Schemaless進行了簡單介紹，包括其發展決策過程、整體數據模型，並介紹了Schemaless的trigger與索引等功能。 本文將概述Schemaless的架構。

Schemaless簡介

回顧一下，Schemaless是一個可擴展的容錯資料庫，其數據的基本單位被稱為單元（cell），它是不可變的，一旦寫入，便無法被覆蓋（在特殊情況下，我們可以刪除舊記錄）；單元可以被行鍵（row key）、列名（column name）和引用鍵（ref key）引用；單元內容通過編寫引用鍵更高的新版來執行更新，但行鍵和列名保持不變。Schemaless不對其中存儲的數據執行任何操作（故而命名schemaless）。從Schemaless的觀點來看，它只負責存儲JSON對象。Schemaless有著獨特的模式，它支持最終在單元欄位保持一致的高效二級索引。

架構

Schemaless有兩種節點：工作節點和存儲節點，可以放在同一個物理/虛擬主機上，也可以放在分離的主機上。工作節點接收客戶端請求，將其分發到存儲節點中，再將結果聚合起來。存儲節點存放數據的方式使得在同一個存儲節點上進行單個或多個檢索速度很快。我們將這兩種節點類型分開，分別進行擴展。Schemaless的基本結構如下：

工作節點

Schemaless的客戶端與工作節點通過HTTP端點通訊。它們向存儲節點發出路由請求，並將從存儲節點獲得的結果進行聚合（在需要時），同時處理後臺任務。對於進展緩慢或出現故障的工作節點，客戶端資料庫將嘗試連接到其他主機並重試請求。對Schemaless的寫入請求是冪等的，因此每次請求重試都是安全的（這個性能真的很棒）。客戶端資料庫利用了這個功能。

存儲節點

我們將數據集劃分成固定數量的分片（一般配置為4096），然後將其映射到存儲節點上。根據單元的行鍵，將單元與分片一一對應。複製每個分片到存儲節點的可配置數量。總體來講，這些存儲節點構成存儲集群，每個存儲集群包含一個主（master）、兩個輔（minion）。Minion（也稱為副本）會分布到多個數據中心中，提供數據冗餘，以防災難性的數據中心宕機。

讀取和寫入請求

一旦Schemaless用作讀取，比如讀取單元或查詢索引時，工作節點能夠從集群的任意存儲節點中讀取數據。每次請求是從master還是minion的存儲節點中讀取是可配置的；默認是讀取master存儲節點的數據，也就是說確保客戶端能夠看到寫入請求的結果。寫入請求（請求插入單元）必須要在單元集群的master上執行。一旦master數據更新，存儲節點將更新異步複製到集群的minion上。

故障處理

分布式數據存儲系統有趣的一點在於它們處理故障的方式，比如在存儲節點未能響應請求時（無論master還是minion）。Schemaless在設計時，旨在將存儲節點無法響應讀取與寫入請求的失敗影響降到最低。

讀取請求

Master和minion的設置意味著：只要集群中有一個節點可用，就能滿足讀取請求。如果master可用，Schemaless就總能在檢索時返回最新的數據。如果master不可用，一些數據可能還未傳到minion，因此Schemaless可能返回過期的數據。然而在生產環境中，複製的延遲通常是次秒級的，因此minion的數據往往是最新的。工作節點在與存儲節點的連接中使用斷路器模式，以檢測存儲節點是否出現問題。用這種辦法，在出現故障時將讀取任務轉移到另一節點上。

寫入請求

一個minion宕機不會影響寫入；相應操作可以轉到master上去。不過如果master宕機，Schemaless仍會接收寫入請求，但會將這些請求存入另一個master（隨機選擇）的磁碟。這與Dynamo或Cassandra系統中的暗示移交（hinted handoff）十分類似。向另一個master寫入意味著在master恢復或者minion升級為master前，隨後的讀取請求都無法讀取這些新的寫入請求。事實上，在異步複製中Schemaless總是通過將寫入轉到另一個master的方式來處理故障；我們將這種技術稱為緩存寫入（buffered writes，下面會詳細描述）。

使用單獨的節點來接收寫入請求，優勢和劣勢都很多。一個優勢在於：寫入每個分片的請求可以整體進行排序。對於Schemaless trigger來說，這是很重要的性能，我們的異步處理框架（系列文的第一部分中提到過）可以從任意節點為分片讀取數據，同時確保同樣的處理順序。在所有集群的所有節點上負責寫入請求的單元都是一樣的。因此在某種意義上，Schemaless的分片可以看作是分區單元的修改日誌。

單master最突出的缺點在於，如果一個集群的master宕機，我們向別的master緩存寫入命令，但這些新的寫入內容是無法讀取的。這種麻煩情況的優點在於：Schemaless可以在master宕機時通知客戶端，因此客戶端會知道新寫入的單元不再是立即可讀的了。

緩存寫入

由於Schemaless使用MySQL異步複製，在master收到並留存寫入請求，然後還沒來得及將其複製到minion前，便出現了故障（比如硬碟驅動器故障），這個寫入請求就會丟失。為了解決這個問題，我們使用了一種技術，名叫緩存寫入。通過寫入多個集群，將數據丟失的風險減到最低。如果一個master宕機，後續的讀取任務無法迅速執行，但請求存續卻不受影響。

通過緩存寫入，當工作節點收到寫入請求時，會將請求寫入兩個集群：次級集群和主集群（按次順序）。只有兩者都執行成功的情況下，系統才會通知客戶端寫入成功。見下圖：

在後續讀取中，數據應當在主集群的master中。如果在異步MySQL複製將單元複製到主集群的minion前，主集群的master就宕機了，那麼就將次級集群的master用作臨時數據備份。

次級集群的master是隨機選擇的，轉移的寫入命令將進入特殊的緩存表格。後臺job會監控主集群的minion，查看單元的出現時間；然後才會將相應單元從緩存表格中刪除。設置次級集群代表著需要將所有數據至少要寫入兩個主機。此外，次級集群的數量也是可配置的。

緩存寫入用到了冪等性；如果一個行鍵、列名和引用鍵相同的單元已經存在，寫入就會被拒絕。冪等性意味著只要單元的行鍵、列名和引用鍵不同，就會在主集群的master恢復運作時寫入原master。另一方面，如果緩存了多個行鍵、列名和引用鍵相同的寫入請求，那麼只有一個能夠成功；在主集群恢復時，剩下的請求都會被拒絕。

將MySQL用作存儲後端

Schemaless的強大（與簡單）大多是因為我們在存儲節點中使用了MySQL。Schemaless本身是一個在MySQL之上相對較薄的層面，負責將路由請求發送給正確的資料庫。通過使用MySQL索引，並將build緩存到InnoDB中，單元和二級索引的查詢速度很快。

每個Schemaless分片都是獨立的MySQL資料庫，而每個MySQL資料庫伺服器包含一系列MySQL資料庫。每個資料庫包含一個單元的MySQL表格（叫做單元表），而每個二級索引也有一個MySQL表格，另有一組輔助表格。每個Schemaless的單元就是單元表中的一行，定義如下：

added_id列是一個自動遞增的整數列，也是單元表的MySQL主鍵。將added_id作為主鍵，可以讓MySQL在磁碟上線性寫入單元。此外，將added_id作為每個單元的獨特指針，Schemaless trigger可以按照插入的時間順序來有效地提取單元。

而row_key、column_name和ref_key分別代表Schemaless單元的行鍵、列名和引用鍵。為了通過這三欄進行有效地查詢，我們為這三列定義了一個複合MySQL索引。這樣一來，我們就能根據指定的行鍵和列名有效地找出所有單元了。

內容列中包含每個單元的JSON對象，以壓縮的MySQL blob（二進位大對象）表示。我們嘗試了各種編碼和壓縮算法，最終由於壓縮速度和大小選用了MessagePack和ZLib（在後面的文章中，我們會詳細進行描述）。最後，created_at列是單元插入的時間戳，可供Schemaless trigger用來查找指定日期的單元。

通過這種設置，客戶端可以控制模式，而無需修改MySQL的布局；查找單元更有效率。此外，added_id列使得寫入命令以線性執行，因此我們能夠將數據視作分區日誌來訪問，達到高效。

總結

如今的Schemaless是Uber基礎架構大量服務的生產資料庫。我們的很多服務都極其依賴這個高可用性和可擴展的Schemaless。