Hi các bài, bài hôm nay mình sẽ về nói về offset và cơ chế chống lỗi.

The Log

Phần 3 đang kết thúc ở việc giới thiệu cách tổ chức dữ liệu Trong kafka: 1 Kafka Cluster có nhiều Topic, mỗi Topic gồm nhiều Partition, mỗi Partition là tập hợp nhiều Segment.

Vậy là dữ liệu thực sẽ được lưu trong Segment, các file dữ liệu trong Kafka gọi là log file (đừng nhầm với loại file log của hệ thống sinh ra, đây chính là file dữ liệu), các message (bản ghi dữ liệu) được ghi lần lượt trong file log này.

Các bản ghi sẽ được đánh thứ tự, gọi là offset, bắt đầu từ 0 và tăng dần. Offset được quản lý ở mức Partitions, VD 1 topic có 3 Partition thì sẽ có 3 offset 0 ở partition 1, partition 2 và partition 3

Trên 1 Partition, user có thể vừa ghi mới vừa đọc dữ liệu đồng thời, phục vụ tốt cho các ứng dụng streaming (xem lại phần Decoupling Producer & Consumer).

Brokers Manage Partitions

Vậy là mình đã nói toàn bộ cấu trúc lưu trữ dữ liệu trong Kafka, từ lớp ngoài cùng là Kafka Cluster đến từng bản ghi nhỏ là message, hãy đi đến 1 vài kết luận để bạn thực sự hiểu hơn về các khái niệm này:

• Về mặt logic, các bản ghi của 1 topic được phân tán trên các Partitions
• Partitions lại được phân tán trên các Brokers
• Mỗi Broker quản lý nhiều partitons
• Mỗi partitions được lưu trữ trên ổ đĩa của Brokes
• Mỗi bản ghi được định danh thông qua số thứ tự, gọi là offset
• Dữ liệu được lưu trữ trong khoảng thời gian retention có thể cấu hình được, sau khoảng thời gian này kafka sẽ xóa dữ liệu cũ đi.

Kafka Replication-factor, Leader — Follower

Việc đảm bảo dữ liệu trong bất kì hệ thống phân tán nào cũng là cực kì quan trọng, Kafka cũng vậy và Replica-factor là cơ chế được sử dụng để nhân bản dữ liệu thành nhiều bản khác nhau, lưu trữ trên các broker khác nhau, có như vậy khi 1 Broker down, ta không bị mất mát dữ liệu, các ứng dụng producer, consumer cũng không bị ảnh hưởng do đã có các bản sao dự phòng ở broker khác.

Việc replicate dữ liệu trên Kafka là ở mức partitions, theo mặc định, mỗi partition sẽ được tạo ra thêm 2 bản sao dự phòng nữa, tổng cộng sẽ có 3 bản sao chép của partitions dữ liệu, trải đều trên các broker, hãy nhìn ảnh dưới đây:

Lúc này câu hỏi đặt ra là ta chỉ cần đọc dữ liệu 1 partition mà có tới 3 bản sao thì sẽ phải đọc từ bản sao nào? Kafka đưa ra khái niệm Leader, đại diện cho partition được ưu tiên đọc và ghi dữ liệu. Khi có dữ liệu mới đẩy vào hoặc yêu cầu đọc dữ liệu ra, partition leader sẽ được ưu tiên đọc, ghi trước, sau đó các partition bản sao (gọi là Follower) sẽ sao chép lại dữ liệu từ leader về dự phòng.

Apache Zookeeper

Trước khi nói đến các phần sâu hơn hãy nói qua 1 chút về Zookeeper. Tất nhiên đây không phải là bài giới thiệu về Zookeeper, mình chỉ nói về các nội dung mà Kafka sử dụng từ Zookeeper.

Như các phần trước, 1 cụm Kafka là tập hợp của nhiều Brokers, các broker này hoạt động song song với nhau để quản lý dữ liệu ra vào. Rõ ràng không có 1 mô hình Master-Slave nào ở đây, có nghĩa là bất kì Broker nào đều có vai trò ngang với các Broker khác. Vậy làm sao Kafka duy trì được điều này, làm sao để các Broker “nói chuyện” được với nhau.

Zookeeper (ZK) được sử dụng ở đây như là 1 “distributed coordination”. Có thể hiểu là ZK cung cấp dịch vụ cho phép các client có thể “nhìn” chung dữ liệu với nhau (sự phối hợp làm việc — coordination), VD Client A ghi dữ liệu thì ngay lập tức Client B khác có thể nhìn thấy thay đổi ấy, điều này rất quan trọng trong môi trường phân tán, khi tìm hiểu về HA của Hdfs hay Yarn, các bạn cũng sẽ thấy các nội dung về ZK.

Đơn vị quản lý dữ liệu của ZK là node, bản thân 1 node có thể chứa cả dữ liệu và các node con bên trong

Toàn bộ thông tin về topics và partitions của 1 cluster đều được lưu trên ZK, đó là lý do tại sao khi cài Kafka bạn luôn được yêu cầu cài đặt ZK, mặt định, node ZK được sử dụng để lưu thông tin về cụm Kafka là /brokers, trong đây sẽ chứa thông tin về id của Broker, các topics và partitons.

Thêm vào đó, thông tin Leader của các partition cũng được lưu trữ trên Zookeeper, Khi có sự kiện thêm hoặc mất broker, thông tin trên ZK sẽ giúp toàn bộ các broker còn lại biết được hiện trạng của cụm để có những điều chỉnh phù hợp về leader.

Như trên hình, khi Broker 4 bị down, topic 1, partition 4 lúc này sẽ không còn leader, Kafka tự động bầu ra 1 leader mới trên Broker 2, do đã có dữ liệu dự phòng, việc đọc ghi dữ liệu sẽ được tiếp tục mà vẫn đảm bảo tính đúng đắn của dữ liệu.

Link bài viết gốc tại đây

Bài viết đăng tải lại dưới sự cho phép của tác giả : thầy Nguyễn Chí Thanh là giảng viên khoá Big Data tại Techmaster