HackMD
Leader partition concept
Ở bài trước, ta dùng replication factor để replicate các partition và lưu trữ trên các kafka broker. Kafka sẽ có 1 và chỉ 1 replication partition là leader, chính vì thế việc read/write message sẽ đều thông qua partition này.
- Tại một thời điểm, mỗi partition có duy nhất một replication leader.
- Chỉ có thể read/write message từ replication leader.
- Các replication còn lại được gọi là ISR, đồng bộ message từ replication leader.
- Do vậy, mỗi partition có duy nhất một replication leader và một hoặc nhiều ISR - in-sync replica.
Trong trường hợp Broker 101 gặp sự cố, replication leader của partition 1 không còn hoạt động. Lúc này, một trong các ISR còn lại sẽ trở thành Leader và partition trở lại hoạt động bình thường.
Một câu hỏi khác được đặt ra - Ai là người quyết định replication nào trở thành Leader hay ISR? Đó là nhiệm vụ của ZooKeeper.
Producer
Producer
Producer là người gửi message đến Message broker. Cụ thể với Kafka, producer write data vào partition của topic.
Producer tự động biết nên write vào broker nào và partition nào. Trong trường hợp đang write data mà broker gặp sự cố, producer sẽ có cơ chế tự động retry cho đến khi thành công.
Trong trường hợp gửi message đến topic mà không chỉ định partition, producer sẽ gửi message đến broker theo cơ chế round-robin.
Tiếp tục đến bài toán khác, làm thế nào producer biết message đã được write thành công ở partition? Chẳng cách nào khác ngoài cơ chế ack - acknowledgment.
Producer có thể lựa chọn nhận ack từ Kafka để chắc chắn rằng message được gửi thành công:
- acks=0: giống fire-and-forget, gửi message mà không chờ phản hồi. Do vậy có thể dẫn đến tình huống mất message.
- acks=1: default setting. Lần này chắc chắn hơn, producer chờ cho tới khi nhận được phản hồi từ replication leader. Tuy nhiên chưa ngăn chặn hoàn toàn việc mất message. Replication leader write message thành công, báo lại cho producer, tuy nhiên broker có thể gặp sự cố với disk, không thể khôi phục data.
- acks=all: lần này thì quá chắc chắn, đảm bảo không mất message. Producer sẽ nhận được phản hồi khi tất cả replication leader và IRS write data thành công.
Dễ dàng nhận thấy cái giá phải trả cho việc đảm bảo không mất message là performance.
Message key
Làm thế nào để điều hướng message đến chính xác partition mình mong muốn để đảm bảo message ordering? Có 3 cách để thực hiện việc này:
- Thứ nhất: thêm key cho message. Default, Kafka sử dụng hash key partitioning để tìm partition cho message. Đảm bảo cùng key sẽ cùng partition.
- Cách thứ hai: hardcode, chỉ định partition cho message, thực tế không mấy khi làm như vậy.
- Cuối cùng: tự define cơ chế partitioning, routing message bằng cách implement interface Partitioner.
Nếu muốn các message liên quan với nhau được gửi vào cùng partition và order theo thứ tự, cần define key cho mỗi message.
- Key có thể là bất kì loại dữ liệu nào: string, number…
- Nếu key = null, message được gửi đến broker/partition theo cơ chế round-robin.
- Nếu key != null, tất cả các message có cùng key sẽ đi vào cùng broker/partition.
Kafka sử dụng các thuật toán hashing và rounting để điều phối message có cùng key đến cùng partition. Chúng ta hoàn toàn có khả năng điều phối message đến chính xác partition mong muốn bằng cách đọc code Kafka, tuy nhiên nó chẳng giúp giải quyết vấn đề gì.
Consume
Consume
Consumer là đầu nhận message.
- Consumer đọc message từ topic, xác định bằng topic name.
Đồng thời, consumer biết nên đọc message từ broker nào. - Trong trường hợp chưa read xong mà broker gặp sự cố, consumer cũng có cơ chế tự phục hồi.
- Việc đọc message trong một partition diễn ra tuần tự để đảm bảo message ordering. Có nghĩa là consumer không thể đọc message offset=3 khi chưa đọc message offset=2.
- Một consumer cũng có thể đọc message từ một hoặc nhiều hoặc tất cả partition trong một topic.
- Message ordering chỉ đảm bảo trong một partition. Việc đọc ghi message giữa nhiều partition không đảm bảo thứ tự.
- Message offset=5 ở partition 0 có thể được đọc trước message offset=2 ở partition 1.
Consume group
Quay lại phần trước, consumer là nơi đọc message từ topic. Có nghĩa là một consumer có thể đọc toàn bộ message của tất cả partition thuộc cùng topic.
Nếu số lượng producer tăng lên và đồng thời gửi message đến tất cả partition trong khi chỉ có duy nhất một consumer thì khả năng xử lý sẽ rất chậm, có thể dẫn tới bottle-neck. Giải pháp là tăng số lượng consumer, các consumer có thể xử lý đồng thời message từ nhiều partition. Và tất cả các consumer sẽ thuộc cùng một nhóm được gọi là consumer group.
Như vậy, consumer group read toàn bộ data của các partition và chia vào các consumer bên trong để xử lý.
Mỗi consumer thuộc consumer group sẽ đọc toàn bộ data của một hoặc nhiều partition để đảm bảo message ordering. Không tồn tại nhiều consumer cùng đọc message từ một partition.
Một consumer có thể nhận message từ nhiều partition. Nhưng một partition không thể gửi message cho nhiều consumer trong cùng consumer group.
Nếu số lượng consumer trong consumer group lớn hơn số lượng partition thì những consumer dư thừa có trạng thái inactive - không nhận bất kì message nào từ topic.
Một vài trường hợp số lượng consumer trong group sẽ lớn hơn số lượng partition.
Trong trường hợp một active consumer gặp vấn đề và không thể tiếp tục hoạt động, một trong những inactive consumer còn lại được đẩy lên thay thế và tiếp tục công việc ngay lập tức.
Nếu không có inactive consumer nào, message sẽ được route tới một active consumer bất kì khác.
Quá trình re-assign này được gọi là partition rebalance
Chia thành càng nhiều partition và càng nhiều consumer thì số lượng message được xử lý đồng thời càng nhiều, phần nào cải thiện performance của hệ thống.
- Từ 1 partition/1 consumer thành 5 partition/5 consumer khả năng sẽ đem lại performance tốt.
- Nhưng lên 1000 partition/1000 consumer thì chưa chắc.
Queue và Topic trong Apache Kafka
- Nếu một topic có duy nhất một consumer group, nó là point-to-point messaging - queue.
- Ngược lại nếu muốn implement hệ thống broadcast messaging topic, hãy tạo ra nhiều consumer group subcribe trên cùng một topic.
