微信後台基於時間序的海量數據冷熱分級架構設計實踐

作者｜楊平安 編輯｜小智 本文將為你介紹，微信後台的一種基於時間序的海量數據冷熱分級架構。應對 PB 級數據、每天萬億級訪問、鍵值帶來的挑戰，微信技術團隊是這樣做的。

微信的後台數據存儲隨著微信產品特性的演進，經歷了數次的架構改造，才形成如今成熟的大規模分散式存儲系統，有條不紊的管理著由數千台異構機型組成的機器集群，得以支撐每天千萬億級的訪問、鍵值以及 PB 級的數據。

作為以手機為平台的移動社交應用，微信內大部分業務生成的數據是有共性可言的：數據鍵值帶有時間戳信息，並且單用戶數據隨著時間在不斷的生成。我們將這類數據稱為基於時間序的數據。比如朋友圈中的發表，或者移動支付的賬單流水等業務生成的數據都滿足這樣的特徵。基於時間序的數據都天然帶有冷熱分明屬性――這是由手機的物理特性決定的，它的尺寸有限的屏幕所展示的數據只能分屏，通過手指的滑動，平滑而又連續的沿時間軸依次訪問――通常是由最新生成的數據，慢慢回溯到較早前的數據。同時朋友圈等業務都是信息讀擴散的應用場景，這就意味著它們生成的後台數據具有讀多寫少的鮮明特徵。

在微信的實際應用場景中，這類數據的主要特點包括：數據量大、訪問量大、重要程度高等。這些特點在現網的實際運營過程中，給我們帶來了非常大的挑戰，主要包括：

• 數據量大，需求的存儲容量高――基於時間序的數據通常不會刪除，而是隨著時間不斷積累，數據量達到 PB 級別，相應需要的存儲空間也與日俱增；

• 訪問量大，節日效應明顯――基於時間序的數據往往是熱點業務生成的數據，它們的訪問量居高不下，基本維持在每分鐘數十億次的級別。尤其是在節日期間，瞬發訪問量更可達平日的三至五倍；

• 重要性高，用戶感知明顯，數據一旦丟失，導致用戶不能正常使用產品，並因此而轉化成的投訴率高。

通過堆機器來橫向擴展存儲自然可以應對如上的各種挑戰，然而在成本預算緊張的前提下，機器數目是有限的。在這種情況下，基於時間序的海量數據的冷熱分級架構便應運而生。該架構正是為了應對後台日益膨脹的這類數據，本著充分利用機器資源，發揮各種硬體介質特長的原則，結合數據的冷熱分明、讀多寫少的訪問特徵而開發和設計出來的。它基於數據分層的理念，根據不同時間段的數據在訪問熱度和數據量上的差異，定製不同的服務策略，在縱向上擴展存儲的邊界。橫向擴展存儲是易於理解的，通過向原集群中增加相同類型的機器――其中必然涉及到一輪歷史數據的遷移――最終新舊機器負載均衡，彼此之間並無差異的對外提供服務。在這種方案下，數據橫向流動，系統一視同仁的對待，顯然並無因地制宜思想的容身之所。而縱向擴展存儲的架構便提供了這樣一種思路：

對熱點數據，數據量少，但承擔的訪問流量大，我們當然是希望它們能常駐內存，因此系統提供了有強一致保證的內存層，在應對突發流量時，也可在不涉及歷史數據遷移的前提下，單獨、動態的快速擴展內存層。

對歷史數據，數據存量大，但承擔的訪問量非常有限，我們當然是不希望用昂貴的固態硬碟來存儲它們，因此，系統提供了廉價的機械盤層，並且有一套透明的冷數據剝離和批量下沉的流程，將存儲層中歷史數據源源不斷的抽離到機械盤層。

通過這樣的一種縱向分層、單獨擴展的思路，即為我們系統提供了極大的靈活性，解決了節日期間存儲層面臨的內存瓶頸，以從長遠的角度為我們緩解了成本壓力，解決了存儲層面臨的磁碟容量瓶頸。

當然一套成功的大型分散式系統僅有這些是不夠的，還必須包括數據多副本複製策略以及分區演算法等，也要有能應對複雜的現網運營環境的能力。我們結合各層的服務特點，制訂了相對應的數據強一致演算法，如內存層通過版本號控制來保證與存儲層的完全一致，存儲層通過 Paxos Group 實現多副本容災，而機械盤層則通過串列寫來保證。我們同時也實現了自己的去中心化的數據路由演算法，確保了數據和流量的均勻分佈，並且保證這種特性在橫向擴展后依然成立。

通過如上工作的努力，環環相扣，我們的基於時間序的海量數據的冷熱分層架構成功的應對了 PB 級數據、千億級訪問以及萬億級鍵值帶來的挑戰。

本文提及的海量數據的冷熱分級架構是專門服務於基於時間序的數據，它們主要特徵為：

a). 數據鍵值帶有時間戳信息 ;

b). 單用戶數據隨著時間在不斷的生成。

我們設計的架構強依賴於特性 a)，各個環節基本上是依賴於鍵值中的時間戳來分發數據或者進行數據排序的。至於鍵值中的時間戳如何生成、全局是否維持統一時間、如何維持等則不在本文的討論範圍，通常這由前端的業務特性以及後台的時間伺服器策略決定的。

而特性 b) 則保證了本架構的必要性、實用性。如果數據規模有限，以用戶的賬戶信息舉例，它就像我們日常生活中的戶口本，它只有一份，對單用戶而言不會新增。則我們通常用固定的機器集群存儲就可以，並且鮮有變更。而我們要處理的是用戶的日記本、或者記賬簿，它們每天都在不斷生成新數據。

我們以現網某個集群的實例情況舉例，說明下此類業務數據有如下的特點：

1.、數據量大，PB 級數據，萬億級鍵值，並且在源源不斷的生成中，然而新生成的數據相較於歷史存量數據佔比小。下圖展示了該集群數據在各時間段的一個佔比情況。

2、訪問量大，峰值可達每分鐘數十億次訪問，尤其是在節日期間，用戶高漲的熱情更可以轉化成平日三至五倍的訪問量。同時具有冷熱分明、讀多寫少 (讀寫比例甚至可達 100：1) 的訪問特徵，比如節日期間倍增的訪問通常是對節日期間生成的新增數據的訪問。下圖展示了該集群訪問在各時間段的一個佔比情況。

3、數據安全性要求高，這類數據通常是用戶感知敏感數據，一旦丟失，轉化成的用戶投訴率高。

系統由三個層次組成，如圖所求，分別是內存層、存儲層（熱數據存儲層）以及機械磁碟層（冷數據存儲層）。從時間軸上看，它們服務的數據由熱至冷。如下圖所示：

從客戶端的角度看，三層都是並列的，客戶端都會直接的與某層中的某台機器發生通信。具體的區別點在於，內存層和機械磁碟層對客戶端而言是只讀的。所有的寫都是由客戶端直接寫向存儲層。我們將去中心化的配置分發到客戶端機器上，配置的類型包括內存層路由、存儲層路由以及其它元數據，客戶端根據配置中的時間分隔點以及流量比例，來決定將當前的讀請求分發到內存層還是存儲層的具體機器上。配置支持快速分發和動態載入，可以在秒級實現更新。

機械磁碟層的路由對客戶端而言是透明的，存儲層保存了下沉到機械磁碟層的數據鏈接，鏈接包含了文件編號、內部偏移和大小，而客戶端對此是不知情的。當已下沉數據的讀請求分發到存儲層機器上時，存儲層會計算出該數據各副本在冷數據存儲層對應的機器地址，然後將它和文件鏈接一起回復給客戶端。客戶端再按照隨機的策略在多副本之間選擇一份讀取，從這個角度看，冷數據存儲層對客戶端而言更像個遠程文件系統，而 inode 信息和路由表是放在熱數據存儲層的。

下面我們再詳細的分析各層的設計策略。

內存層從表現上更像是一個緩存代理，然而普通的緩存在處理數據有效性上是乏力的。常見的策略如寫時淘汰，每次寫存儲層之前，都先清理掉緩存中相應的數據，確保失效。然而數據在緩存中通常也是多副本的，這個方案即無法處理網路分區錯誤，並且寫時淘汰也會產生多次 RPC 請求，過份的消耗系統資源。另外一種常見策略是有限的數據一致性，即過時淘汰的策略。在將數據寫入緩存時，會附帶一個有效時間，在這個有效期內，該數據一直被認為是正確的，並不關心真實情況是如何的。這種緩存只能應用於對數據實時性要求不高的服務。對微信的敏感業務而言，我們更需要能保證數據強一致的分散式緩存。

我們通過版本號來實現了這一目的。我們為緩存中的每一份數據都維持了一份版本號，存儲層中相應的也有一份。只有當緩存中的版本號與存儲層的版本號達到一致時，才會認為緩存中的數據是有效的。所以，客戶端每次對內存層的讀請求，都會由緩存層相應的產生一次讀請求發到存儲層。在一次 RPC 請求中完成有效性的識別以及過期數據的更新。

從直覺上看，採用這種方案的強一致緩存並沒有降低存儲層的訪問壓力。因為客戶端對緩存層的請求，與緩存層對存儲層的請求是 1：1 的。然而這個方案點的關鍵在於，我們成功的疏解了存儲層的內存瓶頸。將存儲層緩存數據的功能，轉移到緩存層的內存上。我們現在對存儲層的要求就是能夠盡量的緩存更多的版本號，提供高效的版本號訪問能力就可以了。從這種意義上來看，這個強一致性緩存就是存儲層內存的延伸。因此，我們將它稱為內存層。它的優勢在於可動態的調整流量比例，並且可以在訪問高峰期快速的擴容。後面的章節我們也描述了如何通過工程手段優化版本號交互帶來的資源消耗。

為了系統的健壯性，一些異常情況也是需要考慮的，如果一台內存層機器突然離線，會有數十 G 的緩存數據失效，我們當然不會希望這數十 G 數據的壓力，會全部的落到一台存儲機器的磁碟上。――這無疑會引起系統的抖動。因此，我們按照組的方式來部署了內存層。每組有多台機器。一份數據可能在這多台機器內有多個副本。客戶端通過隨機的次序訪問這些機器。這樣就儘力避免了單結點失效對整個系統的影響。

我們在內存層中設計了簡單、輕量的支持變長數據的緩存結構。每台機器包含數十條 LRU 鏈，每條鏈都是一個共享內存形式的一維數組。所有的數據都追加寫在數組的最新位置，到尾部后就從頭開始循環。自然，這樣的結構需要一個索引來記錄數據的位置。這種方式固然浪費一些內存空間，但避免了內存的動態分配。

存儲層在整個系統架構中處於核心的位置。內存層和機器硬碟層都依賴於它的實現。前文提及，提供高效輕量的版本號訪問能力是強一致內存層實現的關鍵。同時，源源不斷的將冷數據下沉到機械硬碟層的需求，就暗示了在存儲層必須有這樣一種特性：冷數據是易於從所有數據中剝離，並且收集的。――這樣就意味著，如果在存儲層中數據是平坦的，冷熱數據混雜在一起，那麼我們在抽離冷數據的時候，就要把硬碟中所有的數據遍歷一輪，無疑會消耗比較多的系統資源。

因此我們採用了 lsm-tree 演算法來實現這一需求。該演算法和 B+ 樹一樣是種建立索引的技術。不同的是它基於多組件 (C0\C1 等組件)，通過延遲提交和歸併排序的方式，將 B+ 樹的隨機 IO 轉變成了內存操作和順序 IO。在我們的訪問模型下，所有的寫都是熱點數據，只會提交到 C0 組件。然後在適當的時機，同 C1 組件中的數據進行多路歸併排序。通過該演算法，我們可以同時實現數據分層和數據有序的目的。

Leveldb 是 Google 公司開源的存儲引擎庫，它正是基於 lsm-tree 演算法的思想開發出來的。因此，我們復用了它成熟的數據結構組件，如日誌格式、數據文件格式、內存表格式等。然而它其中的一些運行時策略，卻會給我們的現網運營帶來麻煩。比如說運行時不受限的 compact 策略、數據文件索引的懶載入等，會觸發不可控的讀盤，造成服務的抖動；同時大量的動態內存分配也會對機器的內存使用帶來一定不可控的因素。因此，我們拋棄了這些運行時行為，定義了自己的管理策略，使系統變得更加可控。同時，我們利用不同數據的訪問差異，對冷、熱數據的存儲進行了各自的定製，按照時間段定義按塊壓縮的粒度、索引的粒度等，行之有效的調和了 CPU、內存、磁碟容量、磁碟 IO 等系統資源之間的轉換關係。

冷數據的鏈接和冷集群的路由表，都是記錄在存儲層中而對前端不可見的。具體的設計思想，我們在下節中詳述。

機械硬碟容量雖大，但是 IO 性能低下，故障率高。一種常見的思路是冷數據存儲層獨立與熱數據存儲層，而對客戶端直接可見――客戶端持有一份冷數據存儲層的路由，並且獨自路由――這無疑是種簡單、易於理解的方案，但是在我們的應用場景中面臨著兩個問題：無法精確防空以及加劇機械硬碟層的 IO 緊張。

定義 TB 訪問量為每 TB 數據的每秒的訪問次數。在我們的應用場景中，每 TB 歷史數據的實際訪問量設為 N，則機械硬碟的服務能力僅為 N 的一半。如果冷數據存儲層獨立，則它需要自己維持所有的數據索引，而內存容量不足以支持數十 T 數據的索引，只能將索引落盤，則每次對數據的讀取都要帶來兩次隨機讀盤。因此，我們將冷數據索引以及冷數據存儲層的路由表，都放到了熱數據存儲層中，而對前端不可見。

為了容災，我們必須為每份數據存儲多份副本。如果採用雙副本方案，則系統需要冗餘 50% 的訪問能力，以應對另外一份副本失效的情況，在 io 瓶頸的前提下，這種方案是不可取的。因此我們採用了三副本方案，只要冗餘三分之一的能力。每份副本分佈在不同的園區，可以實現園區級的容災。

由於機械盤容量大、計算能力差，我們採用 NO RAID 的方式組織了盤組。為了更好的實現單盤失效導致數據丟失的故障的災后恢復，我們實現了同組三台機器在盤級別數據的完全相同。為了達到盤級別的負載均衡，我們通過預計算路由、硬編碼的方式，實現了 (數據 ->機器 ->盤 ->文件) 的單調映射，由數據的鍵值可以直接定位到盤的索引以及文件的編號。

作為機械硬碟層的補充，一個冷數據下沉的模塊是必須的，它作為冷數據存儲層的唯一 Writer，我們通過兩階段提交的方式確保了下沉過程的透明性，通過控制流程發起時機保證資源使用不影響現網服務，通過預佔位、串列寫入的方式，確保了數據在冷數據存儲層文件級別的完全一致。

業務要求系統必須保證在數據的多份副本之間保持強一致性。――這是一個歷久彌新的挑戰。我們將分內存層、存儲層、機械硬碟層分別來考慮數據的強一致性維持。

正如前文描述，內存層作為一種強一致性分散式緩存，它完全是向存儲層對齊的，自身無法判別數據有效性，本身多副本之間也沒有交互的必要。它對前端而言是只讀的，所有的寫請求並不通過它，它只能算是存儲層中數據的一個視圖。所以它對前端數據有效性的承諾完全是依賴於存儲層的正確性的。

我們基於 Paxos Group 實現了存儲層的數據一致性，通過採用無租約的方式，使得系統在保證強一致性的前提下達到了最大的可用性。Paxos 演算法是由 Lesile Lamport 在論文中首提的，它唯一的作用是在多個參與者之間唯一的確定一個常量值。――這點同分散式存儲沒有直接關聯的。我們在 Paxos 演算法的基礎上，設計出基於消息驅動的 Paxos Log 組件――每一條操作日誌都要 Paxos 演算法來確定，再進一步實現了基於 Paxos Log 的強一致性讀寫。

Paxos Group 因為採用了無主模型，組內所有機器在任一時刻都處於相同的地位。Paxos 演算法本質是個多副本同步寫演算法，當且僅當系統中的多數派都接受相同值后，才會返回寫成功。因此任意單一節點的失效，都不會出現系統的不可用。

強一致性寫協議的主要問題來源於 Paxos 演算法本身，因為要確保數據被系統內的多數派接受，需要進行多階段的交互。我們採用如下的方法，解決了 paxos 演算法寫過程中出現的問題：基於 fast accept 協議優化了寫演算法，降低了寫盤量以及協議消息發送、接收次數，最終實現了寫耗時和失敗的降低；基於隨機避讓、限制單次 Paxos 寫觸發 Prepare 的次數等方法，解決了 Paxos 中的活鎖問題。

強一致性讀協議本身和 Paxos 演算法並沒有太大的關係，只要確認多副本之間的多數派，即可獲取到最新的數據。我們通過廣播的方式獲取到集群中多數機器（包含自身）的 paxos log 的狀態，然後判斷本機數據的有效性。

當系統中的單機節點失效，數據完全丟失的時候――這種情況是可以算是 Paxos 演算法的盲區，因為該演算法基於所有的參與者都不會違背自己曾經的承諾，即拜占庭失敗而導致的數據不一致。――而這種情況在現網運營中可謂是常態，因此，我們引入了 Learner Only 模式。在該模式下故障機只接收已提交的數據，而不參與 Paxos 協議的寫過程，意即不會因數據丟失而違背任何承諾。然後通過非同步 catch up 和全量數據校驗快速從其它副本中恢複數據。

為了防止多節點同時失效，我們將數據的多副本分佈在不同園區的機器上。園區是同一個城市不同數據中心的概念。如此，我們的結構足以應對單數據中心完全隔離級別的災難。

因為對客戶端透明，冷數據下沉流程作為機械硬碟層的唯一寫者，則該層的數據一致性是易於實現的。我們通過三副本串列寫入、全部提交才算成功的方式來實現了多副本之間的數據一致性。

作為補充，冷數據集群為數據塊增加了 CRC 校驗和一致性恢復隊列，當單機數據不可用 (丟失或者損壞) 時，首先客戶端會跳轉到其它備份中讀 (三機同時對外提供讀服務)，一致性恢復隊列會非同步的從其它備份數據塊中恢複本機數據。

因為採用了 No Raid 方式組織的盤組，並且同組機器間盤級別數據文件一致，在單盤故障引發數據丟失時，只要從其它機器相同序盤中傳輸數據文件即可。

數據分區的主要目的是為了確保同層機器間的負載均衡，並且當機器規模發生變化后，在最終仍然可以達到負載均衡的一種狀態。

經典的一致性哈希演算法的初衷是為了健壯分散式緩存，基於運行時動態的計算哈希值和虛擬節點來進行定址。數據存儲與分散式緩存的不同在於，存儲必須保證數據映射的單調性，而緩存則無此要求，所以經典的一致性哈希通常會使用機器 IP 等作為參數來進行哈希，這樣造成的結果一方面是數據的落點時而發生改變，一方面是負載通常不均衡。因此我們改造了此演算法。

我們通過預計算虛擬節點隨機數的方法，生成了割環點同實體機器之間的映射表。該映射表最多可支持一千組的集群規模，滿足在任意組數情況下，實體機器間割段長度維持差異在 2% 以內；並且增加任意組數 (總組數上限不超過一千組)，變動后的實體機器間的割段長度依然維持差異在 2% 以內。我們將此映射表硬編碼，在運行時避免了計算的過程，數據根據鍵值哈希值定址時，只要經過一次二分查找即可獲取到對應的實體機器的編號。我們在內存層、存儲層以及機械硬碟層都採用了這個映射表，保證了數據在各層路由演算法的一致。在工程實現方面，我們可以合理使用這個特性來批量合併請求，以降低資源消耗，這在稍後的章節會有詳細描述。

組是數據分區的獨立單元，是虛擬節點對應的實體單位。組之間是互相獨立的。每組由多台物理機器組成，這是 Paxos Group 生效的基本單位。一份數據包括的多份副本分別散落在組內的各台機器上。為了在組內機器上保證負載均衡，我們同樣設計了一套演算法，規定了數據副本之間的訪問優先順序，前端會依優先順序逐一的請求數據，只要成功獲取，即中斷這個過程。然後我們再將副本按優先順序均勻的散落在組內機器上，如此即可實現組內負載的均衡。

靜態映射表是非常靈活的，在不達到組數上限的情況下，可以任意的增加一組或者多組機器。當然這個過程中一些數據的路由映射發生了改變，則就涉及到了歷史數據的挪騰。為了在挪騰的過程中不影響服務，保證數據依然可讀可寫，我們開發出了對前端透明的，基於遷移標誌位，通過數據雙寫和非同步挪數據的方式實現的安全的、可回退的數據遷移流程。

存儲層和機械硬碟層通過冷數據鏈接耦合在了一起。因為兩層使用了相同的映射表，那麼當存儲層因擴容而發生遷移時，那麼冷數據鏈接無疑也要重新定址，進行一輪重新定位。如果我們以單鍵值為粒度記錄冷數據鏈接和進行冷數據下沉，那麼在萬億鍵值的語境下，效率無疑是低下。因此我們設計了最小不變塊的演算法，通過兩階段哈希，使用中間的哈希桶聚集數據，將數據鍵值和冷數據存儲層的機器路由隔離開來。通過該演算法，我們可以實現：批量的轉存冷數據、熱數據存儲層批量的以塊 (block) 為單位記錄冷數據鏈接、當熱數據存儲層發生擴容時，塊 (block) 內的數據不因擴容被打散掉，而可以整體的遷移到新目標機上。

糟糕的工程實現可以毀掉一個完美的系統設計，因此，如何在工程實現的過程中，通過技術的手段，提升系統的表現，同樣值得重視。

內存層的設計嚴重依賴存儲層數據版本號的高效獲取，那自然是版本號請求全落在內存中就可以了。因此，針對這種情況我們為定長的版本號設計了一套極簡的、輕量的、行之有效的緩存――內存容量不足以支撐版本號全緩存。

它的數據結構只是一個二維數組，一維用來構建 hash 鏈，一維用來實現 LRU 鏈。每次讀或者寫都需要通過數組內數據的挪動，來進行更新。如此一來，我們就通過千萬級數目的 LRU 鏈群，實現了緩存整體的 LRU 淘汰。它具有定長，可共享內存搭載，進程重啟不丟失、內存使用率高等優點。

對系統伺服器而言，前端訪問過來的某個請求，其對應的邏輯操作都是串列的，我們自然可以梳理這個串列流程中的 CPU 消耗點進行優化。然而當主要的瓶頸被逐漸的消滅掉后，CPU 消耗點變得分散，優化效果就變得微乎其微了。因此，我們只能尋找其它突破點。

我們發現在存儲引擎、一致性協議演算法的實現流程中，邏輯操作步驟多，涉及到網路交互，硬碟讀寫等過程。因此，我們決定合併不同請求中的相同步驟，實現批量化操作，極大的優化了 CPU 消耗。

合併的代價即是耗時略有增加，我們通過快慢分離，只針對熱點數據請求中的邏輯操作進行合併，去掉了耗時中的不穩定因子，減少了耗時抖動。

既然單機的邏輯操作性能已經得到了極大的提升，那麼前後端的網路交互階段，包括接入層的打包解包、協議處理等環節，成為了資源的主要消耗點。參考批量操作的經驗，我們同樣使用批量化的技術來優化性能――即將後台訪問過來的單條請求 (Get) 在內存層聚合成一次批量請求 (Batch Get)。

因為每個數據都是根據鍵值單獨進行路由的，如果要進行請求合併，我們就必須確保同一個批量請求內的數據，都會定址到相同的 Paxos Group 上。因此，我們必須在內存層將落到同一台存儲機器上的 Get 請求聚合起來。我們首先在內存層和存儲層採用了相同的路由演算法，然後將內存層的組數同存儲層的組數進行對齊，來完成了這一目標。

在設計的階段，我們充分的調研了業界的各類方案，大到系統的整體架構，小到具體的技術點。各種方案自有應用場景、各有千秋，不能單純以好壞區別，我們同樣基於自己的業務場景，謹慎的選擇合適的方案，或者棄而不用。在此盡量敘述。

處理 SNS 類業務生成的數據，業界有多種的冷熱分離架構可以參考。我們以 Facebook 的 Cold Storage 系統舉例而言，它也是基於冷熱分層的想法，設計出了服務它們照片業務數據的存儲方案。不同的是它採用了軟硬體結合的方法，一方面定製專門的伺服器（包括硬碟、電源等）和數據中心，一方面降低冷數據的備份數、增加糾刪碼等手段。

然而它們的經驗我們是無法徹底套用的，主要兩種原因：我們可使用的機器機型是固定的，不存在自己定製硬體的條件。同時它處理的是照片這種大 value 的數據。而我們基本上是文本這種類型的小 value 數據。從前文提及的 TB 訪問量角度來看，它們處理的數據是容量瓶頸的，而我們處理的是 IO 瓶頸的，可以算是不太冷的冷數據帶來的挑戰。所以，我們只能實現自己的冷數據管理策略。

同樣，業界有諸多關於如何實現數據一致性的方案。包括我們微信自研的 Quorum 協議，它是一種 NWR 協議，採用非同步同步的方式實現數據多副本。即然是非同步同步，那在多副本達到最終一致，必然存在一個時間差，那麼在單機出現離線的情況下，就會有一定概率導致數據的不可用。而我們追求的是在單點故障下，所有的數據都保證強可用性。

因此，我們採用了無主的去中心化的 Paxos Group 實現了這一目標，其中非租約是 PaxosStore 架構的一個創新亮點。在故障時通常系統是抖動的，會有時斷時續的狀況，常見的租約做法在這種場景下容易出現反覆切換主機而導致長期不可用，而 PaxosStore 的非租約結構能夠輕鬆應對，始終提供良好的服務。PaxosStore 核心代碼正在整理開源當中，預計四季度會正式發布，同時該項目的底層框架也基於我們已開源的協程庫 github.com/libco。

作者介紹

楊平安，12 年加入騰訊，在微信技術架構部的基礎平台組負責存儲系統的開發。先後參與了 QuorumKV\PaxosStore 等項目，伴隨微信存儲成長。一路起來，見證了微信存儲架構的演變。

Java 老矣，尚能飯否？