Podcast

1. Kafka là gì

1. Lịch sử ra đời
2. Một hệ thống thương mại điện tử khi kết nối đến database, vì vậy sẽ có data pipeline như sau: 
   
3. Nhưng thực tế còn kết nối với rất nhiều hệ thống khác: 
   
4. Như vậy, data pipeline càng ngày càng phức tạp. Kafka tách rời các data pipeline giữa các hệ thống để làm cho việc communicate giữa các hệ thống trở nên đơn giản hơn và dễ quản lý hơn.

1. Khái niệm
2. Là 1 loại Message Queue
3. Là hệ thống xử lý message phân tán
4. Được thiết kế để xử lý, lưu trữ và truyền tải message trong các ứng dụng theo thời gian thực, dựa trên mô hình pub/sub

2. Message queue là gì

1. Là kiến trúc dùng để giao tiếp bất đồng bộ giữa các thành phần trong hệ thống
2. Dữ liệu được gửi và nhận thông qua hàng đợi (queue) và xử lý theo thứ tự (FIFO: vào trước ra trước) 
   

3. Mục đích sử dụng message queue

1. Tách biệt các thành phần (producer, consumer) không bị phụ thuộc vào nhau
2. Đảm bảo xử lý bất đồng bộ: tăng hiệu suất và xử lý song song
3. Đảm bảo tin cậy: message được lưu trữ trên queue cho đến khi Consumer xử lý xong và ngăn mất dữ liệu khi hệ thống gặp sự cố
4. Dễ dàng mở rộng
5. Giảm tải cho hệ thống xử lý công việc dần dần

4. Có các loại công nghệ message queue nào ngoài kafka

1. RabbitMQ
2. AWS SQS
3. Azure Event Hub

5. Vậy trước đây hệ thống dùng gì trước khi sử dụng message queue

1. Request Http Api: Có độ trễ
2. Sử dụng qua db chung (A ghi - B đọc): ko real time (chờ schedule)
3. Polling: Tốn tài nguyên và ko real time

6. Mô tả cấu trúc chung của kafka

1. Producer

1. Khái niệm: Là 1 client application, publish message vào 1 topic cụ thể và luôn ghi vào leader broker
2. Theo mặc định, message được ghi đều vào các partition (có thể set key để chọn partition)
3. Quá trình gửi message tới Kafka gồm 4 bước:
4. Bước 1: Tạo ProducerRecord (Bắt buộc có topic và value, ko bắt buộc key và partition)
5. Bước 2: Serializer (Trước khi gửi qua network nó sẽ tuần tự hóa key và value thành dạng ByteArrays (mảng các Bytes)
6. Bước 3: Xác định số partition (Dữ liệu được gửi tới partition chỉ định, nếu không có chỉ định thì theo ProducerRecord key)
7. Bước 4: Broker xử lý event và trả về cho Producer (Nếu gửi thành công sẽ return partition, offset message, còn lỗi sẽ thông báo cho Producer và message được retry vài lần trước khi báo lỗi)

2. Broker

1. Là máy chủ server nằm trong Kafka Cluster.
2. Broker chịu trách nhiệm lưu trữ và xử lý message
3. Quản lý partition, lưu message trong commit log, xử lý replication

3. Topic

1. Là kênh hoặc danh mục để nhóm message
2. Là nơi producer gửi message và consumer lấy dữ liệu.
3. 1 topic sẽ chứa n partition

4. Partition

1. Partition chia topic thành nhiều phần, để tăng khả năng xử lý song song và phân tán.
2. Mỗi message sẽ được gán 1 offset duy nhất, bắt đầu từ 0 và tăng dần (Offset dùng để xác định vị trí của message trong partition)
3. Mỗi partition được lưu trữ trên 1 broker chính (leader) và cho phép sao chép sang nhiều broker khác (follower) ngăn ngừa mất dữ liệu trong các trường hợp broker bị lỗi
4. Nếu 1 broker lỗi, 1 trong những follower sẽ được chọn làm leader nhằm đảm bảo tính khả dụng dữ liệu.

5. Consumer

1. Là thành phần nhận và xử lý message từ Kafka.
2. Kết nối tới topic để đọc message từ các partition theo thứ tự offset
3. Có 3 trường hợp đọc từ partition:
4. Trường hợp 1: Số Consumer < số Partition (Consumer 1,2 sẽ đọc lần lượt từ 4 Partition)
   
5. Trường hợp 2: Số Consumer = số Partition (Mỗi Consumer sẽ đọc từ 1 Partition, việc tăng Consumer sẽ chia tải và đọc message nhanh hơn) 
   
6. Trường hợp 3: Số Consumer > số Partition (Không nên dùng vì 1 vài Consumer trở nên nhàn rỗi gây tốn tài nguyên)
   

6. Consumer Group

1. Là nhóm các consumer cùng đọc một topic (n group có thể cắm vào 1 topic)
2. Mỗi message chỉ được một consumer trong nhóm xử lý.
3. Hỗ trợ xử lý song song, chia tải giữa các consumer

7. Consumer offset

Là vị trí message mà consumer đọc đến trong partition của topic, giúp khôi phục lại quá trình tiêu thụ sau khi gặp sự cố.

8. Delivery Semantic

Là quy tắc đảm bảo message được gửi và nhận đặc biệt là khi gặp sự cố

1. At Most Once: Message có thể bị mất nhưng không bị gửi nhiều lần; không có cơ chế retry.
2. At Least Once: Message được gửi ít nhất 1 lần; nếu broker ko xác nhận (acks) thì nó sẽ gửi lại.
3. Exactly Once: Message đc gửi 1 lần ko bị mất và ko bị trùng lặp; sử dụng cơ chế idempotence.

9. Retention

Là chính sách quản lý thời gian dữ liệu được lưu trữ trong hệ thống trước khi bị xóa

1. Dữ liệu được giữ trong khoảng thời gian xác định: 7d, 30d,..
2. Dữ liệu được giữ với kích thước tối đa: 100GB,...
3. Xóa dữ liệu khi đạt trạng thái hoặc điều kiện nhất định

10. Fault Tolerance

Là khả năng của 1 hệ thống tiếp tục hoạt động khi 1 hoặc n thành phần gặp sự cố

1. Replication: Dữ liệu được sao chép trên nhiều broker.
2. Khôi phục dữ liệu ack từ Producer:
3. ack = 0: không cần xác nhận.
4. ack = 1: Broker leader xác nhận thành công.
5. ack = all: Chỉ xác nhận khi tất cả replica đã ghi thành công.

1. Consumer Offset: lưu lại vị trí đọc để khôi phục.

11. Replication

1. Partition trên broker (Ví dụ):
2. Broker 1: Partition 0, Partition 3, Partition 6
3. Broker 2: Partition 1, Partition 4, Partition 7
4. Broker 3: Partition 2, Partition 5

1. Set leader và follower sẽ nằm ở các broker còn lại.

7. Scale Application dùng kafka như thế nào

1. Chia partition: Tăng khả năng xử lý đồng thời
2. Tăng Broker: Tăng khả năng replication và dung lượng lưu trữ
3. Tăng Consumer: Tăng tốc độ đọc message và tự động cân bằng tải
4. Tăng producer: Tăng khả năng ghi message vào topic nhanh hơn

8. Kafka với Zookeeper (from which version), quorum?

1. Loại bỏ từ ver 2.8.0 (tháng 4/2021)
2. Hạn chế của zookeeper:
   1. Chỉ hỗ trợ khoảng 200,000 partition
   2. Việc bầu chọn lại leader có thể làm chậm hệ thống
   3. Việc cài đặt phức tạp
3. Zookeeper có tác dụng: Quản lý metadata, chọn leader partition, xử lý sự cố broker.
4. Nếu bỏ zookeeper: KRaft quản lý metadata trực tiếp trong Kafka, tăng khả năng mở rộng đến hàng triệu partition.

9. Nhược điểm của kafka

1. Nhược điểm chung: Cấu hình phức tạp, yêu cầu tài nguyên lớn, không phù hợp với hệ thống message nhỏ.
2. So với message queue khác: Không có tính năng ưu tiên message, không có công cụ quản lý sẵn.
3. So với không dùng message queue: Chi phí tài nguyên, message không tự động xóa ngay sau khi xử lý.

10. Trường hợp nào nên sử dụng kafka

1. Dữ liệu lớn (Big Data): throughput cao.
2. Xử lý theo thời gian thực: Real time analytics.
3. Hệ thống phân tán và microservices: Truyền dữ liệu giữa các service.
4. Tối ưu hóa luồng công việc: Đảm bảo thứ tự và không mất mát.
5. Khả năng mở rộng dễ dàng: Tăng số lượng broker không làm giảm hiệu suất.