DevOps 30/08/2026 9 phút

Cả một cụm Kubernetes chỉ là sổ sách trong etcd — kubelet là chỗ duy nhất sổ sách biến thành tiến trình thật, và toàn bộ độ trễ khởi động pod nằm ở một chỗ bạn không ngờ

Ba mốc cuối của việc khởi động một pod xảy ra gọn trong cùng một giây — kubelet gần như không tốn thời gian. Chỗ đắt là kéo ảnh: 5,9 giây cho 4 MB, 15,7 giây cho 400 MB. Bài này đo đoạn đường từ 'bộ lập lịch ghi tên node' tới 'container đang chạy', và chỉ ra vì sao kubelet là thành phần duy nhất trong Kubernetes không phải là một pod.

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.

Message Queue 30/08/2026 9 phút

Thử lại tin hỏng ngay tại chỗ chậm hơn 25 lần so với đẩy sang hàng đợi chết — vì một tin kẹt trên partition chặn đứng mọi tin tốt phía sau nó

Khi một tin không xử lý được, phản xạ tự nhiên là thử lại. Tôi đo cái giá đó ở bốn mức tỉ lệ hỏng: ở mức 50%, thử lại tại chỗ cho 30 tin/giây còn đẩy sang DLQ cho 766 — chênh 25,5 lần. Chi phí của một tin hỏng không phải là chờ nó, mà là toàn bộ hàng phía sau cũng phải chờ theo.

Message Queue 30/08/2026 9 phút

Cùng một trạng thái Kafka: 'tụt 2 triệu tin' hay 'tụt 102,6 giây' — một con số nói cho bạn mọi thứ, con số kia chẳng nói gì

Lag là chỉ số quan trọng nhất của một hệ thống Kafka, và cũng là chỉ số bị đặt cảnh báo sai nhiều nhất. Tôi đo cùng một trạng thái theo hai cách: hai triệu tin không hành động được, còn 102,6 giây thì trả lời ngay mọi câu hỏi. Cùng 100.000 tin lag có thể là 5 giây hoặc 2,8 giờ — chênh hai nghìn lần, tuỳ tốc độ.

Message Queue 30/08/2026 9 phút

Cùng một bài toán, cùng một máy: Kafka ghi nhanh gấp 2,9 lần và đọc gấp 4,8 lần RabbitMQ — nhưng con số đó gần như không phải lý do để chọn cái nào

Tôi dựng cả Kafka lẫn RabbitMQ trên cùng một máy, ném 200.000 tin vào mỗi bên và đo. Kafka thắng rõ về tốc độ. Nhưng khác biệt quyết định lựa chọn lại nằm ở chỗ khác hẳn: với RabbitMQ đọc xong là tin biến mất, với Kafka đọc xong tin vẫn còn — và đó là khác biệt kiến trúc, không phải hiệu năng.

Message Queue 30/08/2026 8 phút

Đặt min.insync.replicas = 3 với 3 bản sao nghe như 'an toàn nhất' — thực ra nó biến mọi lần vá máy thành một sự cố dừng ghi toàn phần

min.insync.replicas quyết định lúc nào Kafka thà từ chối ghi còn hơn nhận rồi mất. Tôi đo cả ba giá trị ở ba mức hỏng: đặt bằng đúng replication-factor thì không còn dư địa nào, mỗi lần bảo trì một broker đều dừng ghi. Và có một kiểu hỏng — mất quorum controller — mà không cấu hình topic nào chạm tới được, trong khi describe vẫn báo khoẻ.