項目地址：https://github.com/doyoubi/undermoon

目標：

• 簡單
• 快速

遷移過程基于以下 Redis 命令：

• SCAN
• DUMP
• PTTL
• RESTORE
• DEL

SCAN 命令有一個很好的特性，它可以保證在第一個 SCAN 命令之前設置的所有 key 最終都會返回，但有時會返回多次。我們可以執行 3 階段遷移來模擬復制。

• 等待 Redis 完成所有命令。
• 將所有讀寫操作重定向到目標 Redis。如果 key 不存在，則目標 Redis 將需要在處理命令之前從源 Redis 轉儲 key 的數據。
• 開始掃描并將數據轉發到 peer Redis。

詳細步驟

• migrating proxy(遷移代理) 通過 PreCheck 命令檢查 importing proxy(導入代理) 是否也收到遷移任務。
• migrating proxy 阻塞所有新添加的命令到 Queue，并等待現有命令完成。
• migrating proxy 向 importing proxy 發送 TmpSwitch 命令。收到此命令后，importing proxy 開始處理導入slot(槽)范圍內的 key。當命令返回時，migrating proxy 釋放 Queue 內的所有命令，并將它們重定向到 importing proxy。
• migrating proxy 使用 SCAN、PTTL、DUMP、RESTORE、DEL 將遷移 slot 范圍內的所有數據轉發到 peer importing Redis。RESTORE 不設置 REPLACE flag。
• importing proxy 在處理命令時，無論是讀操作還是寫操作，都會先

• 將 EXISTS 和處理后的命令發送到 local importing Redis，如果 EXISTS 返回 true，則將命令轉發到 local importing Redis。
• 如果 EXISTS 返回 false，則發送 DUMP 和 PTTL 到遷移的 Redis 獲取數據，并 RESTORE 數據并將命令轉發到 local Redis。然后最后將命令轉發到 local importing Redis。
• 如果該命令不會刪除 key，則獲取 key lock，
• 如果該命令可能刪除 key，則獲取 key lock 并將 UMSYNC 發送到 migrating proxy，讓 migrating proxy 使用 DUMP、PTTL、RESTORE、DEL 將 key 傳輸到 importing proxy。然后最后將命令轉發到 local importing Redis。

• 當 migrating proxy 完成掃描后，它會向 importing proxy 提出 CommitSwitch。然后importing proxy只需要在 local Redis 中處理命令。
• 通知 coordinator 并等待 UMCTL SETCLUSTER 的最終提交。

為什么會這樣設計

整個遷移過程基于以下命令 SCAN、PTTL、DUMP、RESTORE、DELETE。僅向導入服務器代理發送 RESTORE 命令，因此為了獲得更好的性能，應在遷移服務器代理中執行此掃描和傳輸。

由于掃描和傳輸在服務器代理和 Redis 上都占用了大量的 CPU 資源，因此最好在importing proxy上處理其他工作負載。因此，一開始我們將所有插槽(slots)直接轉移到importing proxy。

此時，importing proxy 仍然只有一小部分數據。當它需要處理新添加的 slots 上的命令時，需要在處理請求之前使用 PTTL、DUMP、RESTORE 從遷移的服務器代理中拉取數據。它還需要發送 DELETE 來刪除 key。

請注意，對于不會刪除 key 的任何命令，由于它是冪等的，因此對同一 key 多次 RESTORE 仍然是正確的。所以僅僅讓 importing proxy 來拉數據不會導致任何不一致。

但是對于那些可能刪除 DEL、EXPIRE、KPOP 等 key 的命令，只讓 importing proxy 拉取數據可能會導致以下情況：

• key 被刪除
• 還有另一個 RESTORE 命令可以恢復 key。

因此，在提取數據時，需要將其與

• importing proxy中的其他 RESTORE 命令。
• migrating proxy中的 SCAN 和 RESTORE。

因此，我們需要在 importing proxy 中鎖定 key，并且需要 migrating proxy 幫助我們發送數據而不是從importing proxy中拉取數據，以便對該 key 的操作只能按順序處理。

性能

因此，在遷移過程中，遷移和導入 proxy 的工作量非常平衡。migrating proxy 使用 130% 的 CPU，importing proxy使用 80% 的 CPU。

而且遷移 1G 數據只用了不到一分鐘。

在測試中，在遷移的同時進行基準測試，吞吐量從 50k 減少到 28k 并逐漸增加到 40k。這是因為在遷移和importing proxy中，SCAN、DUMP、RESTORE 會在 Redis 中消耗大量吞吐量。但是一旦 key 被遷移到導入服務器代理，它只需要在請求之前發送一個額外的 EXISTS 命令。

提交遷移后，吞吐量將翻倍。