Message Queue 30/08/2026 7 phút

Sáu partition, hai consumer, tưởng chia 3-3 — Kafka chia 2-4, và một consumer làm gấp đôi mà không ai hiểu vì sao

Chiến lược chia mặc định (RangeAssignor) chia riêng từng topic và làm tròn cùng một phía, nên phần dư dồn hết lên một consumer: hai topic lệch 4:2, năm topic lệch 10:5. Cộng với chuyện khởi động lại một consumer gây tới hai lần cân bằng toàn nhóm — và một dòng group.instance.id xoá sạch cả hai.

Message Queue 30/08/2026 8 phút

'Luôn dùng cooperative-sticky' — tôi đo thử và thấy nó khiến tổng thời gian partition ngừng chạy cao gấp 375 lần lời khuyên đó đang cố tránh

Cân bằng lại nhóm consumer được vẽ nhiều mà đo ít. Tôi bắt từng sự kiện kèm dấu thời gian: kiểu 'nhả hết' xong trong 4 ms không ai để ý, còn kiểu hợp tác giữ được partition đang chạy nhưng mỗi partition nhường mất 3 giây — tổng đắt gấp 375 lần. Lời khuyên 'luôn dùng cooperative' chỉ đúng khi ngắt một partition là đắt.

Message Queue 30/08/2026 8 phút

MirrorMaker 2 chép 200.000 tin sang cụm Kafka khác trong 8,7 giây — nhưng offset của consumer thì không sang, và nó hỏng mà không báo một tiếng; chép sách dễ, chép dấu trang mới khó

Sao chép Kafka giữa hai vùng là nền của mọi kế hoạch phục hồi thảm hoạ. Tôi dựng hai cụm thật, chạy MirrorMaker 2: dữ liệu sang hoàn hảo trong 8,7 giây, nhưng vị trí đọc của consumer thì không — topic checkpoint được tạo ra, rỗng, và im lặng. Đó là khác biệt giữa 'có bản sao dữ liệu' và 'có kế hoạch chuyển vùng'.

Message Queue 30/08/2026 7 phút

Một partition Kafka đã đạt 83% thông lượng đỉnh, 128 partition không nhanh hơn 4 — nhưng chỉ cần thêm partition rỗng, bộ nhớ broker đã tăng gấp 3,4 lần

'Đặt nhiều partition cho chắc' là lời khuyên phổ biến và tốn kém. Tôi đo cả hai vế: phía ghi một partition đã gần chạm trần, thêm consumer bão hoà ở 1,7 lần chứ không phải 4 lần, còn 2.000 partition rỗng đẩy bộ nhớ broker từ 290 MB lên 973 MB. Partition là đơn vị song song, không phải nút vặn thông lượng — và tăng thì được, giảm thì không.

DevOps 30/08/2026 8 phút

Cơ sở dữ liệu chớp tắt vài giây, và cả bốn pod ứng dụng — vốn đang khoẻ mạnh — rơi vào vòng lặp khởi động lại chỉ vì một dòng livenessProbe nghe rất hợp lý

Probe là thứ hiếm hoi mà cấu hình sai còn tệ hơn không cấu hình. Dựng ba kiểu sai phổ biến nhất và đo hậu quả: livenessProbe kiểm phụ thuộc ngoài khiến cả fleet restart khi DB chết (và restart không sửa được gì, còn làm phục hồi tệ hơn); timeoutSeconds mặc định 1 giây giết pod hoàn toàn khoẻ chỉ vì nó trả lời chậm hơn một giây; readinessProbe với failureThreshold 1 làm cả dịch vụ mất hết endpoint khi mọi pod cùng trượt một nhịp — mà kubectl get pods trông gần như bình thường. Và vì sao nhiều ứng dụng KHÔNG nên có livenessProbe.

Cơ sở dữ liệu 29/08/2026 9 phút

300 client dùng chung 17 kết nối — và work_mem của người này lặng lẽ rò sang truy vấn của người khác

Phần trước đo được thông lượng PostgreSQL đạt đỉnh ở đúng số lõi CPU. PgBouncer là câu trả lời khi ứng dụng có nhiều máy chủ — nó nhồi 300 client vào 17 kết nối. Nhưng chế độ transaction có một cái giá không phải hiệu năng: trạng thái phiên của một client rò sang client khác.