Kafka: Zero to Hero

1 Ba đội cùng đọc một tin mà không ai làm mất của ai — vì sao gọi Kafka là 'hàng đợi' đã sai từ gốc Kafka hay bị gọi là hàng đợi tin nhắn, và cái tên đó đẻ ra phần lớn hiểu nhầm. Tôi đo đặc tính thật sự định nghĩa nó: đọc không xoá tin, ba nhóm cùng đọc đủ. Và 493.421 tin mỗi giây không đến từ 'mỗi tin nhanh' — bỏ gộp lô thì mỗi tin nhanh gấp 34 lần mà thông lượng sụp đổ. 29/08/2026 · 8 phút đọc

2 Cả nghìn bài đo bảo 'Kafka chậm' — họ đang bấm giờ JVM khởi động, không phải Kafka Một broker Kafka thật ra khởi động 2 giây, chiếm 290 MB — nhẹ hơn hẳn tiếng tăm của nó. Nhưng thứ khiến tôi dừng lại là một cái bẫy đo lường: công cụ dòng lệnh tốn 0,86 giây trong khi gửi tin thật chỉ mất 0,89 mili giây. Chênh nhau một nghìn lần, và rất nhiều người đo trúng cái sai. 29/08/2026 · 7 phút đọc

3 Tôi gửi 4 khoá vào 4 partition, đinh ninh mỗi ngăn một khoá — kết quả là 5000/0/0/15000 Ba khái niệm topic–partition–offset thường được vẽ bằng hình hộp và mũi tên. Tôi mở thẳng thư mục dữ liệu trên đĩa ra xem, và vấp phải một cái bẫy về key mà không hình vẽ nào cho thấy: hai partition rỗng hoàn toàn, thêm partition cũng chẳng chữa. 29/08/2026 · 7 phút đọc

4 acks=1 báo 'đã gửi', trả 200 cho khách — rồi 100 bản ghi biến mất, và không ai biết Ai cũng bảo 'acks=0 nhanh nhất'. Tôi đo thì thấy nó còn chậm hơn acks=1 5%. Chỉ acks=all mới thật sự tốn — mất nửa thông lượng. Và đây là thứ nửa đó mua được: sự thật, đúng lúc cụm đang hỏng. 29/08/2026 · 7 phút đọc

5 Suýt nữa tôi đăng một bài bảo 'nén chẳng đáng' — may là tôi đo lại trên dữ liệu thật Ai cũng bảo gộp lô là 'đổi độ trễ lấy thông lượng'. Tôi đo thì thấy nó làm độ trễ giảm 1.567 lần, cùng lúc với thông lượng. Còn nén trên dữ liệu ngẫu nhiên lại cho ra tệp to hơn bản không nén — và đó chính là cái bẫy suýt khiến tôi kết luận ngược. 29/08/2026 · 8 phút đọc

6 Consumer đọc hết sạch rồi mà bảng giám sát vẫn báo lag = 7 — và nó sẽ mãi là 7 'Ghi đúng một lần' là cụm dễ hiểu sai nhất trong Kafka. Mở tệp log ra xem, tôi thấy giao dịch bị huỷ vẫn nằm nguyên trên đĩa và vẫn chiếm offset — đủ để một consumer đã bắt kịp hoàn toàn vẫn hiện lag khác 0 suốt đời. 29/08/2026 · 9 phút đọc

7 '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. 30/08/2026 · 8 phút đọc

8 Cùng một lần sập, ba cách chốt offset: một cách trùng 1.150 tin, một cách trùng 50, một cách mất hẳn 50 tin mà không một lỗi nào — và không cách nào cho ra đúng 5.000 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. 30/08/2026 · 8 phút đọc

9 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. 30/08/2026 · 7 phút đọc

10 Kafka mặc định cho độ trễ 0,35 mili giây — một dòng fetch.min.bytes đẩy nó lên 503 ms, chậm hơn 1.439 lần mà không một lỗi nào, và cắn mạnh nhất lúc vắng khách '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ố. 30/08/2026 · 8 phút đọc

11 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. 30/08/2026 · 7 phút đọc

12 Gửi 1 đến 12 đúng thứ tự, consumer nhận về 1-5-9-2-3-4 — và tăng số partition làm 9 trong 20 khoá đổi chỗ vĩnh viễn, phá thứ tự không cách nào sửa 'Kafka giữ thứ tự tin nhắn' đúng một nửa, và nửa sai là nửa gây sự cố. Tôi đo: thứ tự chỉ được bảo đảm trong một partition, không phải trong một topic. Và vì khoá định tuyến bằng băm chia lấy dư cho số partition, tăng partition làm gần một nửa khoá chuyển chỗ — tin cũ và tin mới của cùng một khoá rơi vào hai partition khác nhau, thứ tự vỡ vĩnh viễn. 30/08/2026 · 8 phút đọc

13 Giết một broker Kafka mất 9,142 giây mới bầu xong leader mới — không phải vì bầu chậm, mà vì phải chờ đủ lâu để chắc chắn nó đã chết chứ không phải chỉ chậm Bản sao là cơ chế Kafka dùng để không mất dữ liệu khi máy chết. Tôi giết máy thật và bấm giờ: 9,142 giây để bầu leader mới, đúng bằng broker.session.timeout.ms — vì không thể phân biệt tức thời 'đã chết' với 'chỉ chậm'. Không mất tin nào, nhưng có tin mất 11,7 giây mới tới, và broker sống lại thì ngồi không cho tới khi được trao lại việc. 30/08/2026 · 8 phút đọc

14 Đặ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ẻ. 30/08/2026 · 8 phút đọc

15 Tôi dựng đúng kịch bản làm Kafka mất 500 tin đã xác nhận, và nhìn bộ đếm offset đi lùi từ 1.500 về 1.000 — thứ Kafka vốn hứa không bao giờ xảy ra Có một tham số Kafka mà bật lên là bạn đồng ý mất dữ liệu trong vài tình huống. Tôi dựng đúng tình huống đó: unclean.leader.election.enable=true cho một bản sao cũ lên làm leader, 500 tin đã ack biến mất, và offset đi lùi — phá vỡ giả định nền của mọi thứ xây trên Kafka. Đây là lựa chọn giữa 'dừng lại chờ' và 'tiến lên với dữ liệu sai'. 30/08/2026 · 8 phút đọc

16 63 dòng chỉ mục cho 4.992 tin, và đọc offset 49.000 nhanh y như đọc offset 0 — bí mật là một chỉ mục thưa đến mức bất ngờ Kafka nhanh vì gần như không làm gì phức tạp trên đĩa. Tôi mở tệp .index ra đọc từng dòng: một segment 4.992 tin chỉ có 63 mục — một dòng cho ~79 tin. Đủ để nhảy gần đúng rồi quét nốt, nên tìm một offset bất kỳ gần như miễn phí. Đây là đánh đổi chỉ mục thưa, và vì sao đọc lại từ giữa log không tốn gì. 30/08/2026 · 9 phút đọc

17 Đặt retention.ms = 20 giây, tin vẫn sống tới 70 giây; đặt retention.bytes = 1 MB, đĩa dùng thật 3,56 MB — hai tham số giữ tin đều không làm đúng cái tên retention.ms là mức *sàn*, không phải hạn chót: việc dọn chạy theo chu kỳ 5 phút và chỉ xoá nguyên cả segment. retention.bytes tính theo từng partition và làm tròn lên một segment, nên đĩa thật gấp 3,4 lần con số bạn viết. Đây là công thức dự trù đĩa đúng, và vì sao 'xoá sau 30 ngày' không phải một bảo đảm tuân thủ. 30/08/2026 · 8 phút đọc

18 30.000 tin với 1.000 khoá, nén xong còn 2.908 chứ không phải 1.000 — 'mỗi khoá một tin' là câu sai, và consumer nào tin nó sẽ đếm nhầm cleanup.policy=compact biến topic Kafka thành gần một bảng khoá–giá trị. Nhưng tôi đo thấy nó không để lại mỗi khoá đúng một tin: phần đầu log vừa ghi vẫn giữ nguyên bản trùng, chỉ phần đuôi đã nén mới sạch. Bảo đảm ở đây là 'rốt cuộc hội tụ về giá trị mới nhất', không phải một bất biến tức thời — và có một cái bẫy bia mộ khiến dữ liệu xoá vẫn còn. 30/08/2026 · 8 phút đọc

19 Xoá sạch bộ đệm trang rồi bắt Kafka đọc lại — chỉ chậm đi 1,6 lần, không phải 100 lần; vì đọc tuần tự thì trượt đệm gần như không đau Kafka hay được khen nhanh nhờ 'zero-copy' và 'page cache', hai cụm từ ít khi được đo. Tôi đo cả hai: một broker 1,2 GB phục vụ 1.130 MB/giây, và khi xoá sạch bộ đệm trang, đọc lạnh chỉ chậm 1,6 lần chứ không phải hai bậc độ lớn — vì Kafka đọc tuần tự, và với truy cập tuần tự thì bộ đệm gần như là tuỳ chọn. 30/08/2026 · 9 phút đọc

20 Kafka mặc định không bao giờ gọi fsync — bật nó lên, thông lượng còn chưa tới một phần ba; độ bền của Kafka đến từ bản sao, không đến từ đĩa Mọi hệ lưu trữ phải trả lời: ghi vào bộ đệm hệ điều hành đã coi là an toàn chưa? Kafka trả lời khác PostgreSQL, và tôi đo cái giá: fsync mỗi lô kéo thông lượng từ 540k xuống 170k tin/giây. Kèm một câu chuyện về phép đo hình chữ U mà tôi suýt công bố — hoá ra do một lệnh tạo topic hỏng bị nuốt lỗi. 30/08/2026 · 9 phút đọc

21 Bỏ ZooKeeper, cả ngăn xếp Kafka dựng trong 2,8 giây thay vì 26,3 — nhưng KRaft không xoá quorum, nó chỉ dời quorum vào trong Kafka Suốt mười năm Kafka cần ZooKeeper; từ 4.0 thì không. Tôi dựng cả hai kiểu cạnh nhau: KRaft nhanh gấp chín lần, nhẹ hơn, bớt một tiến trình. Nhưng bài học đáng nhớ hơn là khi ZooKeeper chết, Kafka vẫn ghi đọc bình thường — chỉ mặt phẳng điều khiển dừng — và bỏ ZooKeeper không có nghĩa bỏ được yêu cầu đa số 2f+1. 30/08/2026 · 8 phút đọc

22 Một tin không đọc nổi khiến consumer ném 8.306.744 ngoại lệ trong 12 giây và khoá cứng cả partition — một vòng thử-lại không chờ không phải là suy thoái, nó là tan chảy Kafka coi mọi tin là mảng byte, nên đổi lược đồ là trách nhiệm của bạn. Tôi đo cái giá khi làm sai: một tin sai kiểu khiến consumer quay ở 692 nghìn ngoại lệ mỗi giây, đốt trọn một nhân CPU, và partition đứng vĩnh viễn ở offset đó. Bảy dòng chữa nó — và cái bẫy thật là một vòng bắt-lỗi lặp lại ngay thao tác vừa hỏng. 30/08/2026 · 9 phút đọc

23 Avro nhỏ hơn JSON 2,5 lần — nhưng sau khi bật nén thì chỉ còn 1,4 lần; cái lợi bạn tưởng mình mua đã được một tầng miễn phí làm hộ Lời khuyên phổ biến là 'đừng dùng JSON trên Kafka, dùng Avro'. Tôi đo cả ba định dạng trên cùng dữ liệu: thô thì Avro nhỏ hơn JSON 2,5 lần nhưng mã hoá lại chậm hơn. Rồi bật nén — mà cụm nào cũng bật — và lợi thế co xuống 1,4 lần, vì nén xoá đúng phần dư thừa (tên trường lặp lại) mà Avro xoá bằng tay. Lý do thật để chọn Avro nằm ở chỗ khác. 30/08/2026 · 8 phút đọc

24 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. 30/08/2026 · 9 phút đọc

25 Tôi bảo Kafka tua về 8 giờ sáng, nó báo 'partition rỗng' rồi nhảy thẳng tới cuối — bỏ qua sạch dữ liệu cần xử lý lại, và tôi tưởng đã xong Khả năng đọc lại dữ liệu cũ là thứ phân biệt Kafka với hàng đợi truyền thống. Tôi đo bốn cách tua offset, và tìm ra cái bẫy trong cách dùng nhiều nhất: --to-datetime với mốc quá dữ liệu không từ chối mà âm thầm lùi về 'latest' — nhảy tới cuối, ngược hẳn ý định — kèm một thông báo 'empty' hoàn toàn gây hiểu nhầm. 30/08/2026 · 9 phút đọc

26 Gói một tin vào một giao dịch Kafka cho ra 96 tin mỗi giây — chậm hơn sáu nghìn lần; gói mười nghìn tin thì chi phí biến mất sạch Chi phí của giao dịch Kafka phụ thuộc hoàn toàn vào một con số bạn tự chọn: cỡ giao dịch. Một tin một giao dịch cho 96 tin/giây, cỡ 10.000 cho 639.285 — nhanh hơn cả không giao dịch. Đó là một chi phí cố định 10,4 mili giây được khấu hao trên số tin; nhưng gói càng lớn thì tin đầu tiên chờ càng lâu, vì read_committed không thấy gì tới khi cả lô cam kết. 30/08/2026 · 9 phút đọc

27 Khởi động lại ngay một ứng dụng Kafka Streams mất 44 giây, nhưng chờ 50 giây rồi mới bật lại chỉ mất 0,4 giây — nghịch lý này có một dòng cấu hình để xoá Kafka Streams chạy xử lý dòng ngay trong ứng dụng của bạn. Tôi đo một phép đếm đơn giản và cả ba con số đều bất ngờ: 200.000 tin vào chỉ cho 5.340 bản ghi ra, trạng thái nằm ở hai nơi, và khởi động lại ngay lập tức chậm hơn khởi động lại sau khi chờ tới 90 lần — vì bản mới đang đợi chính bóng ma của mình hết hạn. 30/08/2026 · 9 phút đọc

28 Cùng một tập dữ liệu, đổi đúng một con số: cửa sổ nối 5 giây cho 0 kết quả, cửa sổ 60 giây cho 5.000 — và trường hợp rỗng không hề báo lỗi Nối hai dòng dữ liệu là việc phổ biến nhất và dễ làm sai nhất trong Kafka Streams. Tôi dựng một phép nối rồi chỉ đổi độ dài cửa sổ: kết quả đi từ đầy đủ xuống bằng không, không một dòng log. Cửa sổ nối so thời gian sự kiện, nên nó phải khớp khoảng cách thật trong nghiệp vụ — và cái giá của cửa sổ dài tỉ lệ với lưu lượng, không với độ dài. 30/08/2026 · 8 phút đọc

29 50.000 UPDATE và 10.000 DELETE trong PostgreSQL sinh ra đúng 0 bản ghi trong Kafka — connector vẫn báo RUNNING, và dữ liệu sai nằm đó vĩnh viễn Kafka Connect đưa dữ liệu vào ra Kafka bằng JSON cấu hình thay vì mã. Tôi dựng đường ống PostgreSQL → Kafka và đo: thông lượng hơn trăm nghìn dòng/giây, nhưng mode=incrementing mù hoàn toàn với UPDATE và DELETE — không lỗi, không log, connector vẫn xanh, trong khi hạ nguồn tính toán trên dữ liệu cũ. Cách bạn phát hiện thay đổi quyết định loại thay đổi bạn thấy được. 30/08/2026 · 8 phút đọc

30 Tôi tạm dừng một connector Debezium đúng 8 giây, PostgreSQL giữ lại 50 MB WAL — và không nhả ra kể cả khi đã bắt kịp; một sự cố hạ nguồn leo ngược lên hệ thống gốc Debezium đọc WAL thay vì hỏi bảng, nên nó bắt được cả UPDATE lẫn DELETE mà JDBC source bỏ sót — kèm cả giá trị 'before' và 'after'. Nhưng cái giá nằm ở phía cơ sở dữ liệu: khe sao chép ghim WAL lại cho tới khi connector xác nhận, nên một consumer chết qua đêm có thể làm đầy đĩa và chặn luôn việc ghi của hệ giao dịch. 30/08/2026 · 8 phút đọc

31 Lag tăng 57 lần trong 60 giây, mà cả ba chỉ số sức khoẻ broker Kafka vẫn xanh mướt — chúng không nói dối, chúng chỉ đang đo sai thứ Kafka phát ra hàng trăm chỉ số qua JMX. Tôi dựng một sự cố thật — consumer treo, dữ liệu ngừng chảy tới hạ nguồn — rồi xem chỉ số nào báo: broker báo hoàn toàn khoẻ suốt cả phút. Bài này chỉ ra bốn chỉ số broker thật sự đáng cảnh báo, và ba chỉ số phía client mới là thứ nói cho bạn biết đường ống có đang chạy hay không. 30/08/2026 · 9 phút đọc

32 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 độ. 30/08/2026 · 9 phút đọc

33 Đặt hạn ngạch 5 MB/giây cho Kafka, client vẫn đẩy lọt 47 MB ở tốc độ 150 MB/giây — và khi bị bóp, nó chỉ thấy độ trễ 10,9 giây chứ không một lỗi nào 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. 30/08/2026 · 8 phút đọc

34 Bật TLS cho Kafka làm việc ghi chậm 20%, nhưng việc đọc chậm tới 2,2 lần — cùng một tính năng, hai cái giá lệch hẳn, và lý do nằm ở một đường tắt chỉ phía đọc mới có Tôi dựng một broker Kafka hai cổng — PLAINTEXT và SSL — rồi đo cùng phần cứng, cùng dữ liệu: ghi với TLS chậm 20%, nhưng đọc chậm 2,2 lần, và cột SSL gần như phẳng trong khi PLAINTEXT tăng dần. Khác biệt không phải ngẫu nhiên — mã hoá giết chết sendfile, cái đường tắt zero-copy mà chỉ phía đọc mới được hưởng. 30/08/2026 · 9 phút đọc

35 Bật ACL cho Kafka và broker tự chặn chính mình không khởi động nổi — rồi một producer bị chặn nhận lỗi 'Cluster authorization failed' không hề nhắc tới topic nào Xác thực trả lời 'bạn là ai', ACL trả lời 'bạn được làm gì'. Tôi bật ACL trên cụm thật rồi cấp quyền từng lớp: broker bị chính luật của nó chặn vì lưu lượng nội bộ là ANONYMOUS, đọc cần tới hai ACL, và lỗi của producer idempotent nói về cụm chứ không nói về topic. Mỗi lỗi đều chỉ sai chỗ cần sửa. 30/08/2026 · 8 phút đọc

36 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'. 30/08/2026 · 8 phút đọc

37 Tôi thay cả ba broker Kafka lên phiên bản mới không mất một tin nào — rồi phát hiện cụm vẫn chưa thật sự chạy bản mới; 'đã cài' không bao giờ là 'đã bật' Nâng cấp Kafka không cần dừng dịch vụ, quy trình ngắn hơn nhiều người nghĩ. Tôi chạy nó thật trên cụm đang có producer và consumer hoạt động: thay từng broker, ISR đầy lại sau 1–22 giây, không mất tin. Nhưng nhị phân mới không có nghĩa giao thức đã mới — và khoảng cách đó là một cửa sổ lùi được đặt ra có chủ ý. 30/08/2026 · 8 phút đọc

38 Quên đúng một dòng volume và 10.000 tin biến mất cùng cả topic — không một dòng log nào báo; bốn thứ Docker phải đổi trước khi chạy Kafka thật Chạy Kafka trong Docker để thử nghiệm chỉ cần một lệnh. Chạy nó thật thì cần vài dòng nữa — và bài này đo chuyện gì xảy ra khi thiếu từng dòng: thiếu volume thì mất sạch dữ liệu không một dòng log, giới hạn bộ nhớ 400 MB thì broker bị OOMKilled giữa chừng, và advertised.listeners sai là chỗ hỏng nhiều nhất. 30/08/2026 · 8 phút đọc

39 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. 30/08/2026 · 9 phút đọc

40 Chốt 40 phần Kafka: mười con số không tài liệu nào nói trước, sáu cách Kafka hỏng mà tuyệt nhiên không báo gì, và một quy tắc đo khiến tôi suýt công bố quy luật không tồn tại Bốn mươi phần, mỗi phần một phép đo thật trong container. Bài cuối gom lại những con số đáng mang theo, một bộ cấu hình mặc định mà mọi dòng đều có gốc từ một phép đo, sáu kiểu hỏng im lặng, và bài học đắt nhất: kết quả quá gọn gàng không phải phát hiện — nó là dấu hiệu phép đo đã hỏng. 30/08/2026 · 9 phút đọc