本文講解的方法論是一種通用的遷移方案，既適合字段遷移、表遷移、也適合庫遷移以及應(yīng)用遷移，既適合數(shù)據(jù)庫的遷移也適合緩存的遷移，雖然在細節(jié)上有些不同，但是在方法論上則大同小異，我們以分片后的數(shù)據(jù)容量不能滿足需求，需要對分片后的數(shù)據(jù)擴容為例，這里的擴容實際上是遷移的一種特殊案例，我們以擴容為例來說明相應(yīng)的步驟和實現(xiàn)細節(jié)。

1. 平滑遷移

平滑遷移適合對可用性要求較高的場景，例如，線上的交易服務(wù)對緩存或者數(shù)據(jù)庫依賴較大，不能忍受停機帶來的業(yè)務(wù)損失，也沒有交易的低峰期，我們對此只能采用平滑遷移的方式。

平滑遷移，是指將正在提供線上服務(wù)的數(shù)據(jù)，從一個地方數(shù)據(jù)存儲到另一個數(shù)據(jù)存儲，整個遷移過程中要求不停機，服務(wù)不受影響。根據(jù)數(shù)據(jù)所處層次，可以分為緩存遷移、數(shù)據(jù)庫存儲遷移、應(yīng)用遷移等等；根據(jù)數(shù)據(jù)遷移前后的變化，又可以分為數(shù)據(jù)平移和數(shù)據(jù)轉(zhuǎn)移。數(shù)據(jù)庫對數(shù)據(jù)庫的遷移屬于平移，數(shù)據(jù)庫對其他Nosql庫的遷移屬于數(shù)據(jù)轉(zhuǎn)移。??數(shù)據(jù)平移是指遷移前后數(shù)據(jù)組織形式不變，比如Mysql數(shù)據(jù)庫從1個實例擴展為4個實例，Redis緩存從2個實例擴展到8個實例，等等。

如果在最初的設(shè)計里就為以后的擴容做好準備，也就是做了充分的容量評估，關(guān)于容量評估，請參考《分布式服務(wù)架構(gòu)：原理、設(shè)計與實戰(zhàn)》的第3章的內(nèi)容，那么數(shù)據(jù)遷移工作就會簡單很多，比如Mysql已經(jīng)做了分庫分表，擴展實例的時候，只需要多做幾個從庫，切換訪問關(guān)系，最后將冗余的庫表刪除即可達到擴容的效果，當然，這需要短暫的停止服務(wù)。

近年來出現(xiàn)很多支持自動可伸縮的數(shù)據(jù)庫，在實現(xiàn)上已經(jīng)做到全自動數(shù)據(jù)遷移，如HBase、TiDB等，那就更簡單了，只要通過管理功能來添加機器，手工修改配置或者系統(tǒng)自動發(fā)現(xiàn)，就可完成數(shù)據(jù)庫容，也就免去了發(fā)雜的數(shù)據(jù)遷移等工作。??數(shù)據(jù)轉(zhuǎn)移是指在數(shù)據(jù)遷移前后，數(shù)據(jù)組織形式發(fā)生了變化。比如將Mysql數(shù)據(jù)庫遷移到HBase數(shù)據(jù)庫，微博就經(jīng)歷過這樣的過程。

平滑遷移通常使用的是雙寫方案，方案分成4個步驟：雙寫、遷移歷史數(shù)據(jù)、切讀、下雙寫。

這種方式如果應(yīng)用與緩存擴容的遷移的場景，則還有一個變種，就是不需要遷移舊數(shù)據(jù)，在第1步中雙寫后，在一定的時間里通過新規(guī)則對新緩存進行寫入，新緩存已經(jīng)有了足夠的數(shù)據(jù)，這樣我們就不用再遷移舊數(shù)據(jù)，直接進入第3步即可。

首先，假設(shè)我們的應(yīng)用現(xiàn)在使用了具有兩個分片的數(shù)據(jù)集群，通過關(guān)鍵字哈希的方式進行路由，如下圖所示。

因為兩個分片已經(jīng)不能滿足容量的需求，所以現(xiàn)在需要擴容到4個分片，達到原來兩倍的總大小，因此我們需要遷移。

遷移的具體過程如下。

1. 雙寫

按照新規(guī)則和舊規(guī)則同時往新新舊數(shù)據(jù)系統(tǒng)中寫數(shù)據(jù)，如下圖所示。

2. 遷移歷史數(shù)據(jù)

把舊緩存集群中的歷史數(shù)據(jù)讀取出來，按照新的規(guī)則寫到新的數(shù)據(jù)集群中，如下圖所示。

3. 切讀

把應(yīng)用層所有的讀操作路由到新的數(shù)據(jù)集群上，如下圖所示。

4. 下線雙寫

在這一步，我們把寫入舊的集群的邏輯下線，，如下圖所示。

閱讀全文請報名Gitchat的嘮嗑節(jié)目。

推薦一起學習《分布式服務(wù)架構(gòu)：原理、設(shè)計與實戰(zhàn)》一書，它是一本不可多得的理論與實踐相結(jié)合的架構(gòu)秘籍，是作者多年工作經(jīng)驗積累的結(jié)晶。京東購買請掃描下方二維碼。