大家在日常工作中可能會經常遇到系統更新迭代與集群重建等需求，不可避免會涉及到服務的遷移更換操作。針對不同場景和訴求，具體的處理方式會不太一樣，但大致的思想和方法還是具有一定的普適意義。本文主要想和大家分享一下團隊最近經歷的在保障大數據高并發、低延時、高吞吐讀寫的同時，如何不停機地在 AWS 上更換關鍵大數據服務的實踐，供感興趣的同學參考。

類似在飛機高速運行的過程中完成更換關鍵引擎這個高難度動作

背景與挑戰

筆者就職于 FreeWheel，是一家擁有完整廣告管理解決方案，為客戶提供互聯網視頻廣告的投放、監測、預測、增值等關鍵服務的公司，目前正在被 90% 以上的美國主流電視媒體和運營商使用。

這次涉及集群重建的關鍵大數據服務是 Aerospike， 它是一個高性能、可擴展、可靠性強的 NoSQL 解決方案，作為 KV 存儲支持 RAM 和 SSD 存儲介質，并專門針對 SSD 有相應的特殊優化，目前廣泛應用于實時競價等實時計算領域。它在 FreeWheel 要求高并發、高性能、高可靠性的廣告實時投放階段扮演著重要的角色。由于公司業務場景的需求且數據服務原有的 XDR 功能 (類似 replica sync 的功能) 耗時長、成本高、無法支持數據服務的版本升級等現狀，所以我們需要在 AWS 的多個 region 上重建整個 Aerospike 集群， 線上重要的業務服務（廣告投放、預測與用戶畫像實時服務的所有流量）需要全部切到對應的新集群上。

重建和更換過程正值美國瘋狂三月各種賽事階段，面臨如下挑戰和需求：

• 對 Aerospike 實時并發百萬級的讀與寫操作需求；
• 舊集群已有的上百億條的記錄和幾十 T 數據量；
• 更換過程中不能有數據服務停機時間（停機會極大影響平臺線上廣告投放）；
• 新集群的數據不能有錯漏；
• 更換時間越短越好，節省雙集群并存帶來的成本。

如何設計不停機的更換方案？

總體設計

那么如何設計這樣一個關鍵大數據服務不停機無縫切換的方案呢？

通常對于非大數據場景，非常直接的想法就是，在 backup 和 restore 數據到新集群的過程中，暫停寫入（Ingestion）端數據的寫入，當新集群數據 restore 結束后再打開 Ingestion 端的寫入，并且直接寫入到新集群，然后用新集群來服務線上即可。

但這個思路對于大數據場景就不太適用了。由于舊集群的數據量大，據 SRE 同學以往的操作經驗，backup + restore 這部分數據到新集群大約需要一個星期左右，而 Ingestion 端數據也在每秒百萬級寫入的量級。直接停掉 Ingestion 端、試圖減少新舊集群數據的變化和干擾的方法看上去不太現實，因為會嚴重影響關鍵業務數據在線上的使用，對客戶的業務和廣告實時投放產生影響。

所以我們需要在同時保障數據服務大量寫入和讀請求的情況下另辟蹊徑，以下是我們的思考和設計：

持續雙寫 + 主從集群靈活切換

在集群數據開啟 backup 的那一刻開始，到新集群經歷 restore，對齊新舊集群的數據至切換完成，再到舊集群最終下線，一直持續向新舊集群雙寫（圖上① ② ） Ingestion 端進入的數據。

另外在 Ingestion 端寫入數據時，業務上需要先從集群中讀取舊數據然后進一步和新數據 merge 后再寫回集群，所以在持續雙寫過程中，會存在主從集群的角色轉換，其中主集群負責線上的寫入與讀取，而從集群主要是保持數據的同步：

• 階段 1：在數據對齊前，由舊集群擔任主集群角色，新集群進行快照的 restore 和同步寫入；
• 階段 2：兩個集群的數據對齊后，由新集群擔任主集群角色，而舊集群繼續保持數據的同步寫入。

對齊后依然持續雙寫可以從流程上保證兩個集群的數據都不會丟，且系統一直擁有快速切換到舊集群的能力，來保證數據服務高可靠和切換過程中的永遠的 Plan B 準備。

充分利用數據服務特性

在數據寫入過程中，可以充分利用數據服務特性保證 Ingestion 端的數據擁有高優寫入覆蓋權限。之所以這么做是因為 Ingestion 端寫入同一個 key 的數據版本相對于 backup 和 restore 的數據一定是較新的版本，所以需要確保較新版本的數據不會被 restore 的快照里較舊的數據覆蓋。

這時可以充分利用 Aerospike 在 restore 過程中 unqiue 特性：“如果 key 在 Aerospike 里已經存在那么 restore 就不再向集群中寫入該條數據”， 來保證 restore 的數據不會覆蓋 Ingestion 端的最新數據版本。

加速新舊集群的數據對齊

首先我們看一下新舊集群數據不一致的區間發生在哪里，下面是一個集群切換的大致時序圖：

由時序圖可直觀看到，數據不一致的區間會發生在：開啟雙寫（T1）->開始 backup + restore (T2) -> 結束 restore（T3）-> 暫停寫入，開始對齊數據（T4）。

如果需要記錄舊集群在這一區間內所有數據變化，那么以 Ingestion 端每秒百萬級的寫入，可想而知，在進行 restore 和 backup 的這一周積累的數據記錄有多大。這樣一來通過重放數據來對齊新舊集群的時間勢必會拉長。

有沒有可能縮短這部分數據對齊的時間呢？

經過仔細分析，只記錄 delete key 的數據變化就可以加速新舊集群的數據對齊。

在 Ingestion 端的寫入場景下，由于 delete key 數據變化占整體數據寫入的比例不到 1% ， 所以該優化可大大減少需要用來對齊差異的數據量，加速數據對齊的過程。大家可能會疑惑，數據服務寫入涉及增刪改，為什么只記錄 delete keys 并且后期只 replay delete keys 就能保證新舊集群最終數據對齊了呢？我們可以一起分析一下原因。

• 分析

在對齊前，這個數據變化區間里涉及到的舊集群的 keys 有如下幾種情況：

通過對以上各種場景的分析可見，delete key 部分相對特殊，可能會存在 Ingestion 端去在新集群中執行刪除后的 key 再次被 restore 階段寫回（執行刪除操作的時刻早于 restore 的操作），因此會帶來新舊集群的差異。而其他場景的最新數據狀態已經如實反映在新集群里，無須記錄和對齊。

• 技術選型

技術選型部分考慮用臨時的 Aerospike 小集群來記錄 delete key，主要考量點有以下幾個方面：

• Replay 階段對于服務 scan 的性能要求較高，期望可以在較短的時間內完成，因此對于技術棧的高性能讀寫具有較高的要求；
• Ingestion 端有大量寫入 delete key 的請求以及刪除已記錄的 delete keys 的請求（比如該 key 后期又重新寫回集群）下，因此也對技術棧讀寫的性能有極高的要求；
• KV 存儲結構可以減少 Key 的冗余，可以減少存儲的大小。

在對比了 AWS S3，MySQL，Aersopike 后，綜合讀寫高性能要求（Aeropsike 可以保證 800k 每秒的 QPS）和實現維護及 cost 成本，Aerospike 是一個 ROI 更高的選擇。

分布式共享配置 + 灰度切換

Etcd 是用于共享配置和服務發現的分布式、一致性的 KV 存儲系統。我們通過 etcd 來控制關鍵流程和灰度切換，比如是否要開啟雙寫、是否開始記錄或者停止記錄 delete key、 切換 Aerospikey 主從集群、灰度切換線上服務用哪一個 Aerospike 集群等等，只需要修改相應的 etcd 配置即可，無需再修改代碼升級上線，使得整個操作更方便、可控，也為隨時停止操作切回原有的 workflow 的 Plan B 帶來更多的靈活性。

數據驗證 + 關鍵業務指標監控

在做完新舊集群的數據對齊后，我們通過再一輪的數據驗證保證數據的準確性。考慮到數據量的大小，同時為了避免驗證對線上集群和 Ingestion 的影響，以及由于對比過程是一個非原子性的操作，新舊集群的數據在高 QPS 寫的場景下可能會取到不同版本的數據，所以我們采用以下三個維度來做數據驗證保證數據的一致：

• 新舊集群的 object count 需要一致；
• 對 1% 的數據進行抽樣對比，數據差異需要控制在 1?之內；
• 對于可能檢測到的非常少量的差異數據，需要再一次驗證新舊集群保證這些“差異”數據完全一致，徹底消除非原子性操作帶來的誤判。

監控部分由業務模塊加上相應的關鍵指標，比如 Aerospike 里的 hit ratio（有多少發送到 Aerospike 的 key 并且該 key 能在 Aerospike 里找到對應的記錄，即 hit_ratio = key_hit_counts / key_query_counts），就可以從另一個側面監控新舊集群的數據質量是否一致。此外，監控部分也有對 Aerospike 本身的讀寫性能、QPS 等等的報警指標，幫助時刻關注對線上服務的影響和性能變化。

具體遷移更換步驟

1. 新集群構建、前期設計開發及環境監控指標等準備

按照總體設計開始雙寫、數據對齊、驗證、監控等相關開發工作，與此同時，SRE 同學幫忙準備新集群及臨時輔助集群環境，并進行初步的新集群性能測試，保證新集群的性能滿足業務需求。

2. 打開雙寫，設置舊集群為主集群，并記錄變化的 delete keys

通過 etcd 打開 Ingestion 端的雙寫以及記錄 delete keys 的相關配置。

3. 開始舊集群數據的 backup 和 restore 過程

開始 backup 舊集群數據，backup 完成后新集群通過 unqiue 特性進行快照數據 restore。與此同時由于持續雙寫，所以新集群也同步寫入 Ingestion 端的數據。整個過程 AWS 上每個 region 的 backup + restore 耗時大約一個星期。

4. 根據 delete 的 keys 通過 replay 對齊數據

通過記錄 delete 的 keys 來進行 replay 對齊新舊集群的數據。在進行 replay 的階段，會暫停 Ingestion 端的數據寫入，防止誤刪后續新加入進來的數據。基于臨時 Aersospike 集群的高性能，幾個 region 分別根據 delete keys 重放兩次的情況下（第二次重放是為了進一步保證數據都徹底刪干凈），存儲的約五億個 keys 的處理時間總共大約只需一個小時左右。其中由于并不是所有記錄下的 delete keys 都真的需要對集群里數據進行實際操作（可回顧“加速新舊集群的數據對齊 ”里對于 delete keys 的情況分析，有一些記錄的 delete keys 已經并不存在新集群里了）。實踐中實際處理的數據約五千萬，命中率約 9%。所以對于 Ingestion 暫停的影響非常小，后續可以通過加大 Ingestion 速率來快速追趕這一個小時的數據。

執行 replay 操作結束后，會通過 Aerospike 記錄的上次 Ingestion 暫停時寫入的 Kafka offset 來保證數據寫入的連續性，并重新恢復 Ingestion 的寫入。

5. 數據驗證

對齊數據后，分 batch 對新舊集群進行 sampling scan 對比，對比結果需滿足設計階段對于數據驗證的要求。

6. 下游線上服務切換至讀新集群

數據驗證通過后下游線上服務可放心切換至讀取新集群的數據。

7. 雙寫切換新集群為主集群，仍持續進行雙寫

切換新集群為主集群角色，同時響應線上的服務讀取請求和 Ingestion 端的寫入請求，并持續通過業務監控指標及報警觀察新集群的性能和數據質量。切換后雙寫依然持續寫入，以防極端或者未考慮的場景發生，平臺仍具有 Plan B 能力可以迅速切回舊集群。用來輔助數據對齊的 delete keys 模塊及臨時集群此時可以下線收回。

8. 關閉雙寫，下線舊集群， 清理環境和代碼

持續觀察一到二周，線上一切正常，那么可通過 etcd 優雅地關閉雙寫，并下線舊集群，清理不需要的代碼。

成果與體會

這次關鍵大數據服務的集群更換在較短的時間里圓滿完成，整個過程比較平穩，0 事故發生。同時在更新的過程中統一了公司所有的 Aerospike 版本且都升級到最新的 5.x，另外也打開了 Rack Awareness 功能等等，使得廣告平臺上這個重要的大數據服務在 AWS 上的多 Region、多 AZ、高可用、可擴展和高性能的能力得到進一步保障。

由衷感謝團隊小伙伴們通盤地考量、準備、詳細的設計和快準穩的付出，以及 SRE、廣告投放和預測團隊的通力配合，讓這個高難度操作的完美交付成為可能！

面對線上關鍵大數據服務要求不停機地進行更換且不允許出現一丁點兒差錯的場景下，前期的設計如何仔細全面都不為過，而永遠有靈活且快速的 PlanB 方案 stand by 也是可以讓你沉穩地面對線上各種突發狀態，并且夜晚也能安然入眠的實用利器。

作者介紹：

肖紅梅，畢業于北京大學，曾任職于微策略、美團、Pegasus 大數據公司，具備豐富大數據開發與調優、大數據產品分析、數據倉庫 / 建模、項目管理及敏捷開發的經驗。現擔任 Comcast FreeWheel 數據 Identity 團隊高級經理。

目前 Identity 團隊主要負責廣告生態里關鍵的受眾定向這一環節， 基于 FreeWheel、客戶及第三方數據管理平臺（DMP）生成的數億用戶畫像，在海量數據中通過數據整合、機器學習、數據挖掘、圖分析等挖掘出有價值的信息來賦能業務，實現基于數據的用戶精細化廣告投放運營和精準營銷，為客戶提供業務決策提升服務質量，并最大化數據的價值與核心競爭力。