Kiểm thử Kafka consumer rebalance: lag, duplicate và partition skew

Mục tiêu không chỉ là “rebalance nhanh”. Cần biết trong lúc membership thay đổi, producer có tiếp tục ghi không, backlog tối đa bao nhiêu, thời gian bắt kịp bao lâu, có message mất/trùng không, ordering được bảo vệ ở phạm vi partition nào và downstream có chịu được retry hay không.

Chốt delivery contract: at-most-once, at-least-once hay quy trình có transaction/idempotency. Kafka offset commit chỉ phản ánh vị trí đọc; nó không tự chứng minh side effect tại database, API hoặc object store đã xảy ra đúng một lần.

Topology gồm producer có event ID duy nhất, cluster Kafka, consumer group, downstream sink và bộ đối soát độc lập. Thu metric theo topic–partition–consumer; tổng lag có thể che một partition nóng. Đồng bộ thời gian giữa generator, broker, consumer và sink để dựng timeline.

Workload nên giữ phân phối key giống production, gồm payload size, compression, batch, produce rate và tỷ lệ key nóng. Chạy steady state đủ lâu để có baseline, rồi thực hiện rolling restart, kill member, network delay, coordinator movement và scale-out riêng biệt.

Khóa số partition, replication, producer rate, key distribution, assignor, session/heartbeat timeout, max poll interval, poll batch, processing time, commit mode và consumer concurrency. Nếu thay assignor đồng thời đổi timeout, không thể quy cải thiện cho một yếu tố.

Tài nguyên cũng là biến: CPU throttling, JVM pause, disk/network broker, downstream latency và autoscaling policy. Một consumer bị xem là “dead” vì không poll kịp có thể bắt nguồn từ sink chậm, không phải Kafka network.

• Key distribution — Tác động: Partition skew; Bằng chứng: Per-partition ingress/lag
• Processing time — Tác động: max.poll.interval risk; Bằng chứng: Handler latency histogram
• Assignor — Tác động: Phạm vi partition di chuyển; Bằng chứng: Assignment event log
• Commit timing — Tác động: Duplicate/loss window; Bằng chứng: Offset + event ID ledger
• Downstream latency — Tác động: Backpressure; Bằng chứng: Sink p95/p99, error/retry

Đo rebalance start/end, thời gian không có successful consume, peak lag, recovery time về baseline, throughput trough, duplicate rate, missing event count, out-of-order theo key và số partition bị reassigned. Báo per-partition và group aggregate.

Bằng chứng gồm consumer log với member/generation, assignment snapshot, committed offset, broker/coordinator event, producer manifest, sink ledger và resource telemetry. Một dashboard lag không đủ để chứng minh không mất dữ liệu.

• Graceful rolling restart — Kỳ vọng: Chuyển assignment có kiểm soát; Failure cần phát hiện: Pause dài, duplicate burst; Pass/fail gợi ý: Recovery trong SLO; ledger đủ
• Kill consumer — Kỳ vọng: Member timeout rồi phân phối lại; Failure cần phát hiện: Lag tăng vượt headroom; Pass/fail gợi ý: Không mất; duplicate trong budget
• Scale-out — Kỳ vọng: Partition được san lại; Failure cần phát hiện: Thêm member nhưng throughput không tăng; Pass/fail gợi ý: Skew giảm hoặc lý do rõ
• Sink chậm — Kỳ vọng: Backpressure có giới hạn; Failure cần phát hiện: Poll timeout, rebalance loop; Pass/fail gợi ý: Không runaway lag/rebalance
• Partition tăng — Kỳ vọng: Assignment thay đổi; Failure cần phát hiện: Key ordering expectation sai; Pass/fail gợi ý: Ordering đúng trong phạm vi cam kết
• Coordinator disruption — Kỳ vọng: Group tái ổn định; Failure cần phát hiện: Storm, commit failure; Pass/fail gợi ý: Evidence đầy đủ, tự phục hồi

1. Ghi version broker/client, protocol, assignor và cấu hình group. 2. Sinh manifest event ID–key–partition–timestamp và baseline ở 50–60% tải mục tiêu. 3. Tăng đến tải mục tiêu; xác nhận lag ổn định, không chỉ bằng 0 tức thời. 4. Rolling restart từng consumer, đo pause, peak lag và recovery. 5. Kill -9 một member; giữ producer rate không đổi. 6. Làm chậm sink để khiến processing gần max poll interval; quan sát rebalance loop. 7. Scale-out/scale-in; kiểm tra assignment và partition skew. 8. Thử broker/coordinator disruption trong giới hạn lab được phê duyệt. 9. Đối soát producer manifest với sink ledger; phân loại duplicate và missing. 10. Lặp ba lần và thực hiện canary với traffic profile đã giảm trước production.

Với at-least-once, duplicate có thể là hành vi chấp nhận được nhưng downstream phải idempotent. Dùng event ID và idempotency key để chứng minh. Với transaction, kiểm tra phạm vi transaction và hệ thống ngoài Kafka; một database side effect không tự nằm trong Kafka transaction.

Ordering chỉ được đảm bảo trong partition theo điều kiện phù hợp, không phải toàn topic. Nếu tăng partition, cùng key vẫn có thể được map theo quy tắc producer, nhưng chiến lược và lịch sử dữ liệu phải được xem xét; không hứa ordering toàn cục khi kiến trúc không cung cấp.

Khi lag tăng, tách ba nhóm: ingress vượt processing capacity; partition skew; hoặc consumer mất thời gian vì rebalance/GC/downstream. Xem per-partition first, sau đó assignment events, poll/handler latency, commit error và resource saturation.

Nếu group liên tục rebalance, tìm member churn và max poll violation trước khi tăng timeout. Timeout lớn có thể giảm churn nhưng kéo dài phát hiện member chết. Nếu thêm consumer không tăng throughput, kiểm tra số partition, hot key và bottleneck sink.

Kết quả phụ thuộc version, client implementation, assignor, managed-service behavior và workload. Một bài thử không có duplicate không chứng minh exactly-once. Peak lag trong lab không đại diện production nếu key distribution và downstream latency khác. Luôn ghi điều kiện, seed và dataset.

• Consumer group: nhóm consumer chia assignment partition.
• Rebalance: quá trình cập nhật membership và phân phối partition.
• Consumer lag: chênh lệch giữa log end offset và vị trí đã xử lý/commit theo định nghĩa metric.
• Partition skew: tải phân bố không đều giữa partition.
• Idempotency: xử lý lặp không tạo side effect ngoài ý muốn.
• Recovery time: thời gian từ fault đến khi backlog và throughput về điều kiện chấp nhận.