在企業級的數據同步和遷移場景中，Redis 憑借高性能和靈活的數據結構，常被用于緩存和高頻讀寫場景。隨著業務數據的積累，Redis 中不可避免會出現包含大量元素的“大 Key”，如包含幾十萬條數據的 List、Set 或 Hash 類型。在進行全量同步或遷移時，大 Key 往往成為性能瓶頸甚至故障源。

CloudCanal 作為專業的數據遷移同步工具，不斷優化 Redis 同步技術，近期對 Redis 源端鏈路又完成了一系列優化，包括更多指令支持、數據校驗以及 全量大 Key 同步優化。本文重點介紹在大 Key 同步場景下，CloudCanal 的技術優化與性能提升。

大 Key 同步挑戰

在高并發、高實時性的業務系統中，Redis 某個 Key 的元素可能高達數十萬甚至上百萬。一旦執行全量數據同步，容易帶來如下問題：

• 內存占用劇增（OOM）：一次性加載整個大 Key 會使任務程序的內存瞬時暴漲，嚴重時可能引發 OOM。
• 協議限制超限：Redis 協議對單條命令的參數數量和請求體大小有上限（如 RESP 協議中為 512MB），超出即報錯。
• 對端寫入失敗：Redis 目標節點在處理過大命令時，可能因資源不足而拒絕執行，導致同步中斷。

CloudCanal 同步技術優化

為解決上述問題，CloudCanal 引入了針對大 Key 的延遲加載與分片同步機制，確保在不犧牲一致性前提下，順利完成 Redis 全量同步。

延遲加載

傳統同步方式往往一次性讀取整個 Key 內容加載到內存中，CloudCanal 則采取延遲加載策略，即在全量同步過程中，源端 Redis 的數據不會立即加載到內存中，而是通過 分片 的方式逐步加載和處理。這種方式可以 有效減少內存占用，避免程序 OOM 問題。

大 Key 分片同步

CloudCanal 對 Redis 源端鏈路的核心優化是將大 Key 拆分成多個“小片段”，分片寫入目標 Redis。每個片段包含的元素數量可以通過參數靈活控制：

• 參數名：parseFullEventBatchSize
• 默認值：1024
• 類型支持：List、Set、ZSet、Hash

例如，一個包含 50 萬元素的 Set，可以被拆成約 490 個片段，每次發送一個 SADD 命令攜帶 1024 個元素。

分片同步流程

1. 分片計算：CloudCanal 首先統計大 Key 中的元素總數，并根據設定的參數 parseFullEventBatchSize 將其切分成多個片段。
2. 片段構造與發送：每個片段被構造成符合 Redis 協議限制的命令，多次發送，最終重建完整 Key 內容。
3. 順序與原子性保證：每個片段按順序寫入，確保目標端數據一致性。

實際效果

CloudCanal 測試了優化后的大 Key 同步效果，數據準備如下：

• 100w 普通大小 Key（包含：String、Set、ZSet、List、Hash）
• 5w 30 MB 大小 Key（包含：String、Set、ZSet、List、Hash，最大 Key 35 MB左右）

數據同步性能如下：

結果顯示，CloudCanal 在 Redis 到 Redis 數據同步（包含大 Key 場景）中，基準 RPS 可達到 4-5 K 左右，基本能夠滿足業務日常同步需求，并確保數據準確。

總結

通過延遲加載與分片同步機制，CloudCanal 有效避免全量同步過程中可能出現的 OOM 問題和協議限制問題，從而提升全量同步的穩定性和可靠性。