Giới thiệu
Apache Kafka là một nền tảng phát trực tuyến sự kiện phân tán, được sử dụng để xuất bản, lưu trữ và xử lý các luồng bản ghi một cách đáng tin cậy và có khả năng mở rộng theo chiều ngang. Kafka được sử dụng rộng rãi cho việc theo dõi hoạt động, phân tích thời gian thực, xử lý luồng và như một bus dữ liệu trung tâm giữa các microservices và hệ thống dữ liệu. Tài liệu chính thức mô tả Kafka như một hệ thống phân tán gồm các broker và client với một giao thức TCP hiệu suất cao, được thiết kế để phục vụ như một commit-log bền vững và có thứ tự.
Các khái niệm cốt lõi và kiến trúc
Một sự kiện ghi lại thực tế rằng "điều gì đó đã xảy ra" trong thế giới hoặc trong doanh nghiệp của bạn. Nó cũng được gọi là bản ghi hoặc thông điệp trong tài liệu. Khi bạn đọc hoặc ghi dữ liệu vào Kafka, bạn thực hiện điều này dưới dạng các sự kiện. Về mặt khái niệm, một sự kiện có một khóa, giá trị, dấu thời gian và tiêu đề metadata tùy chọn. Dưới đây là một ví dụ về sự kiện:
Khóa sự kiện: "Alice"
Giá trị sự kiện: "Đã thanh toán 200 đô la cho Bob"
Dấu thời gian sự kiện: "25 tháng 06, 2020 lúc 2:06 chiều"Producers là những ứng dụng client xuất bản (ghi) các sự kiện vào Kafka, và consumers là những người đăng ký (đọc và xử lý) các sự kiện này. Trong Kafka, producers và consumers hoàn toàn tách biệt và không phụ thuộc vào nhau, điều này là yếu tố thiết kế chính để đạt được khả năng mở rộng cao mà Kafka nổi tiếng. Ví dụ, producers không bao giờ cần phải chờ đợi consumers. Kafka cung cấp nhiều đảm bảo như khả năng xử lý sự kiện chính xác một lần.
Các sự kiện được tổ chức và lưu trữ bền vững trong các topics. Đơn giản hóa, một topic giống như một thư mục trong hệ thống tệp, và các sự kiện là các tệp trong thư mục đó. Tên topic có thể là "payments". Các topic trong Kafka luôn là multi-producer và multi-subscriber: một topic có thể có không, một hoặc nhiều producers ghi sự kiện vào nó, cũng như không, một hoặc nhiều consumers đăng ký những sự kiện này. Các sự kiện trong một topic có thể được đọc nhiều lần như cần thiết - khác với các hệ thống nhắn tin truyền thống, các sự kiện không bị xóa sau khi tiêu thụ. Thay vào đó, bạn định nghĩa thời gian mà Kafka nên giữ các sự kiện của bạn thông qua cài đặt cấu hình theo từng topic, sau đó các sự kiện cũ sẽ bị loại bỏ. Hiệu suất của Kafka thực sự không thay đổi theo kích thước dữ liệu, vì vậy việc lưu trữ dữ liệu lâu dài là hoàn toàn hợp lý.
Các topics được phân vùng, có nghĩa là một topic được trải rộng trên một số "thùng" nằm trên các broker Kafka khác nhau. Việc phân phối dữ liệu này rất quan trọng cho khả năng mở rộng vì nó cho phép các ứng dụng client đọc và ghi dữ liệu từ/đến nhiều broker cùng một lúc. Khi một sự kiện mới được xuất bản vào một topic, nó thực sự được thêm vào một trong các phân vùng của topic đó. Các sự kiện có cùng khóa sự kiện (ví dụ: ID khách hàng hoặc phương tiện) sẽ được ghi vào cùng một phân vùng, và Kafka đảm bảo rằng bất kỳ consumer nào của một topic-partition nhất định sẽ luôn đọc các sự kiện của phân vùng đó theo đúng thứ tự mà chúng được ghi.
Topic: orders
Partitions: P0, P1
Broker A (người lãnh đạo P0) Broker B (người lãnh đạo P1)
| |
v v
Replica trên Broker C Replica trên Broker A
( người theo dõi ) ( người theo dõi )Producers & consumers; nhóm consumer
Producers xuất bản các bản ghi vào các topic (tùy chọn điều khiển sự lựa chọn phân vùng). Consumers đọc từ các topic; những consumer thuộc cùng một nhóm consumer phối hợp để mỗi phân vùng được tiêu thụ bởi đúng một thành viên trong nhóm - cho phép cả xử lý song song và khả năng mở rộng. Các offsets (theo phân vùng) theo dõi tiến trình đọc và có thể được cam kết tự động hoặc thủ công để đảm bảo xử lý mạnh mẽ hơn.
Các ngữ nghĩa giao hàng, offsets và giữ lại
- Kafka hỗ trợ các ngữ nghĩa giao hàng có thể cấu hình:
- Tối đa một lần (producer gửi, nhưng offset cam kết trước khi xử lý),
- Tối thiểu một lần (mặc định khi cam kết sau khi xử lý),
- Ngữ nghĩa chính xác một lần (EOS) trong Kafka Streams / transactional API cho xử lý chính xác một lần từ đầu đến cuối giữa producers, brokers và consumers. Các topic cũng có thời gian giữ lại có thể cấu hình: theo thời gian hoặc theo kích thước, và log compaction có thể giữ lại giá trị mới nhất theo khóa cho các topic đã được nén.
Xử lý luồng và Kafka Streams / Connect
Kafka không chỉ là nhắn tin - nó là một nền tảng phát trực tuyến. Hai thành phần cốt lõi:
- Kafka Connect: khung có thể cắm cho việc di chuyển dữ liệu vào/ra khỏi Kafka (nguồn và bể) - ví dụ: JDBC, HDFS, S3, các kết nối đám mây. Rất tốt cho CDC/ETL.
- Kafka Streams: một thư viện Java nhẹ cho việc xây dựng các ứng dụng xử lý luồng có trạng thái và không có trạng thái. Nó hỗ trợ cửa sổ, joins, state stores, và tích hợp với ngữ nghĩa chính xác một lần của Kafka khi được cấu hình.
Các mô hình và kiến trúc kỹ thuật dữ liệu
Lưu trữ sự kiện / commit log
Kafka thường phục vụ như một commit-log bền vững: mọi thay đổi (sự kiện) đều được lưu trữ theo thứ tự, cho phép phát lại và khôi phục. Mô hình này đơn giản hóa việc sao chép trạng thái giữa các hệ thống và tách biệt producers và consumers. Lý do thiết kế ban đầu của LinkedIn cho Kafka nhấn mạnh việc sử dụng một log thống nhất cho cả consumer trực tuyến và ngoại tuyến.
Pipelines ETL và CDC thời gian thực
Các công cụ Change Data Capture (CDC) (Debezium, các kết nối Confluent) truyền phát các thay đổi từ cơ sở dữ liệu vào các topic Kafka; các consumer hạ lưu xử lý làm phong phú, phân tích, hoặc tải dữ liệu vào lakes/warehouses. Độ bền và thời gian giữ lại của Kafka cho phép các consumer muộn và xử lý lại mà không cần phải nhập lại.
Các trường hợp sử dụng
LinkedIn ban đầu xây dựng Kafka để xử lý các luồng hoạt động và nhập log, thống nhất các hệ thống trực tuyến và phân tích ngoại tuyến trên một trừu tượng log duy nhất. Câu chuyện nguồn gốc đó đã hình thành các mục tiêu thiết kế của Kafka: thông lượng cao, độ trễ thấp và ghi/đọc tuần tự rẻ cho nhiều consumer. LinkedIn đã công bố nhiều bài học rút ra từ việc mở rộng Kafka nội bộ.
Netflix
Netflix sử dụng Kafka rất nhiều như xương sống cho sự kiện, nhắn tin và xử lý luồng trên các lĩnh vực studio và sản phẩm - cung cấp cá nhân hóa thời gian thực, truyền phát sự kiện và telemetry hoạt động. Netflix vận hành Kafka như một nền tảng (tự phục vụ) hỗ trợ nhiều khối lượng công việc và tích hợp với các hệ thống xử lý luồng và lưu trữ của họ. Các bài viết về độ bao phủ của Confluent và kỹ thuật Netflix thảo luận về vị trí của Kafka trong kiến trúc của họ.
Uber
Uber coi Kafka là một viên gạch cơ bản trong kiến trúc dữ liệu và microservice của mình, được sử dụng cho pub/sub giữa hàng trăm microservices, cho các pipelines thời gian thực, và cho các chiến lược lưu trữ theo tầng để quản lý hàng petabyte sự kiện. Kỹ thuật Uber đã viết rất nhiều về việc bảo mật, kiểm toán và vận hành Kafka ở quy mô lớn (sao chép đa vùng, proxy consumer, công cụ kiểm toán).
Thực hành tốt
- Luôn đảm bảo rằng dữ liệu được tối ưu để giảm thiểu độ trễ.
- Sử dụng các nhóm consumer để tăng cường khả năng mở rộng.
- Theo dõi và phân tích hiệu suất của các topic và partition để tối ưu hóa việc lưu trữ.
Những cạm bẫy thường gặp
- Không cấu hình retention time đúng cách có thể dẫn đến mất dữ liệu.
- Không sử dụng partitioning hiệu quả có thể làm giảm hiệu suất.
Mẹo hiệu suất
- Sử dụng các phân vùng để tăng cường khả năng đọc và ghi.
- Tối ưu hóa cấu hình broker để đạt được hiệu suất tốt nhất.
Giải quyết sự cố
- Kiểm tra logs để phát hiện sự cố kết nối.
- Sử dụng công cụ giám sát để theo dõi tình trạng của Kafka.
FAQ
1. Kafka có thể xử lý bao nhiêu sự kiện mỗi giây?
Kafka có thể xử lý hàng triệu sự kiện mỗi giây tùy thuộc vào cấu hình và kiến trúc của hệ thống.
2. Kafka có thể tích hợp với các công nghệ nào?
Kafka có thể tích hợp với nhiều công nghệ như Hadoop, Spark, và các công cụ ETL khác.
Kết luận
Apache Kafka là một giải pháp mạnh mẽ cho việc quản lý và xử lý luồng dữ liệu trong thời gian thực. Bằng cách hiểu rõ các khái niệm cốt lõi và cách ứng dụng chúng trong thực tế, bạn có thể tối ưu hóa hiệu suất và khả năng mở rộng hệ thống của mình. Hãy khám phá thêm về Kafka và áp dụng vào dự án của bạn ngay hôm nay!
