數據遷移在服務端是很常見的，包括cache遷移、db遷移等。遷移的動機包括業務重構、業務隔離、機器遷移、擴容等很多種情況。下面筆者就工作中遇到的比較簡單的遷移案例淺談下，讀者工作中遇到同類問題可以互相探討下。
1.cache遷移
mc或者redis節點經常是一致性哈希方式在集群中存放數據的，所以遷移或者擴容并不是簡單的加節點。比如我們業務通過twemproxy配置了5個redis節點。現在需要把所有的redis數據遷到新的集群。通常最簡單的做法是，在業務低峰期進行全量的redis數據同步，twemproxy進行一刀切。現在談另外一種做法，更具有普適性，包括可以針對擴容。也即twemproxy逐個加新的cache節點，如：5+1->5+2->...->5+5，然后逐個減少老的cache節點，如：5+5->4+5->3+5->...->0+5。當然整個過程是很謹慎的，要有數據支撐。
- 要評估的數據是，增加或減少cache節點帶來的miss的量，以及db是否能夠承受。因為增加或減少一個節點，必然導致部分key在cache節點中產生偏移，從而回源到db。所以cache節點盡量多，遷移也盡量在低峰期。實際miss的量和哈希算法以及節點個數相關。
- 要觀察的數據是，一方面是每次更改節點后，cache的命中率的變化。要等cache命中率穩定提升到最高，理論上是最適合遷移的時候。另一方面就是db的負載。這兩方面共同決定了要不要繼續下一次更改節點。
當然，如果有公司自研的cache代理，本身就可以支持擴容。比如可以通過支持流量copy的方式，逐步加熱新的cache集群，直至流量全部遷移完畢。
無論什么場景，采用什么方式，cache的遷移或擴容都要特別謹慎！業務請求的tps的時間分布，高峰期的量，cache命中率的預期變化，每個操作步驟的預期時間，回源量變化對后端的影響，網絡、存儲、帶寬，遷移是否會導致業務上的邏輯漏洞等等方方面面都要有盡量明確的評估，還有非常重要的一點：遷移失敗的回滾方案。
2.db數據遷移
我們業務中是純粹進行數據庫的遷移，而且要求業務不能停服。具體場景是，千萬級以上的數據，數據拷貝至少需要1個小時，另外表的主鍵id沒有被其他表或者cache引用。所以我們的做法是：
- 老庫數據全量導入到新庫，并記錄全部max id
- 程序更改配置和上線，讀寫都走新庫
- 再導出老庫的max id，對比上次記錄的max id，做增量插入。注意插入時候需要忽略id，否則會有id沖突。
這樣基本就完成了表的遷移。這里有個細節，如果新表的自增id我們允許不連續，那么可以設置個比較大的數，在增量插入的時候就可以全部字段復制插入了。而且好處是新老表可以認為是完全一樣的，而前一種方式id會變，如果有cache引用那也是有問題的。所以遷移要考慮是否有id作為其他表的外鍵、是否有cache或者其他地方引用主鍵id等等。如果漏考慮很可能就造成臟數據甚至影響業務了。
