Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
'Đặ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.
Service cho bạn một IP ổn định trong khi pod đến rồi đi — nhưng mở ra thì ClusterIP không tồn tại ở đâu cả: 0 socket, 0 giao diện mạng, chỉ là luật iptables DNAT đổi địa chỉ đích sang pod thật. Điều đó giải thích vì sao không ping được, telnet cổng lạ thì im lặng, tcpdump không thấy nó. Và một sự thật hay bị bỏ sót: cân bằng tải xảy ra ở mức KẾT NỐI không phải mức yêu cầu, nên HTTP keep-alive và gRPC dồn mọi yêu cầu về cùng vài pod. Cộng thêm vì sao iptables 55.000 dòng không co giãn và IPVS ra đời.
OOMKilled là trạng thái pod hay bị chẩn đoán sai nhất. Dựng nó có chủ ý: container vượt limits.memory bị kernel giết bằng SIGKILL (exitCode 137) — không tín hiệu, không giai đoạn dọn dẹp, nên mọi cơ chế tắt sạch bạn viết đều vô dụng, thứ cần giữ phải ghi LIÊN TỤC chứ không phải lúc tắt. Kubernetes không sinh event nào cho OOM — thông tin chỉ nằm ở status pod, nên bảng theo dõi dựa vào event mù hoàn toàn. Và OOMKilled (mức container, không đổi node) khác hẳn Evicted (mức node, đổi node) cả cơ chế lẫn cách chữa.
Một client viết sai có thể chiếm hết băng thông cả cụm. Kafka có hạn ngạch để chặn, và tôi đo xem nó thật sự làm gì: bóp đúng xuống 4,38 MB/giây, nhưng bóp bằng cách làm chậm phản hồi chứ không từ chối, nên không có lỗi nào để bắt — và vì nó đo trên cửa sổ trung bình 11 giây, một client vẫn bùng phát được tới gấp 11 lần hạn ngạch trước khi bị chặn.
Chốt offset là chỗ dữ liệu thật sự mất hoặc trùng. Tôi dựng một lần sập giống hệt nhau rồi chạy ba cách: chốt trước khi xử lý mất tin, chốt sau khi xử lý trùng tin, không cách nào từ Kafka cho ra đúng một lần. Thứ tự giữa 'làm việc' và 'ghi nhận đã làm' quyết định crash làm mất hay làm trùng.
'Kafka có độ trễ cao' là câu hay nói. Tôi đo thật, tách từng chặng: mặc định dưới một phần ba mili giây. Thứ gây độ trễ nghìn lần là hai bộ hẹn giờ chờ-gom-lô (linger.ms, fetch.min.bytes) — gần như miễn phí khi tải cao, nhưng bằng đúng cả khoảng chờ khi tải thấp, nên kiểu hỏng tệ nhất rơi vào lúc ba giờ sáng không ai nhìn bảng số.