背景
在分布式系統中，用於解決客戶端訪問分布式集群熱點問題的算法比較出名的一種算法就是一致性哈希算法，該算法同樣應用在redis中，本司所使用的是64位的有符號hash算法（網上很多例子所使用的是32位無符號hash），加上虛擬節點解決哈希傾斜問題。但無論一致性哈希算法如何優秀，它依然解決不了新增刪除節點帶來的數據遷移需求。
方案一：離線遷移方案
dump---拷貝到中轉機---合並dump---清理冗余數據---拆分dump---傳dump---停起主從----啟動主從加載數據
優點：整個遷移過程，只有最終起停主從加載數據時，無法提供服務，大概持續幾分鍾的時間，應用系統可以通過降級服務的方式避免這種影響；
缺點：從dump開始之后的新數據都將丟失，而且服務起停過程期間產生的數據如果應用系統自己不做實時備份，將永久丟失。
應用場景：對數據丟失不敏感，支持降級的服務，以及有緊急擴容需求的業務系統可以選擇
方案二：不停機橫向擴容方案1
第一步：運維dump老分片的rdb文件（此時刻為T1），遍歷文件內容，按照新分片進行rehash，如果發現rehash之后匹配的分片與之前不一致，則為需要遷移的key，記錄遷移前的分片（用於刪除），記錄遷移后的分片（用於遷移）；
第二步：將需要遷移的key使用redis客戶端插入到新的分片（第二步中已經通過rehash計算出來新的所屬分片）；
第三步：應用系統替換最新的redis分片配置，此時新數據將按照新的分片進行路由（此時刻為T2）；
第四步：從老分片中刪除這部分已經遷移的key（第二步中已經比較出這部分key；
第五步：重復
第一步、第二步、第四步，目的是將T1-T2時刻寫入到老分片集群的新數據重新遷移；
（注：第二步，第四步操作的數據是同一批，都是第一步計算出來的需要重新遷移的key；需要直接使用插入刪除命令）
優點：整個遷移過程不需要停機，數據不會丟失；
缺點：
1.第三步執行之后，第五步執行完成之前，這部分遷移的key會因為客戶端rehash結果與之前不一致導致查詢不到，此時可能會影響業務；（該方案需要業務自行評估影響）；
2.第五步插入前可能已經在新分片有寫入了，這時候舊數據不能隨便寫入，可能引起數據覆蓋，需要做檢查處理。
應用場景：對數據丟失敏感，但可支持短時間降級（key查詢為空的情況）的服務，以及有緊急擴容需求的業務系統可以選擇；
方案三：不停機橫向擴容方案2
應用系統同時對新老分片集群進行“雙份”寫入，此時查詢還是通過老分片提供；
等到新分片集群已經完全可以提供查詢服務時，替換查詢服務到新分片集群（如何確認新分片集群可以提供查詢服務，需要根據老集群中所有key的最長失效時間，必須超過這個時間，才能將查詢切換到新集群；
優點：整個遷移過程不需要停機，數據不會丟失，同時遷移過程也不會出現查詢不到key的情況；
缺點：
- 需要應用系統自行改造代碼發布，遷移完之后，還需要進行發布還原代碼；
- 整個遷移過程可能會因為集群中key的最長失效時間過長，導致遷移周期太長，同時遷移過程可能出現大量key在不同的分片中重復存儲，因此這個方案在時間和空間上都步不適合臨時緊急擴容；
- “雙份”寫入可能會影響服務性能
應用場景：對數據丟失敏感，且不支持服務降級的系統，以及沒有緊急擴容要求的系統可以選擇；
總結：每個方案各有優缺點，業務系統可以根據自身的應用場景和數據特點選擇方案。方案一和方案二都需要中間件和運維進行技術支持，應用系統不用做改造。方案二目前尚未提供；方案三不需要中間件和運維支持，業務系統自行完成；方案一可以有改進版，業務系統自行備份遷移過程的數據，在遷移完成后自行步入。