Xin chào, lại là mình - Đức Phúc, anh chàng hơn 6 năm trong nghề vẫn nghèo technical nhưng thích viết Blog để chia sẻ kiến thức bản thân học được trong quá trình “cơm áo gạo tiền” đây. Các bạn có thể theo dõi mình thêm qua một số nền tảng bên dưới nhé:
- Linkedin: https://www.linkedin.com/in/phuc-ngo-728433346
- Viblo: https://viblo.asia/u/NHDPhucIT
- Patreon: https://www.patreon.com/felix_ngo
- Facebook: https://www.facebook.com/DucPhucIT
Tiếp tục chuỗi Series về Kafka, hôm nay chúng ta sẽ đến với Kafka Brokers. Khái niệm mà đã được nhắc tên đến ở những bài trước. Ngoài ra, ta cũng sẽ tìm hiểu về cách mà hoạt động kết hợp với Topic và Topic Replication. Nào, bắt đầu thôi
1. Kafka Brokers
Ở những bài trước, khi nói đến Kafka Topic, chúng ta đã nhắc đến Kafka Cluster. Và nó chính là tập hợp của nhiều Kafka Brokers. Chúng có tên như vậy vì chúng đóng vai trò nhận và gửi dữ liệu, và được đánh dấu bởi ID là 1 số nguyên.
Mỗi Broker sẽ chứa một số Partition nhất định. Điều này đồng nghĩa là dữ liệu sẽ được phân phối trên nhiều Broker
Ở ví dụ trên, ta sẽ có 3 Broker với ID là 101, 102 và 103. Ta cũng có 2 Topic:
- Topic A: 3 Partitions: A1, A2, và A3
- Topic B: 2 Partitions: B1, và B2
Ta cũng sẽ thấy dữ liệu được phân phối trên cả 3 Broker. Đây cũng chính là phần giúp Kafka có thể dễ dàng mở rộng theo chiều ngang (Horizontal Scaling)
2. Bootstrap Server
Ngoài cái tên là Kafka Broker, chúng còn được gọi với tên là “Bootstrap Server”. Chúng có tên như vậy bởi trong 1 Cluster, khi Kafka Client kết nối đến bất kì Broker nào, thì chúng sẽ tự biết cách để kết nối đến tất cả những Broker còn lại
Như hình ảnh minh hoạ, ta sẽ thấy:
- Đầu tiên, Kafka gửi yêu cầu kết nối và Metadata đến Broker 101.
- Broker 101 lúc này sẽ trả về danh sách toàn bộ Broker trong cùng Kafka Cluster
- Lúc này, Kafka Client có thể connect đến bất kì Broker nào mà nó muốn, ví dụ như Broker 105
3. Topic Replication
Có lẽ chúng ta đã không còn xa lạ khi nhắc đến “replication” của 1 thứ gì đó. Và Topic cũng không ngoại lệ. Chúng có thể có nhiều replication (bản sao chép) cho mỗi Topic Partition. Và hiển nhiên, chúng sẽ nằm trên những Broker khác nhau.
Nhờ điều này, mà nếu bất kì Broker nào xảy ra sự cố, ta vẫn sẽ có những phiên bản khác của các Partition để ghi/nhận dữ liệu. Nếu 1 Partition có N replica, Kafka cho phép bạn bị mất kết nối tới N-1 Broker mà dữ liệu vẫn được đảm bảo.
Như ví dụ này, chúng ta sẽ có 3 Broker như trước đó. Topic A lúc này sẽ có 2 Partitions là A1 và A2. Ngoài ra, mỗi Partition sẽ có thêm 1 Replication nằm lần lượt ở Broker 102 và Broker 103.
Như vậy, giả sử Broker 102 gặp sự cố, ta vẫn sẽ còn 2 Broker 101 và 103 chứa đủ cả 2 Partitions A1 và A2. Giúp cho chúng ta không bị mất dữ liệu
4. Leader Partition
Okay, một team sẽ luôn cần 1 Leader đúng không nào? Broker cũng vậy. Tại bất kì thời điểm nào, chỉ có duy nhất 1 Broker đóng vai trò Leader cho 1 Partition.
Quay lại ví dụ lúc trước, ta sẽ thấy:
- Broker 101 là Leader cho Partition A1
- Broker 102 đóng vai trò Leader cho Partition A2
- Broker 103 sẽ là Replica của Partition A2
Như vậy, với mỗi Partition, chúng sẽ có duy nhất 1 Leader, và có thể có nhiều ISR (in-sync replica)
Vậy quá trình gửi và nhận dữ liệu sẽ như thế nào? Mặc định,
- Khi Producer gửi dữ liệu đến Partition, chúng sẽ chỉ gửi đến Broker đang đóng vai trò Leader cho Partition đó
- Tương tự Consumer cũng sẽ đọc dữ liệu từ Broker đóng vai trò Leader cho Partition
Như ví dụ này, Producer muốn gửi dữ liệu đến Partition A1, thì sẽ gửi đến Broker 101 (Leader). Consumer cũng sẽ làm điều tương tự cho việc nhận dữ liệu
Tuy nhiên, từ phiên bản Kafka 2.4 trở đi, Kafka đã giới thiệu “Kafka Consumer Replica Fetching”. Nhờ vậy, mà Consumer bây giờ có thể đọc dữ liệu từ Replica gần nhất của một Consumer, thay vì luôn luôn đọc ở Leader như trước đó
Điều này sẽ giúp giảm đi độ trễ, cũng như chi phí cho phần Network nếu như chúng ta sử dụng Cloud. Vì khi đọc dữ liệu từ cùng 1 nhóm Server gần nhau, chi phí và độ trễ sẽ giảm đi
5. Producer Acknowledgement (acks)?
Producer Acknowledgement là một cơ chế giúp Producer kiểm soát được đã có bao nhiều Brokers xác nhận đã nhận được Message trước khi cân nhắc rằng Message đã được gửi thành công
Chúng ta sẽ có những trường hợp sau đây cho acks
| Giá trị | Ý nghĩa | Độ trễ | Mức độ rủi ro mất dữ liệu | Ví dụ trường hợp sử dụng |
|---|---|---|---|---|
0 |
Không cần xác nhận từ Broker | Thấp nhất | Rất cao | Hệ thống ghi log, metrics, dữ liệu không quan trọng |
1 |
Chỉ cần Leader Broker xác nhận | Thấp | Trung bình | Những trường hợp chấp nhận rủi ro mất một số dữ liệu nhưng không ảnh hưởng đến hệ thống |
all hoặc -1 |
Tất cả Replica (ISR) đều phải xác nhận | Cao nhất | Thấp nhất | Các hệ thống cần độ chính xác cao như Tài chính, E-commerce |
Chúng ta sẽ tiến hành cấu hình những tham số này ở phần sau của Series này nhé, trước mắt, các bạn có thể ghi nhớ kiến thức này trước nha
6. Tổng kết
Okay, vậy là thêm những kiến thức nữa đã được gửi đến các bạn ở bài viết này. Hy vọng chúng sẽ giúp bạn hiểu nhiều hơn về Kafka. Sẽ còn thêm nhiều điều nữa nếu bạn muốn khám phá. Hẹn gặp lại các bạn ở những bài viết tiếp theo
Một lần nữa, đừng quên connect với mình để cùng trao đổi nhé
- Linkedin: https://www.linkedin.com/in/phuc-ngo-728433346
- Viblo: https://viblo.asia/u/NHDPhucIT
- Patreon: https://www.patreon.com/felix_ngo
- Facebook: https://www.facebook.com/DucPhucIT