Atomic slot migration with Redis 8.4

Redis · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài kỹ thuật của nhà cung cấp về tính năng của Redis Open Source; benchmark do Redis tự chạy. Sheet trỏ bài thông báo Smooth Scaling (Redis Cloud Pro) dựa trên tính năng này.

Bối cảnh

• Redis Cluster chia key vào 16.384 hash slot (CRC16(key) mod 16384, hoặc phần trong {}), mỗi node giữ một tập slot. Phải dời slot khi scale out/in và khi một key, slot hay node quá tải (bộ nhớ, CPU, băng thông).
• Phát hiện mất cân bằng: CLUSTER SHARDS; từ 8.2 có CLUSTER SLOT-STATS cho từng slot (số key, CPU µs, byte vào/ra, từ 8.4 thêm bộ nhớ) để tìm slot nóng, slot lạnh.

Cách cũ (trước 8.4): dời từng key

• SETSLOT IMPORTING/MIGRATING, rồi lặp GETKEYSINSLOT + MIGRATE theo lô nhỏ cho tới khi slot rỗng, rồi SETSLOT NODE. Theo bài, cách này không nguyên tử và gây sáu vấn đề:
  1. Key đã dời trả -ASK, client phải gọi lại node đích: thêm latency, làm hỏng pipeline đơn giản.
  2. Lệnh nhiều key (MGET) gặp TRYAGAIN cho tới khi dời xong cả slot.
  3. Lỗi giữa chừng (ví dụ node đích hết bộ nhớ) để lại trạng thái phải xử lý tay, thường mất dữ liệu.
  4. Replica không biết slot đang dời, có thể trả lời như thể key đã bị xoá.
  5. Chậm vì chi phí mỗi key (lookup, round-trip).
  6. Key rất lớn làm MIGRATE timeout hoặc gây latency spike ở cả hai đầu.

Atomic slot migration (ASM)

• Giống full sync replication ở mức slot: chép toàn bộ nội dung slot sang đích kèm luồng delta, xong thì chuyển quyền sở hữu một lần, nguyên tử. Trong lúc chép, client vẫn nói chuyện với nguồn.
• Lệnh CLUSTER MIGRATION IMPORT <start> <end> gửi cho node đích (giống REPLICAOF), trả task ID; có STATUS và CANCEL. Một task cho mỗi node nguồn bất kể bao nhiêu dải slot.
• Các bước: đích mở hai kết nối tới nguồn (snapshot và luồng ghi mới, chạy song song, dùng cơ chế replication mới của Redis 8.0) → nguồn fork, gửi snapshot (thường là RESTORE từng key; key lớn chuyển sang dạng chunk kiểu AOF, ví dụ nhiều lô HSET) → khi snapshot xong và luồng delta xuống dưới ngưỡng, nguồn tạm dừng ghi của client một chút, đẩy nốt phần còn lại → đích nhận quyền, phát cấu hình qua cluster bus → nguồn mở lại ghi, client nhận -MOVED → nguồn xoá slot cũ ở thread nền (tách cả slot một bước, như FLUSHALL async); module không có cấu trúc theo slot hoặc bật CLIENT TRACKING thì quay về xoá dần trong cron của main thread.

Kết quả theo benchmark của Redis

• Tải: 10 triệu key × 512 byte (~5 GB), tỉ lệ ghi:đọc 1:10, 500 kết nối; GCP c4-standard-8, mỗi shard một máy, cùng zone.
• Scale out 3 → 4 shard (dời một phần ba slot): 6,4 giây; latency trung bình tăng dưới 5% trong 2 giây, chủ yếu do p99. Scale in 4 → 3: 8,6 giây; latency 2,3 → 2,8 ms trong 3 giây.
• So với cách cũ: nhanh tới 30 lần (6–8 giây so với 192–219 giây; 640 so với 21 slot/giây); -MOVED 2,1/giây so với tới 241,6/giây; spike latency tối đa dưới 70 ms so với 127 ms; 212 message cluster thêm so với tới 5.400.

Bài học cho SWE

• Dời dữ liệu từng phần tử trong khi vẫn phục vụ đẩy độ phức tạp ra client (redirect, retry, lệnh nhiều key) và để lại trạng thái lơ lửng khi lỗi. Chép trọn đơn vị (slot) + luồng delta + một điểm chuyển quyền nguyên tử là mẫu chung của migration online (Migration không downtime).
• Chọn đơn vị chia nhỏ hơn node (slot cố định) để resharding là dời slot, không băm lại key (Sharding và tách database).
• Có số liệu theo slot thì mới biết slot nào nóng để dời (Hot partition và thundering herd).
• Dời theo cả lô slot thay vì từng key bỏ được chi phí round-trip mỗi key; đó là phần lớn của "30 lần".

Liên quan

• Shopify 2026 · Upstash 2026
• Sharding và tách database · Migration không downtime · Hot partition và thundering herd