Kiểm thử tải Redis: pipelining, hot key, eviction và failover

Mục tiêu có thể là sizing, so sánh cấu hình, xác minh SLO hoặc tìm điểm gãy. Mỗi mục tiêu cần câu hỏi pass/fail khác nhau: hệ thống giữ p99 dưới ngưỡng ở tải mục tiêu; eviction không ảnh hưởng nhóm key quan trọng; replication lag không vượt cửa sổ cho phép; hoặc failover hoàn tất mà retry không làm quá tải node mới.

Không dùng một kết quả redis-benchmark mặc định đại diện cho ứng dụng. Workload GET/SET với key nhỏ, uniform distribution và connection ổn định bỏ qua các vấn đề phổ biến như multi-key command, Lua/function, TTL churn, hot key, TLS, cluster redirect và client retry.

Topology tối thiểu gồm load generator độc lập, Redis primary/replica hoặc cluster, cơ chế điều phối failover, và telemetry cho host, Redis và mạng. Load generator không nên chia sẻ CPU, NIC hoặc storage với Redis. Đặt capture/flow telemetry ở cả phía client và node để phân biệt latency mạng với thời gian xử lý server.

Nếu ứng dụng đi qua proxy/service mesh, chạy hai nhánh: trực tiếp và qua đường production-like. Nhánh trực tiếp tạo baseline; nhánh đầy đủ phản ánh DNS, TLS, NAT, proxy queue và connection pooling. Ghi rõ same-AZ, cross-AZ hay hybrid vì RTT tác động trực tiếp tới command không pipeline.

Mô hình ít nhất sáu chiều: command mix, payload size, key cardinality, key distribution, TTL và concurrency. Dùng histogram payload thay vì một kích thước duy nhất. Với key distribution, chạy uniform để có baseline và Zipf-like để mô phỏng hot key. Ghi rõ tỷ lệ read/write, multi-key, transaction và script.

Pipelining tăng số command trên mỗi round trip nhưng thay đổi queueing, memory và fairness. Vì vậy phải báo pipeline depth cùng requests/second. Connection pooling, keepalive, TLS session reuse và số connection cũng phải cố định giữa các lần chạy.

Khóa phiên bản Redis, mode standalone/Sentinel/Cluster, shard count, replica count, persistence (RDB/AOF), appendfsync, maxmemory, eviction policy, kernel, CPU pinning, NUMA, NIC, MTU và TLS. Trước mỗi run, đưa dataset về cùng trạng thái và làm rõ warm-cache hay cold-start.

Đối với managed service, ghi instance class, region/AZ, maintenance state và giới hạn dịch vụ công bố. Không suy ra năng lực phần cứng bên dưới nếu nhà cung cấp không công bố. Đảm bảo load generator còn ít nhất 20–30% headroom để nó không trở thành bottleneck giả.

Quyết định không dựa vào throughput cực đại. Điểm vận hành nên nằm trước knee point, nơi p99 hoặc error rate bắt đầu tăng nhanh dù throughput chỉ tăng nhẹ.

• KPI: Throughput hữu ích · Ý nghĩa: Command thành công mỗi giây theo đúng mix · Bằng chứng: Client result + server ops/sec
• KPI: Latency p50/p95/p99 · Ý nghĩa: Độ trễ phân vị, tách command · Bằng chứng: Histogram phía client
• KPI: Error/timeout rate · Ý nghĩa: Lỗi kết nối, redirect, timeout · Bằng chứng: Client log có timestamp
• KPI: CPU/NIC saturation · Ý nghĩa: Điểm nghẽn tài nguyên · Bằng chứng: Host telemetry
• KPI: Memory fragmentation · Ý nghĩa: Chênh lệch bộ nhớ cấp phát và dùng · Bằng chứng: INFO MEMORY
• KPI: Eviction rate · Ý nghĩa: Key bị loại do memory pressure · Bằng chứng: evicted_keys delta
• KPI: Replication lag · Ý nghĩa: Độ trễ hoặc offset giữa primary/replica · Bằng chứng: Replication metrics
• KPI: Recovery time · Ý nghĩa: Từ fault đến traffic ổn định · Bằng chứng: Timeline đa nguồn

• Xác minh đồng bộ clock, reset counter và nạp dataset chuẩn.
• Chạy warm-up, không đưa số warm-up vào kết quả.
• Tăng tải theo bậc 10–15 phút; giữ nguyên mix và pipeline depth.
• Lặp lại với uniform rồi Zipf-like key distribution; so CPU từng shard và p99.
• Tăng payload theo histogram mục tiêu, không thay đồng thời concurrency.
• Giảm maxmemory trong lab hoặc tăng dataset để chạm ngưỡng; ghi eviction policy và loại key bị ảnh hưởng.
• Lặp lại với persistence/TLS đúng production; báo overhead như delta so với baseline.
• Chạy tối thiểu ba lần tại điểm mục tiêu, lưu raw histogram và metadata.
• Kịch bản: Baseline · Biến thay đổi: Uniform, không eviction · Điều cần quan sát: Knee point và generator headroom
• Kịch bản: Hot key · Biến thay đổi: Key distribution · Điều cần quan sát: CPU/shard imbalance, p99
• Kịch bản: Pipeline · Biến thay đổi: Depth · Điều cần quan sát: Throughput, tail latency, fairness
• Kịch bản: Memory pressure · Biến thay đổi: Dataset/maxmemory · Điều cần quan sát: Eviction, hit rate, latency
• Kịch bản: TTL churn · Biến thay đổi: Tỷ lệ expire · Điều cần quan sát: CPU, active expiration, jitter

Tạo fault bằng phương pháp có kiểm soát: dừng process, cô lập network hoặc terminate node theo runbook; mỗi loại fault có ý nghĩa khác nhau. Phát tải ổn định trước fault, ghi thời điểm tiêm lỗi, detection, promotion, client reconnect, recovery và ổn định. Theo dõi cả request thành công, timeout, duplicate write và replication offset.

Client retry phải dùng backoff, jitter và retry budget. Retry ngay lập tức từ hàng nghìn client có thể biến failover hợp lệ thành retry storm. Với write, xác định rõ mức durability yêu cầu; replication bất đồng bộ có thể tạo cửa sổ dữ liệu chưa tới replica. Bài kiểm thử chỉ kết luận trong policy và fault model đã mô tả.

Nếu client latency tăng nhưng server CPU thấp, kiểm tra RTT, connection pool, proxy queue, TLS và generator. Nếu một shard đạt CPU cao trong khi shard khác rảnh, xem hot key, key hash hoặc multi-key command. Nếu RSS tăng nhanh hơn dataset, kiểm tra fragmentation, allocator và churn; không mặc định đó là memory leak.

Khi eviction tăng nhưng hit rate không giảm, vẫn cần xem loại key bị loại và downstream load. Một cache miss có thể làm database phía sau quá tải dù Redis còn đáp ứng nhanh. Ghép Redis metrics với application latency và backend query rate mới thấy tác động thật.

Kết quả phụ thuộc mạnh vào phiên bản, module, client library, command mix, dataset, topology và cloud placement. Benchmark ngắn không chứng minh ổn định dài hạn; test lab không đại diện cho noisy neighbor hoặc maintenance event chưa mô phỏng. Không so requests/second giữa hai báo cáo nếu pipeline, payload và durability khác nhau.

• Pipeline depth: Số command gửi trước khi chờ phản hồi.
• Hot key: Key nhận tỷ lệ truy cập vượt trội, dễ gây lệch tải.
• Eviction: Loại key theo policy khi chạm maxmemory.
• Tail latency: Độ trễ ở các phân vị cao như p95/p99.
• Replication lag: Khoảng cách trạng thái giữa primary và replica.
• Knee point: Điểm tải mà latency/error tăng nhanh hơn lợi ích throughput.