Đáp án Quiz Kafka — 37 câu hỏi có giải thích

Đáp án: A

Partition. Trong một consumer group, mỗi partition chỉ được một consumer đọc. Nên topic có 6 partition thì tối đa 6 consumer làm việc; consumer thứ 7 sẽ ngồi không.

Đáp án: C

Không. Kafka là log giữ theo thời gian (retention.ms, mặc định 7 ngày) hoặc theo dung lượng. Consumer chỉ di chuyển con trỏ offset của mình; dữ liệu vẫn nằm đó cho group khác đọc hoặc để đọc lại.

Đáp án: B

Số bản ghi giữa offset cuối của partition và offset consumer đã commit — tức consumer đang chậm bao nhiêu bản ghi. Đây là chỉ số sức khoẻ quan trọng nhất của một pipeline Kafka.

Đáp án: A

Producer rải đều theo lô (sticky partitioner: gom một batch vào một partition rồi chuyển sang partition khác). Có key thì partition = hash(key) % số partition, nên cùng key luôn cùng partition.

Đáp án: D

Mỗi group nhận toàn bộ tin nhắn, độc lập nhau, vì offset lưu riêng theo group. Chia việc chỉ xảy ra giữa các consumer *trong cùng* một group — đây là cơ chế để Kafka làm được cả pub/sub lẫn hàng đợi.

Đáp án: C

Chuyển dữ liệu vào/ra Kafka bằng connector khai báo qua cấu hình: source connector đọc từ Postgres/MySQL/S3 ghi vào topic, sink connector đọc topic ghi ra Elasticsearch/S3/data warehouse.

Đáp án: C

Mỗi partition tồn tại 3 bản trên 3 broker khác nhau: một leader xử lý đọc ghi, hai follower sao chép lại. Mất một broker vẫn còn 2 bản, nên cluster tiếp tục chạy.

Đáp án: C

Số thứ tự tăng dần trong một partition, gán bởi broker khi ghi. Cặp (topic, partition, offset) mới xác định duy nhất một bản ghi — offset một mình thì không, vì mọi partition đều bắt đầu từ 0.

Đáp án: B

--partitions (mức song song tối đa), --replication-factor (khả năng chịu lỗi, thường 3), và retention.ms hoặc retention.bytes. Đừng để mặc định vì mặc định của cluster hiếm khi khớp nhu cầu của topic.

Đáp án: D

Các consumer cùng định danh group chia nhau các partition và dùng chung vị trí đọc đã lưu. Đổi định danh nghĩa là tạo một bên tiêu thụ mới, bắt đầu từ vị trí do cấu hình quy định — thường là từ đầu hoặc từ cuối topic.

Đáp án: D

Chỉ trong một partition. Muốn các sự kiện của cùng một thực thể giữ đúng thứ tự thì ghi chúng với cùng key (ví dụ orderId) — cùng key thì cùng partition.

Đáp án: A

3 consumer nhận mỗi cái một partition, 2 consumer rỗi hoàn toàn. Chúng không lỗi và vẫn ở trong group — hữu ích như bản dự phòng, vì nếu một consumer chết thì rebalance sẽ gán partition cho consumer đang rỗi.

Đáp án: D

acks=1 chỉ chờ leader ghi xong; leader chết trước khi bản sao kịp lấy dữ liệu là mất tin nhắn. acks=all chờ toàn bộ bản sao trong ISR xác nhận, nên bền hơn với giá là độ trễ cao hơn.

Đáp án: D

Bản ghi mới nhất của mỗi key; các bản cũ hơn cùng key bị dọn dần. Log trở thành trạng thái hiện tại chứ không phải lịch sử — dùng cho topic kiểu bảng: thông tin user, cấu hình, tồn kho.

Đáp án: B

Consumer bị đá khỏi group, group rebalance, và tin nhắn đó được giao cho consumer khác — nên nó bị xử lý lại, có thể lặp vô hạn. Đây là nguyên nhân kinh điển của "rebalance liên tục".

Đáp án: D

Offset được commit theo chu kỳ thời gian, không theo tiến độ xử lý thật. Nếu chu kỳ đó rơi vào giữa lúc đang xử lý và consumer chết, các tin nhắn đã được commit nhưng chưa xử lý sẽ không bao giờ được đọc lại — mất dữ liệu âm thầm.

Đáp án: A

Trùng lặp do producer retry: mạng lỗi sau khi broker đã ghi nhưng phản hồi không về, producer gửi lại và tạo bản ghi thứ hai. Idempotent producer gắn id producer + số thứ tự nên broker loại được bản trùng.

Đáp án: A

Dead-letter topic: ghi bản ghi lỗi kèm thông tin lỗi sang một topic riêng, commit offset, rồi xử lý tiếp. Retry mãi sẽ chặn toàn bộ partition — bản ghi phía sau không được xử lý dù chúng hoàn toàn hợp lệ.

Đáp án: D

Khi dữ liệu là dòng sự kiện cần giữ lại: nhiều consumer độc lập đọc cùng nguồn, cần phát lại lịch sử, thông lượng rất cao. RabbitMQ hợp hơn cho hàng đợi công việc với định tuyến phức tạp, priority, TTL từng tin.

Đáp án: B

Tập bản sao đang theo kịp leader (không tụt quá replica.lag.time.max.ms). acks=all chờ đúng tập này, và khi cần chọn leader mới thì chỉ bản sao trong ISR được chọn nếu không muốn mất dữ liệu.

Đáp án: B

Producer chờ tới 20ms để gom thêm bản ghi vào một batch: ít request hơn, nén tốt hơn, thông lượng cao hơn, đổi lại độ trễ tăng tối đa 20ms. Với pipeline theo lô thì đây là đánh đổi rất đáng.

Đáp án: A

Dừng hết consumer của group, rồi kafka-consumer-groups.sh --reset-offsets --to-earliest --execute. auto.offset.reset=earliest không giúp gì ở đây vì group đã có offset commit — nó chỉ áp dụng cho group mới.

Đáp án: B

Có partition mà số bản sao trong ISR ít hơn replication factor. Đây là chỉ số cảnh báo hàng đầu: giá trị lớn hơn 0 kéo dài nghĩa là cluster đang mất khả năng chịu lỗi.

Đáp án: D

Khi xử lý có trạng thái: đếm theo cửa sổ, join hai luồng, tổng hợp theo key. Tự làm những việc đó với consumer thường nghĩa là tự xây state store bền vững, phục hồi sau sự cố, và xử lý dữ liệu tới muộn.

Đáp án: B

Bản ghi đã vào bộ đệm của producer nhưng không gửi được trong delivery.timeout.ms (mặc định 2 phút) nên bị loại bỏ. Nguyên nhân hay gặp: broker không sẵn sàng, mạng nghẽn, hoặc ứng dụng ghi nhanh hơn tốc độ gửi.

Đáp án: D

Backward compatible: consumer chạy schema mới đọc được bản ghi ghi bằng schema cũ, vì field thiếu lấy giá trị mặc định. Đây là mức tương thích mặc định của Schema Registry.

Đáp án: B

Không tự chuyển. Broker mới chỉ nhận partition của topic tạo sau đó. Muốn chuyển dữ liệu cũ thì chạy kafka-reassign-partitions.sh với kế hoạch phân bổ mới.

Đáp án: D

subscribe() tham gia consumer group: Kafka gán partition, tự rebalance khi có consumer vào/ra. assign() chỉ định thẳng partition — không group, không rebalance, và ứng dụng tự lo việc phân chia.

Đáp án: A

pause(partitions) rồi resume(partitions). Điểm quan trọng: vẫn tiếp tục gọi poll() trong lúc pause — nhờ đó heartbeat và giới hạn max.poll.interval.ms được thoả, consumer không bị đá khỏi group.

Đáp án: A

Nhân bản dữ liệu giữa các cluster: cluster dự phòng ở vùng khác, gom dữ liệu từ nhiều vùng về một chỗ phân tích, hoặc di chuyển sang cluster mới. Nó được xây trên Kafka Connect.

Đáp án: C

Mặc định tách theo loại sự kiện — consumer chỉ đăng ký thứ nó cần, retention và schema riêng. Ngoại lệ: các sự kiện của cùng một thực thể mà thứ tự tương đối quan trọng (OrderCreated, OrderPaid, OrderCancelled) nên ở cùng topic, cùng key.

Đáp án: B

ACL gắn với principal lấy từ bước xác thực (SASL hoặc mTLS): mỗi rule cho phép một principal thực hiện một thao tác trên một resource. Không có xác thực thì ACL vô nghĩa vì ai cũng khai mình là ai được.

Đáp án: C

Giảm retention.ms (hoặc đặt retention.bytes) cho các topic to nhất bằng kafka-configs.sh --alter. Thay đổi áp dụng ngay, broker sẽ dọn segment quá hạn trong chu kỳ dọn kế tiếp. Đừng bao giờ xoá file log bằng tay.

Đáp án: D

Consumer xin một offset không còn tồn tại — dữ liệu ở đó đã bị dọn theo retention. Kịch bản kinh điển: consumer chết hoặc bị tắt lâu hơn thời gian giữ của topic, quay lại thì offset cũ đã bay.

Đáp án: D

Record header — các cặp key-value gắn kèm mỗi bản ghi, có từ Kafka 0.11. Đọc được mà không cần giải mã payload, nên rất phù hợp cho trace id, phiên bản schema, hay thông tin lỗi khi đẩy sang dead-letter topic.

Đáp án: C

Nén diễn ra ở phía producer theo cả lô và dữ liệu giữ nguyên trạng thái nén tới tận consumer. Nhờ vậy tiết kiệm băng thông giữa producer và broker, giữa các broker khi nhân bản, và giữa broker với consumer — chứ không chỉ tiết kiệm dung lượng đĩa.

Đáp án: C

Giới hạn băng thông đọc ghi và thời gian xử lý yêu cầu theo từng client hoặc từng người dùng. Mục đích là ngăn một ứng dụng chiếm hết năng lực của cụm và làm ảnh hưởng mọi ứng dụng khác — vấn đề hàng xóm ồn ào trong cụm dùng chung.