Tìm hiểu Apache Kafka là gì, cách hoạt động của topics và partitions, và vị trí của Kafka trong hệ thống hiện đại cho sự kiện thời gian thực, logs và pipeline dữ liệu.
Apache Kafka là một nền tảng streaming sự kiện phân tán. Nói một cách đơn giản, đó là một “ống” chung, bền bỉ cho phép nhiều hệ thống xuất bản các sự kiện về những gì đã xảy ra và cho phép hệ thống khác đọc những sự kiện đó—nhanh, ở quy mô lớn, và có thứ tự.
Các nhóm dùng Kafka khi dữ liệu cần di chuyển đáng tin cậy giữa các hệ thống mà không tạo sự phụ thuộc chặt. Thay vì một ứng dụng gọi trực tiếp ứng dụng khác (và thất bại khi nó bị down hoặc chậm), các producer ghi sự kiện vào Kafka. Các consumer đọc khi họ sẵn sàng. Kafka lưu sự kiện trong một khoảng thời gian có thể cấu hình, nên các hệ thống có thể phục hồi sau sự cố và thậm chí xử lý lại lịch sử.
Hướng dẫn này dành cho kỹ sư quan tâm sản phẩm, những người làm dữ liệu và lãnh đạo kỹ thuật muốn một mô hình tư duy thực tiễn về Kafka.
Bạn sẽ học các khối xây dựng cốt lõi (producers, consumers, topics, brokers), cách Kafka mở rộng bằng partitions, cách nó lưu trữ và phát lại sự kiện, và nơi nó phù hợp trong kiến trúc hướng sự kiện. Chúng tôi cũng sẽ đề cập các trường hợp sử dụng phổ biến, đảm bảo giao hàng, bảo mật cơ bản, kế hoạch vận hành, và khi nào Kafka phù hợp (hoặc không phù hợp).
Kafka dễ hiểu nhất như một log sự kiện chung: ứng dụng ghi sự kiện vào đó, và ứng dụng khác đọc những sự kiện đó sau—thường là theo thời gian thực, đôi khi là vài giờ hoặc vài ngày sau.
Producers là những thành phần ghi. Một producer có thể xuất bản một sự kiện như “order placed”, “payment confirmed”, hoặc “temperature reading”. Producers không gửi sự kiện trực tiếp tới app cụ thể—họ gửi chúng tới Kafka.
Consumers là những thành phần đọc. Một consumer có thể cung cấp dữ liệu cho dashboard, kích hoạt workflow giao hàng, hoặc nạp dữ liệu vào hệ thống phân tích. Consumers quyết định làm gì với sự kiện, và họ có thể đọc theo tốc độ của riêng mình.
Các sự kiện trong Kafka được nhóm vào topics, cơ bản là các danh mục có tên. Ví dụ:
orders cho các sự kiện liên quan đơn hàngpayments cho sự kiện thanh toáninventory cho thay đổi tồn khoMột topic trở thành “nguồn chân lý” cho dòng sự kiện loại đó, giúp nhiều nhóm tái sử dụng cùng dữ liệu mà không phải xây dựng các tích hợp lẻ tẻ.
Một broker là một máy chủ Kafka lưu trữ sự kiện và phục vụ chúng cho consumer. Trong thực tế, Kafka chạy như một cụm (nhiều broker phối hợp) để xử lý lưu lượng lớn hơn và tiếp tục hoạt động ngay cả khi một máy chủ hỏng.
Consumers thường chạy trong một consumer group. Kafka phân phối công việc đọc qua nhóm, nên bạn có thể thêm nhiều instance consumer để mở rộng xử lý—mà không phải mọi instance đều làm cùng một việc.
Kafka mở rộng bằng cách chia công việc thành topics (dòng các sự kiện liên quan) rồi chia mỗi topic thành partitions (mảnh độc lập nhỏ hơn của dòng đó).
Một topic có một partition chỉ có thể được đọc bởi một consumer trong cùng một consumer group tại một thời điểm. Thêm partition, và bạn có thể thêm nhiều consumer để xử lý sự kiện song song. Đó là cách Kafka hỗ trợ streaming sự kiện với khối lượng lớn và pipeline dữ liệu thời gian thực mà không biến mọi hệ thống thành điểm nghẽn.
Partitions cũng giúp phân tán tải lên các broker. Thay vì một máy chịu tất cả ghi và đọc cho một topic, nhiều broker có thể lưu các partition khác nhau và chia sẻ lưu lượng.
Kafka đảm bảo thứ tự trong một partition duy nhất. Nếu sự kiện A, B và C được ghi vào cùng một partition theo thứ tự đó, consumer sẽ đọc chúng A → B → C.
Thứ tự giữa các partition không được đảm bảo. Nếu bạn cần thứ tự nghiêm ngặt cho một thực thể cụ thể (như một khách hàng hoặc đơn hàng), bạn thường đảm bảo tất cả sự kiện cho thực thể đó vào cùng một partition.
Khi producer gửi một sự kiện, họ có thể kèm một key (ví dụ order_id). Kafka dùng key để định tuyến nhất quán các sự kiện liên quan về cùng một partition. Điều đó cho bạn thứ tự dự đoán được cho key đó trong khi vẫn cho phép topic mở rộng trên nhiều partition.
Mỗi partition có thể được replicate sang các broker khác. Nếu một broker bị hỏng, broker khác có replica có thể tiếp quản. Sao chép là lý do chính khiến Kafka được tin tưởng cho pub-sub messaging và hệ thống hướng sự kiện quan trọng: nó cải thiện tính khả dụng và hỗ trợ chịu lỗi mà không yêu cầu mọi ứng dụng phải tự xây dựng logic failover.
Một ý tưởng then chốt của Apache Kafka là các sự kiện không chỉ được truyền đi rồi quên. Chúng được ghi vào đĩa theo một log có thứ tự, nên consumer có thể đọc bây giờ—hoặc sau này. Điều này làm Kafka hữu ích không chỉ để di chuyển dữ liệu, mà còn để giữ một lịch sử bền vững về những gì đã xảy ra.
Khi producer gửi một sự kiện tới một topic, Kafka nối nó vào lưu trữ trên broker. Consumers sau đó đọc từ log đã lưu đó theo tốc độ của họ. Nếu một consumer offline một giờ, các sự kiện vẫn tồn tại và có thể bắt kịp khi nó phục hồi.
Kafka giữ sự kiện theo chính sách retention:
Retention được cấu hình theo topic, cho phép bạn xử lý khác nhau giữa các topic “audit trail” và topic telemetry có lưu lượng cao.
Một số topic giống như changelog hơn là kho lịch sử—ví dụ “cài đặt khách hàng hiện tại.” Log compaction giữ ít nhất bản ghi mới nhất cho mỗi key, trong khi các bản ghi cũ hơn có thể bị loại bỏ. Bạn vẫn có một nguồn chân lý bền vững cho trạng thái mới nhất, mà không làm tăng trưởng không giới hạn.
Vì sự kiện được lưu, bạn có thể phát lại chúng để tái tạo trạng thái:
Trong thực tế, phát lại được điều khiển bằng nơi consumer “bắt đầu đọc” (offset), mang lại một lớp bảo vệ mạnh mẽ khi hệ thống phát triển.
Kafka được thiết kế để giữ dữ liệu chảy ngay cả khi một phần hệ thống gặp lỗi. Nó làm điều này bằng replication, các quy tắc rõ ràng về ai là “trưởng” của mỗi partition, và acknowledgments có thể cấu hình.
Mỗi partition có một broker leader và một hoặc nhiều follower replica trên các broker khác. Producers và consumers nói chuyện với leader cho partition đó.
Followers liên tục sao chép dữ liệu của leader. Nếu leader bị hỏng, Kafka có thể thăng một follower đã bắt kịp lên làm leader mới, giúp partition tiếp tục khả dụng.
Nếu một broker chết, các partition mà nó đang làm leader sẽ tạm thời không khả dụng. Controller của Kafka (điều phối nội bộ) phát hiện lỗi và kích hoạt leader election cho các partition đó.
Nếu ít nhất một replica follower đủ bắt kịp, nó có thể tiếp quản làm leader và client tiếp tục produce/consume. Nếu không có replica nào đồng bộ, Kafka có thể tạm dừng ghi (tùy cấu hình) để tránh mất dữ liệu đã được xác nhận.
Hai nút điều chỉnh chính ảnh hưởng durability:
Ở mức khái niệm:
Để giảm trùng lặp khi retry, các nhóm thường kết hợp acks an toàn với producers idempotent và xử lý consumer chặt chẽ (được đề cập sau).
An toàn cao hơn thường nghĩa là chờ nhiều xác nhận hơn và giữ nhiều replica đồng bộ, điều này có thể làm tăng độ trễ và giảm throughput đỉnh.
Cấu hình độ trễ thấp có thể phù hợp cho telemetry hoặc clickstream nơi mất mát thỉnh thoảng chấp nhận được, nhưng thanh toán, tồn kho và audit logs thường đáng để đánh đổi cho an toàn cao hơn.
Kiến trúc hướng sự kiện (EDA) là cách xây dựng hệ thống nơi các sự kiện doanh nghiệp—một đơn hàng được đặt, thanh toán được xác nhận, một gói được gửi—được biểu diễn như sự kiện mà các phần khác của hệ thống có thể phản ứng.
Kafka thường nằm ở trung tâm của EDA như “luồng sự kiện chung.” Thay vì Service A gọi Service B trực tiếp, Service A xuất bản một sự kiện (ví dụ OrderCreated) lên topic Kafka. Bất kỳ số lượng dịch vụ nào cũng có thể tiêu thụ sự kiện đó và hành động—gửi email, đặt giữ tồn kho, khởi chạy kiểm tra gian lận—mà không cần Service A biết tới họ tồn tại.
Vì các dịch vụ giao tiếp qua sự kiện, họ không phải phối hợp API request/response cho mọi tương tác. Điều này giảm sự phụ thuộc chặt giữa các nhóm và làm cho việc thêm tính năng mới dễ dàng hơn: bạn có thể thêm một consumer mới cho một sự kiện có sẵn mà không thay đổi producer.
EDA bản chất là bất đồng bộ: producers ghi sự kiện nhanh, và consumers xử lý chúng theo tốc độ của họ. Trong lúc tải đột biến, Kafka giúp đệm luồng để hệ thống hạ nguồn không bị quá tải ngay lập tức. Consumers có thể mở rộng để bắt kịp, và nếu một consumer tạm thời chết, nó có thể tiếp tục từ nơi đã dừng.
Hãy nghĩ về Kafka như “luồng hoạt động” của hệ thống. Producers xuất bản các thực tế; consumers đăng ký nhận các thực tế họ quan tâm. Mẫu này cho phép pipeline dữ liệu thời gian thực và workflow hướng sự kiện trong khi giữ các dịch vụ đơn giản và độc lập hơn.
Kafka xuất hiện khi các nhóm cần di chuyển nhiều “sự kiện nhỏ đã xảy ra” giữa các hệ thống—nhanh, đáng tin cậy và sao cho nhiều consumer có thể tái sử dụng.
Ứng dụng thường cần một lịch sử append-only: đăng nhập người dùng, thay đổi quyền, cập nhật bản ghi, hoặc hành động admin. Kafka hoạt động tốt như một luồng trung tâm của các sự kiện này, để công cụ bảo mật, báo cáo và xuất dữ liệu tuân thủ có thể đọc cùng nguồn mà không tăng tải lên cơ sở dữ liệu sản xuất. Bởi vì sự kiện được giữ theo thời gian, bạn cũng có thể phát lại để xây dựng lại view audit sau lỗi hoặc thay đổi schema.
Thay vì các service gọi nhau trực tiếp, họ có thể xuất bản sự kiện như “order created” hoặc “payment received.” Các service khác đăng ký và phản ứng theo thời gian của riêng họ. Điều này giảm coupling chặt, giúp hệ thống hoạt động trong tình trạng lỗi từng phần, và làm cho việc thêm tính năng mới (ví dụ kiểm tra gian lận) đơn giản bằng cách tiêu thụ luồng sự kiện hiện có.
Kafka thường là xương sống để di chuyển dữ liệu từ hệ thống vận hành vào nền tảng analytics. Các nhóm có thể stream thay đổi từ cơ sở dữ liệu ứng dụng và chuyển tới warehouse hoặc data lake với độ trễ thấp, trong khi giữ ứng dụng sản xuất tách biệt khỏi các truy vấn phân tích nặng.
Cảm biến, thiết bị và telemetry ứng dụng thường tới theo từng cơn. Kafka có thể hấp thụ đột biến, đệm an toàn và cho phép xử lý phía sau bắt kịp—hữu ích cho giám sát, cảnh báo và phân tích dài hạn.
Kafka không chỉ là brokers và topics. Hầu hết các nhóm phụ thuộc vào công cụ bổ trợ giúp Kafka thực tế cho việc di chuyển dữ liệu hàng ngày, xử lý stream và vận hành.
Kafka Connect là framework tích hợp của Kafka để đưa dữ liệu vào Kafka (sources) và ra khỏi Kafka (sinks). Thay vì xây dựng và vận hành các pipeline tùy biến, bạn chạy Connect và cấu hình connector.
Ví dụ phổ biến: kéo thay đổi từ cơ sở dữ liệu, ingest sự kiện SaaS, hoặc đẩy dữ liệu Kafka vào data warehouse hoặc object storage. Connect cũng chuẩn hóa các vấn đề vận hành như retry, offset và phân luồng.
Nếu Connect là cho tích hợp, Kafka Streams là cho tính toán. Đó là một thư viện bạn thêm vào ứng dụng để biến đổi luồng theo thời gian thực—lọc sự kiện, enrich, join luồng, và xây dựng các aggregate (như “orders per minute”).
Vì Streams apps đọc từ topic và ghi lại vào topic, chúng phù hợp tự nhiên trong hệ thống hướng sự kiện và có thể mở rộng bằng cách thêm instance.
Khi nhiều nhóm xuất bản sự kiện, tính nhất quán quan trọng. Quản lý schema (thường qua schema registry) định nghĩa các trường sự kiện và cách chúng tiến hóa theo thời gian. Điều này giúp tránh các lỗi như producer đổi tên trường mà consumer đang phụ thuộc.
Kafka nhạy cảm về vận hành, nên giám sát cơ bản là cần thiết:
Hầu hết các nhóm cũng dùng UI quản lý và tự động hóa cho deployment, cấu hình topic và chính sách truy cập (xem /blog/kafka-security-governance).
Kafka thường được mô tả là “log bền + consumers”, nhưng điều các nhóm thực sự quan tâm là: tôi sẽ xử lý mỗi sự kiện một lần không, và chuyện gì xảy ra khi có lỗi? Kafka cung cấp các khối xây dựng, và bạn chọn thỏa hiệp.
At-most-once nghĩa là bạn có thể mất sự kiện, nhưng không xử lý trùng lặp. Điều này xảy ra nếu consumer commit vị trí trước rồi crash trước khi hoàn tất công việc.
At-least-once nghĩa là bạn sẽ không mất sự kiện, nhưng có thể có trùng lặp (ví dụ consumer xử lý xong một sự kiện, crash, rồi xử lý lại sau khi khởi động). Đây là mặc định phổ biến nhất.
Exactly-once nhằm tránh cả mất mát và trùng lặp end-to-end. Trong Kafka, điều này thường liên quan tới producer giao dịch (transactional producers) và xử lý tương thích (thường qua Kafka Streams). Nó mạnh mẽ nhưng bị ràng buộc hơn và yêu cầu thiết lập cẩn thận.
Trong thực tế, nhiều hệ thống chấp nhận at-least-once và thêm biện pháp an toàn:
Offset là vị trí của bản ghi đã xử lý cuối cùng trong một partition. Khi bạn commit offset, bạn nói “Tôi đã xong tới đây.” Commit quá sớm thì rủi ro mất; commit quá muộn thì tăng khả năng trùng lặp sau lỗi.
Retry nên có giới hạn và hiển thị. Một mẫu phổ biến:
Cách này giữ cho một “poison message” không làm tắc toàn bộ consumer group trong khi vẫn bảo toàn dữ liệu để sửa sau.
Kafka thường mang các sự kiện quan trọng của doanh nghiệp (đơn hàng, thanh toán, hoạt động người dùng). Điều này làm cho bảo mật và quản trị là một phần thiết kế, không phải việc làm sau.
Xác thực trả lời “bạn là ai?” Phân quyền trả lời “bạn được phép làm gì?” Trong Kafka, xác thực thường dùng SASL (ví dụ SCRAM hoặc Kerberos), trong khi phân quyền được áp dụng bằng ACL ở mức topic, consumer group và cluster.
Một mẫu thực tế là least privilege: producers chỉ được ghi vào các topic họ sở hữu, và consumers chỉ được đọc các topic họ cần. Điều này giảm lộ dữ liệu tình cờ và giới hạn phạm vi hư hại nếu credential bị lộ.
TLS mã hóa dữ liệu khi di chuyển giữa app, broker và công cụ. Nếu không có TLS, sự kiện có thể bị chặn trên mạng nội bộ, không chỉ internet công cộng. TLS cũng giúp ngăn tấn công “man-in-the-middle” bằng cách xác thực danh tính broker.
Khi nhiều nhóm chia sẻ một cụm, cần có guardrails. Quy ước đặt tên topic rõ ràng (ví dụ <team>.<domain>.<event>.<version>) làm rõ quyền sở hữu và giúp công cụ áp dụng chính sách nhất quán.
Kết hợp quy ước tên với quota và mẫu ACL để một workload ồn ào không làm nghẽn những workload khác, và để dịch vụ mới bắt đầu với cấu hình an toàn.
Xử lý Kafka như một hệ thống lưu trữ lịch sử sự kiện chỉ khi bạn có ý định. Nếu sự kiện chứa PII, dùng giảm thiểu dữ liệu (gửi ID thay vì profile đầy đủ), cân nhắc mã hóa trường, và ghi rõ topic nào nhạy cảm.
Cài đặt retention nên khớp với yêu cầu pháp lý và doanh nghiệp. Nếu chính sách yêu cầu “xóa sau 30 ngày”, đừng giữ 6 tháng “phòng trường hợp”. Đánh giá và kiểm tra định kỳ giúp cấu hình phù hợp khi hệ thống thay đổi.
Chạy Apache Kafka không chỉ là “cài và quên”. Nó hoạt động như một tiện ích chia sẻ: nhiều nhóm phụ thuộc vào nó, và sai sót nhỏ có thể lan sang các ứng dụng hạ nguồn.
Năng lực Kafka phần lớn là bài toán tính toán bạn cần xem lại định kỳ. Các con đòn lớn nhất là partitions (song song), throughput (MB/s vào và ra), và tăng trưởng lưu trữ (bao lâu bạn giữ dữ liệu).
Nếu lưu lượng tăng gấp đôi, bạn có thể cần thêm partition để phân tán tải trên các broker, thêm đĩa để chứa retention, và băng thông mạng lớn hơn cho replication. Thói quen thực tế là dự báo tốc độ ghi đỉnh và nhân với retention để ước tính tăng trưởng đĩa, sau đó cộng đệm cho replication và “thành công bất ngờ”.
Mong đợi công việc định kỳ ngoài việc giữ server sống:
Chi phí bị chi phối bởi đĩa, băng thông mạng, và số lượng/kích thước broker. Managed Kafka có thể giảm gánh nặng nhân sự và đơn giản hóa nâng cấp, trong khi tự quản lý có thể rẻ hơn ở quy mô nếu bạn có đội vận hành giàu kinh nghiệm. Sự đánh đổi là thời gian phục hồi và gánh nặng on-call.
Các nhóm thường giám sát:
Dashboard và cảnh báo tốt biến Kafka từ “hộp bí ẩn” thành dịch vụ có thể hiểu được.
Kafka phù hợp khi bạn cần di chuyển nhiều sự kiện một cách đáng tin cậy, giữ chúng trong một thời gian, và cho phép nhiều hệ thống phản ứng cùng dữ liệu theo tốc độ riêng. Nó đặc biệt hữu ích khi dữ liệu cần phát lại (cho backfill, audit, hoặc tái tạo dịch vụ) và khi bạn dự kiến thêm nhiều producer/consumer theo thời gian.
Kafka thường phù hợp khi bạn có:
Kafka có thể quá thừa nếu nhu cầu của bạn đơn giản:
Trong các trường hợp này, chi phí vận hành (định cỡ cluster, nâng cấp, giám sát, trực) có thể lớn hơn lợi ích.
Kafka cũng bổ trợ—không thay thế—cơ sở dữ liệu (hệ thống ghi chính), cache (đọc nhanh), và công cụ ETL theo lô (chuyển đổi định kỳ lớn).
Hỏi:
Nếu bạn trả lời “có” cho đa số, Kafka thường là lựa chọn hợp lý.
Kafka phù hợp nhất khi bạn cần một “nguồn chân lý” chia sẻ cho các luồng sự kiện thời gian thực: nhiều hệ thống tạo facts (order created, payment authorized, inventory changed) và nhiều hệ thống tiêu thụ các facts đó để cung cấp pipeline, analytics và tính năng phản ứng.
Bắt đầu với một luồng hẹp, có giá trị cao—như xuất bản sự kiện “OrderPlaced” cho các dịch vụ hạ nguồn (email, fraud checks, fulfillment). Tránh biến Kafka thành hàng đợi tổng hợp trong ngày đầu.
Ghi ra:
Giữ schema ban đầu đơn giản và nhất quán (timestamps, IDs, tên sự kiện rõ ràng). Quyết định bạn sẽ bắt buộc schema ngay từ đầu hay tiến hóa cẩn trọng theo thời gian.
Kafka thành công khi có người sở hữu:
Thêm giám sát ngay từ đầu (consumer lag, sức khỏe broker, throughput, tỉ lệ lỗi). Nếu bạn chưa có team platform, bắt đầu với managed offering và giới hạn rõ ràng.
Produce sự kiện từ một hệ thống, tiêu thụ chúng ở một nơi, và chứng minh vòng lặp end-to-end hoạt động. Sau đó mới mở rộng tới nhiều consumer, partition và tích hợp.
Nếu bạn muốn đi nhanh từ “ý tưởng” tới dịch vụ hướng sự kiện hoạt động, các công cụ như Koder.ai có thể giúp bạn prototype phần ứng dụng xung quanh nhanh chóng (giao diện React, backend Go, PostgreSQL) và thêm producers/consumers Kafka theo workflow hướng chat. Nó hữu ích cho việc xây dựng dashboard nội bộ và dịch vụ nhẹ tiêu thụ topic, với các tính năng như planning mode, xuất mã nguồn, triển khai/hosting, và snapshot với rollback.
Nếu bạn đang chuyển sang kiến trúc hướng sự kiện, xem /blog/event-driven-architecture. Để lập kế hoạch chi phí và môi trường, xem /pricing.
Kafka là một nền tảng streaming sự kiện phân tán lưu giữ các sự kiện dưới dạng các log nối tiếp bền vững.
Các producer ghi sự kiện vào các topic, và các consumer đọc độc lập (thường theo thời gian thực, nhưng cũng có thể đọc sau đó) vì Kafka lưu trữ dữ liệu trong khoảng thời gian cấu hình được.
Dùng Kafka khi nhiều hệ thống cần cùng một luồng sự kiện, bạn muốn giảm sự phụ thuộc chặt chẽ giữa các dịch vụ, và bạn có thể cần phát lại lịch sử.
Nó đặc biệt hữu ích cho:
Một topic là một danh mục sự kiện có tên (ví dụ orders hoặc payments).
Một partition là một phần cắt của topic cho phép:
Kafka chỉ đảm bảo thứ tự trong một partition duy nhất.
Kafka sử dụng key của bản ghi (ví dụ order_id) để định tuyến nhất quán các sự kiện liên quan về cùng một partition.
Quy tắc thực tế: nếu bạn cần thứ tự theo từng thực thể (tất cả sự kiện của một order/khách hàng theo trình tự), chọn key đại diện cho thực thể đó để các sự kiện rơi vào cùng một partition.
Consumer group là một tập hợp các instance consumer cùng chia sẻ công việc cho một topic.
Trong một group:
Nếu bạn cần hai ứng dụng khác nhau mỗi cái nhận mọi sự kiện, chúng nên dùng các consumer group khác nhau.
Kafka giữ sự kiện trên đĩa theo chính sách của từng topic, để consumer có thể bắt kịp sau khi offline hoặc xử lý lại lịch sử.
Các kiểu retention phổ biến:
Retention được cấu hình theo topic, nên các luồng audit quan trọng có thể được giữ lâu hơn so với telemetry có lưu lượng lớn.
Log compaction giữ lại ít nhất bản ghi mới nhất cho mỗi key, và loại bỏ các bản ghi cũ đã bị thay thế theo thời gian.
Nó hữu ích cho các luồng “trạng thái hiện tại” (như settings hoặc profile) khi bạn quan tâm tới giá trị mới nhất cho mỗi key hơn là mọi thay đổi lịch sử—nhưng vẫn muốn một nguồn chân lý bền vững cho trạng thái hiện tại.
Mẫu phổ biến nhất là at-least-once: bạn sẽ không mất sự kiện, nhưng có thể xử lý trùng lặp.
Để xử lý an toàn:
Offset là “dấu trang” của consumer cho mỗi partition.
Nếu bạn commit offset quá sớm, khi crash có thể mất công việc; commit quá muộn sẽ khiến bạn xử lý lại và tạo trùng lặp.
Mẫu vận hành phổ biến: retry có giới hạn với backoff, sau đó gửi record bị lỗi đến một dead-letter topic để một message xấu không làm tắc toàn bộ consumer group.
Kafka Connect di chuyển dữ liệu vào/ra Kafka bằng các connector (sources và sinks) thay vì viết pipeline tùy chỉnh.
Kafka Streams là một thư viện để biến đổi và tổng hợp luồng theo thời gian thực bên trong ứng dụng của bạn (lọc, join, enrich, aggregate), đọc từ topic và viết lại kết quả vào topic.
Connect thường dùng cho tích hợp; Streams dùng cho xử lý.