本文節選自即將出版的《可伸縮服務架構：框架與中間件》一書，作者：李豔鵬、楊彪、李海亮、賈博巖、劉淏。
處理分佈式緩存遷移是比較困難的，通常我們將其分為平滑遷移和停機遷移。這裡講解通用的遷移方案，擴容實際上是遷移的一種特殊案例，我們在下面學習的方案全部適用。我們會在講解該方案的過程中，以擴容為例來說明相應的步驟和實現細節。
１．平滑遷移
平滑遷移適合對可用性要求較高的場景，例如，線上的交易服務對緩存依賴較大，不能忍受停機帶來的業務損失，也沒有交易的低峰期，我們對此只能採用平滑遷移的方式。
平滑遷移使用的是雙寫方案，方案分成4個步驟：雙寫、遷移歷史數據、切讀、下雙寫。
這種方式還有一個變種，就是不需要遷移老數據，在第1步中雙寫後，在一定的時間裡通過新規則對新緩存進行寫入，新緩存已經有了足夠的數據，這樣我們就不用再遷移舊數據，直接進入第3步即可。
首先，假設我們的應用現在使用了具有兩個分片的緩存集群，通過關鍵字哈希的方式進行路由，如圖4-19所示。
圖4-19
因為兩個分片已經不能滿足緩存容量的需求，所以現在需要擴容到4個分片，達到原來兩倍的緩存總大小，因此我們需要遷移。
遷移的具體過程如下。
第1步，雙寫。按照新規則和舊規則同時往新緩存和舊緩存中寫數據，如圖4-20所示。
圖4-20
這裡，我們仍然按照舊的規則，也就是關鍵字哈希除以2取餘來路由分片，同時按照新的規則，也就是關鍵字哈希除以4取餘來路由到新的4個分片上，來完成數據的雙寫。
這個步驟有優化的空間，因為是在成倍擴容的場景下，所以我們不需要準備4個全新的分片。新規則中前兩個分片的數據，其實是舊規則中兩個分片數據的子集，並且規則一致，所以我們可以重用前兩個分片，也就是說一共需要兩個新的分片，用來處理關鍵字哈希取餘後為2和3的情況；使用舊的緩存分片來處理關鍵字哈希取餘後0和1的情況即可。如圖4-21所示。
圖4-21
第2步，遷移歷史數據。把舊緩存集群中的歷史數據讀取出來，按照新的規則寫到新的緩存集群中，如圖4-22所示。
圖4-22
在這個過程中，我們需要遷移歷史數據，在遷移的過程中可能需要遷移工具，這也需要一部分開發工作量。在遷移後，我們還需要對遷移的數據進行驗證，表明我們的數據遷移成功。
在某些應用場景下，緩存數據並不是應用強依賴的，在緩存裡獲取不到數據，可以回源到數據庫獲取，因此在這種場景下通過容量評估，數據庫可以承受回源導致的壓力增加，就可以避免遷移舊數據。在另一種場景下，緩存數據一般是具有時效性的，應用在雙寫期間不斷向新的集群中寫入新數據，歷史數據會逐漸過時，並被從舊的集群中刪除，在一定的時間流逝後，在新的集群中自然就有了最新的數據，也就不再需要遷移歷史數據了，但是這需要進行評估和驗證。
第3步，切讀。把應用層所有的讀操作路由到新的緩存集群上，如圖4-23所示。
圖4-23
這一步把應用中讀取的操作的緩存數據源轉換成新的緩存集群，這時應用的讀寫操作已經完全發生在新的數據庫集群上了。這一步一般不需要上線代碼，我們會在一開始上雙寫時就實現開關邏輯，這裡只需要將讀的開關切換到新的集群即可。
第4步，下線雙寫。把寫入舊的集群的邏輯下線，如圖4-24所示。
圖4-24
這一步通常是在雙寫和切讀後驗證沒有任何問題，並保證數據一致性的情況下，才把這部分代碼下線的。同時可以把舊的分片下線，如果是擴容的場景，並且重用了舊的分片1和分片2，則還可以清理分片1和分片2中的冗餘數據。
２．停機遷移
停機遷移的方法比較簡單，通常分為停止應用、遷移歷史數據、更改應用的數據源、啟動應用這4個步驟，如圖4-25所示。
圖4-25
具體的遷移步驟如下。
（1）停機應用，先將應用停止服務。
（2）遷移歷史數據，按照新的規則把歷史數據遷移到新的緩存集群中。
（3）更改應用的數據源配置，指向新的緩存集群。
（4）重新啟動應用。
這種方式的好處是實現比較簡單、高效，能夠有效避免數據的不一致，但是需要由業務方評估影響，一般在晚上交易量比較小或者非核心服務的場景下比較適用。
出自：技術瑣話
閱讀更多 技術顧問聯盟 的文章
