7.7K 39 114

Đã đăng vào khoảng 10 giờ trước 20 phút đọc

📨🧠 Kafka Có Mất Dữ Liệu Không? – Sự Thật Ít Ai Biết - Kafka 101 P5

Kafka Có Mất Dữ Liệu Không? – Sự Thật Ít Ai Biết

Trong thế giới thiết kế hệ thống phân tán, Apache Kafka thường được ca ngợi như một "chén thánh" về khả năng chịu lỗi (fault-tolerance) và độ tin cậy dữ liệu (data reliability). Nhiều kỹ sư mặc định tin rằng: một khi đã đưa dữ liệu vào Kafka, tin nhắn (message) đó sẽ vĩnh viễn an toàn. Các tài liệu quảng cáo và slide thuyết trình luôn vẽ ra viễn cảnh dữ liệu được nhân bản qua nhiều máy chủ (broker), sẵn sàng sống sót qua những sự cố hạ tầng tồi tệ nhất.

Nhưng thực tế ở môi trường production khốc lệ lại kể một câu chuyện rất khác.

Một ngày đẹp trời, hệ thống tài chính của bạn phát hiện ra một số giao dịch bị "bốc hơi" không dấu vết. Không có log lỗi ở phía Producer, không có cảnh báo đỏ từ Kafka Cluster, và Consumer vẫn hoạt động bình thường. Dữ liệu đơn giản là đã biến mất trong quá trình trung chuyển.

Kafka có thực sự không bao giờ mất dữ liệu? Câu trả lời ngắn gọn là: Không. Kafka cực kỳ bền vững, nhưng sự bền vững đó không tự nhiên mà có. Nó là kết quả của những quyết định đánh đổi (trade-offs) và thiết lập cấu hình chính xác từ người kỹ sư. Nếu bạn chỉ cài đặt Kafka với cấu hình mặc định (out-of-the-box), hệ thống của bạn đang đứng trước nguy cơ mất dữ liệu cực kỳ cao.

Bài viết này sẽ vạch trần cơ chế lưu trữ của Kafka dưới lăng kính của một kỹ sư hệ thống, chỉ ra 3 điểm xung yếu có thể làm rò rỉ dữ liệu và cách thiết lập một phòng tuyến chống mất dữ liệu toàn diện.

Câu chuyện từ Production: Đơn hàng biến mất bí ẩn

Tại một doanh nghiệp thương mại điện tử quy mô lớn, hệ thống thanh toán và xử lý đơn hàng được kết nối với nhau thông qua Kafka. Luồng đi rất cơ bản: Khi khách hàng thanh toán thành công, Payment Service (Producer) sẽ đẩy một event vào topic order-paid. Phía bên kia, Order Processing Service (Consumer) sẽ đọc event này để cập nhật trạng thái đơn hàng và kích hoạt quy trình đóng gói.

+-----------------+      send      +-----------------+      poll      +--------------------------+
| Payment Service | -------------> |  Kafka Broker   | -------------> | Order Processing Service |
|   (Producer)    |                | (Topic: o-paid) |                |        (Consumer)        |
+-----------------+                +-----------------+                +--------------------------+
                                                                                  | (Crash!)
                                                                                  v
                                                                        [Database: Chưa update]

Mọi thứ chạy mượt mà cho đến ngày sự kiện khuyến mãi lớn diễn ra. Lượng tải tăng vọt, một vài container của Order Processing Service bị quá tải và crash đột ngột do thiếu bộ nhớ (Out of Memory - OOM). Khi Kubernetes tự động khởi chạy lại các container này, hệ thống hoạt động trở lại bình thường.

Tuy nhiên, cuối ngày, đội ngũ đối soát tài chính phát hiện hàng trăm đơn hàng đã được khách thanh toán thành công nhưng không bao giờ được xử lý trên hệ thống kho. Kiểm tra database, các đơn hàng này vẫn ở trạng thái "Chờ thanh toán". Đáng sợ hơn, Kafka không hề báo lỗi, và khi kiểm tra offset của consumer group, tất cả các message tương ứng đều đã được đánh dấu là "đã xử lý" (committed).

Chuyện gì đã xảy ra? Dữ liệu đã đi đâu khi cả hai đầu hệ thống đều báo không có lỗi nghiêm trọng?

Niềm tin ngây thơ và Thực tế khốc liệt

Sai lầm lớn nhất của các kỹ sư khi mới tiếp cận Kafka là tin vào hai điều sau:

Gửi thành công là an toàn: Chỉ cần hàm producer.send() không ném ra ngoại lệ (exception) hoặc trả về metadata thành công, dữ liệu đã được ghi xuống ổ đĩa cứng của Kafka Broker.
Kafka tự động sao lưu 100%: Khi cấu hình replication.factor = 3, dữ liệu tự động được nhân bản sang 3 máy chủ khác nhau ngay lập tức, do đó một broker chết không làm mất dữ liệu.

Thực tế, cả hai niềm tin trên đều sai lệch so với cách Kafka vận hành trong thực tế.

Đầu tiên, cuộc gọi producer.send() mặc định là bất đồng bộ (asynchronous). Message gửi đi không được truyền trực tiếp đến mạng mà được gom vào một bộ đệm cục bộ (Record Accumulator) trong bộ nhớ RAM của client trước khi gửi đi theo từng lô (batch). Nếu ứng dụng của bạn crash trước khi đệm này được gửi đi, dữ liệu sẽ biến mất ngay tại RAM của Producer.

Thứ hai, ngay cả khi message đã đến được broker, hệ điều hành Linux (nơi Kafka chạy) không ghi trực tiếp dữ liệu xuống ổ đĩa cứng ngay lập tức vì hiệu năng ghi đĩa rất chậm. Thay vào đó, dữ liệu được ghi vào Page Cache (bộ nhớ đệm RAM của hệ điều hành). Kafka thực hiện cơ chế ghi đĩa bất đồng bộ (asynchronous flush). Nếu broker bị sập nguồn đột ngột trước khi Page Cache được đồng bộ (flush) xuống đĩa cứng, dữ liệu đó sẽ biến mất mãi mãi.

Giải mã 3 điểm xung yếu gây mất dữ liệu trong Kafka

Để hiểu tại sao dữ liệu bị mất, chúng phải phân tích toàn bộ vòng đời của một message qua 3 thực thể: Producer, Broker (Cluster), và Consumer.

    [ PRODUCER ]              [ BROKER CLUSTER ]               [ CONSUMER ]
+-------------------+       +--------------------+       +---------------------+
| RecordAccumulator | ----> | Page Cache (RAM)   | ----> | Auto Commit Offset  |
| (Mất nếu JVM chết)|       | (Mất nếu sập nguồn)|       | (Mất nếu crash sớm) |
+-------------------+       +--------------------+       +---------------------+

1. Điểm xung yếu số 1: Phía Producer và tham số `acks`

Khi Producer gửi message đến Broker Leader của một partition, nó cần nhận được xác nhận (acknowledgment - ack) để biết rằng message đã được tiếp nhận an toàn. Cách Producer nhận ack được quyết định bởi cấu hình acks:

acks=0: Producer gửi message đi và coi như đã thành công ngay lập tức. Nó không quan tâm broker có nhận được hay không, có bị sập mạng hay không. Đây là chế độ nhanh nhất nhưng cực kỳ kém an toàn.
acks=1 (Mặc định trong nhiều phiên bản cũ): Producer sẽ đợi Broker Leader xác nhận đã ghi message vào Page Cache của nó. Tuy nhiên, Leader chưa đợi các Broker Follower sao chép dữ liệu này. Nếu Leader xác nhận thành công với Producer, rồi sụp đổ ngay lập tức trước khi kịp nhân bản sang các Follower, dữ liệu đó sẽ biến mất khi một Follower khác được bầu làm Leader mới.
acks=all (hoặc acks=-1): Producer chỉ coi là thành công khi Broker Leader và tất cả các bản sao đang đồng bộ (In-Sync Replicas - ISR) xác nhận đã nhận được dữ liệu. Đây là cấu hình an toàn nhất.

2. Điểm xung yếu số 2: Phía Broker và cơ chế ghi đĩa

Như đã đề cập, Kafka tận dụng Page Cache của hệ điều hành để đạt thông lượng (throughput) cực cao. Nếu cấu hình Kafka để ghi đĩa bắt buộc sau mỗi message (synchronous flush), hiệu năng của Kafka sẽ tụt giảm nghiêm trọng, không khác gì một cơ sở dữ liệu quan hệ truyền thống gặp nghẽn cổ chai I/O.

Do đó, mặc định Kafka dựa vào cơ chế nhân bản (replication) để bảo vệ dữ liệu thay vì ép buộc ghi đĩa liên tục. Nghĩa là, Kafka tin rằng: "Dù dữ liệu trên máy A chỉ nằm ở RAM, nhưng nó đã được copy sang RAM của máy B và máy C. Xác suất cả 3 máy cùng sập nguồn một lúc là cực kỳ thấp".

Tuy nhiên, niềm tin này sẽ đổ vỡ nếu:

Cấu hình số lượng bản sao quá ít (replication.factor = 1).
Cho phép bầu chọn leader không an toàn (unclean.leader.election.enable = true). Khi Leader chết và không có Follower nào trong danh sách ISR còn sống, Kafka sẽ cho phép một Follower không đồng bộ (nằm ngoài ISR, dữ liệu bị cũ) lên làm Leader. Kết quả là toàn bộ phần dữ liệu mới mà Leader cũ đã nhận nhưng chưa kịp nhân bản sẽ bị ghi đè và mất vĩnh viễn.

3. Điểm xung yếu số 3: Phía Consumer và chiếc bẫy "Auto Commit"

Đây chính là nguyên nhân trực tiếp gây ra sự cố mất đơn hàng trong câu chuyện production kể trên.

Mặc định, các thư viện client của Kafka thiết lập enable.auto.commit = true. Điều này có nghĩa là định kỳ (ví dụ mỗi 5 giây - cấu hình bởi auto.commit.interval.ms), Consumer sẽ tự động gửi offset lớn nhất mà nó vừa đọc được lên Kafka để đánh dấu là đã xử lý xong.

Hãy tưởng tượng kịch bản sau:

Consumer thực hiện cuộc gọi poll() và lấy về một batch gồm 100 đơn hàng.
Ngay sau khi lấy dữ liệu về bộ nhớ RAM của Consumer, cơ chế auto-commit chạy ngầm và commit offset của đơn hàng thứ 100 lên Kafka.
Ứng dụng Consumer bắt đầu xử lý tuần tự các đơn hàng này. Đến đơn hàng thứ 10, ứng dụng gặp lỗi Memory Leak và crash hoàn toàn.
Kubernetes khởi động lại Consumer mới. Khi Consumer này kết nối vào Kafka, nó hỏi: "Tôi nên đọc từ đâu?". Kafka trả lời: "Offset mới nhất đã được commit là 100".
Consumer mới tiếp tục đọc từ đơn hàng thứ 101. Từ đơn hàng thứ 11 đến 100 hoàn toàn bị bỏ qua và biến mất khỏi hệ thống xử lý.

Tư duy kỹ sư: Thiết lập hệ thống "Không thể mất dữ liệu"

Đạt được độ bền vững dữ liệu tuyệt đối (Zero Data Loss) đòi hỏi chúng ta phải cấu hình đồng bộ ở cả 3 tầng. Không có một cấu hình đơn lẻ nào có thể tự giải quyết vấn đề. Dưới đây là chiến lược thiết lập phòng tuyến an toàn cho các ứng dụng nhạy cảm (như giao dịch tài chính, thanh toán):

                       [ BỘ BA CẤU HÌNH AN TOÀN ]
  PRODUCER                   KAFKA BROKER                  CONSUMER
+----------+              +----------------------+      +----------------------+
| acks=all | -----------> | replication.factor=3 | ---> | enable.auto.commit=  |
|          |              | min.insync.replicas=2|      | false                |
+----------+              +----------------------+      +----------------------+

Bước 1: Ràng buộc phía Producer

Bạn phải buộc Producer chờ đợi sự xác nhận từ toàn bộ hệ thống phân tán thay vì chỉ tin tưởng một broker duy nhất.

Cấu hình acks = all: Đây là điều kiện tiên quyết.
Cấu hình retries = Integer.MAX_VALUE: Cho phép Producer tự động gửi lại tin nhắn vô hạn lần nếu gặp lỗi mạng tạm thời hoặc đang trong quá trình bầu lại Leader mới.
Cấu hình max.in.flight.requests.per.connection = 1 (hoặc kích hoạt enable.idempotence = true): Đảm bảo thứ tự của tin nhắn không bị đảo lộn khi xảy ra quá trình gửi lại (retry).

Bước 2: Thắt chặt phòng thủ phía Broker

Broker phải được cấu hình để không bao giờ chấp nhận các thỏa hiệp làm giảm tính toàn vẹn dữ liệu.

replication.factor = 3: Đảm bảo mỗi partition luôn có 1 bản chính (Leader) và 2 bản sao (Follower) nằm trên các máy vật lý (hoặc Availability Zone) khác nhau.
min.insync.replicas = 2: Tham số này hoạt động kết hợp với acks=all. Nó chỉ ra rằng: Để một lượt ghi được coi là thành công, phải có ít nhất 2 replica (bao gồm cả Leader) xác nhận đã nhận được dữ liệu. Nếu một broker bị chết và chỉ còn lại 1 replica hoạt động, các yêu cầu ghi của Producer gửi lên với acks=all sẽ bị từ chối (ném ra exception NotEnoughReplicasException), bảo vệ hệ thống khỏi trạng thái ghi dữ liệu không an toàn.
unclean.leader.election.enable = false: Chặn đứng việc cho phép các follower bị chậm tiến độ (out-of-sync) lên làm Leader khi sự cố nghiêm trọng xảy ra. Thà hệ thống chấp nhận ngừng dịch vụ ghi (write unavailability) còn hơn là nhận ghi dữ liệu lỗi hoặc làm mất mát lịch sử.

Bước 3: Kiểm soát offset chủ động phía Consumer

Hãy tước bỏ quyền tự quyết của Consumer và chuyển sang cơ chế quản lý thủ công (Manual Commit).

enable.auto.commit = false: Tắt hoàn toàn tính năng tự động commit.
Thực hiện Commit thủ công sau khi xử lý thành công: Chỉ commit offset lên Kafka sau khi dữ liệu đã được lưu trữ an toàn vào database hoặc hệ thống đích.

Dưới đây là một ví dụ mã giả mô tả tư duy xử lý thủ công này:

# Cấu hình consumer thủ công
consumer = KafkaConsumer(
    'order-paid',
    enable_auto_commit=False, # Tắt tự động commit
    group_id='order-processor'
)

while True:
    records = consumer.poll(timeout_ms=1000)
    for record in records:
        try:
            # 1. Thực thi business logic (ví dụ ghi xuống database)
            database.save_order_transaction(record.value)
            
            # 2. Xử lý thành công, commit offset của tin nhắn cụ thể này
            consumer.commit_offsets(record.offset + 1)
        except DatabaseException as e:
            # 3. Lỗi database: Log lỗi, KHÔNG commit offset. 
            # Hệ thống sẽ retry hoặc đẩy sang Dead Letter Queue (DLQ)
            log.error("Lỗi ghi DB, dừng xử lý để tránh mất dữ liệu", e)
            break

Những đánh đổi (Trade-offs) khốn liệt phía sau

Trong thiết kế hệ thống, không có bữa trưa nào miễn phí. Khi bạn kéo thanh gạt an toàn dữ liệu lên mức tối đa, bạn buộc phải chấp nhận những tổn thất ở các khía cạnh khác:

1. Latency (Độ trễ) tăng cao

Với acks=all và min.insync.replicas=2, mỗi tin nhắn gửi từ Producer phải đi qua hành trình: Producer -> Mạng -> Leader RAM -> Mạng -> Follower RAM -> Mạng -> Producer. Độ trễ của một lượt ghi (write round-trip) giờ đây phụ thuộc vào tốc độ mạng của broker chậm nhất trong nhóm ISR. Nếu mạng giữa các broker bị nghẽn, latency ghi của ứng dụng phía trước (frontend/API) sẽ tăng vọt.

2. Throughput (Thông lượng) giảm

Việc chờ đợi phản hồi phân tán và hạn chế số lượng request đồng thời gửi đi (max.in.flight.requests.per.connection=1) làm giảm đáng kể khả năng tận dụng băng thông của Producer.

3. Đánh đổi tính sẵn sàng (Availability)

Bằng việc đặt min.insync.replicas = 2 trên cụm 3 broker, bạn chỉ cho phép tối đa 1 broker chết. Nếu broker thứ 2 chết, hệ thống sẽ từ chối toàn bộ request ghi mới từ Producer mặc dù vẫn còn 1 broker hoạt động bình thường. Đây là sự lựa chọn trực tiếp giữa Consistency (Nhất quán/Độ bền dữ liệu) và Availability (Tính sẵn sàng) theo định lý CAP.

Những kịch bản thất bại cực đoan (Failure Cases)

Ngay cả khi bạn đã áp dụng tất cả các cấu hình tối ưu ở trên, vẫn tồn tại những góc khuất có thể phá vỡ hệ thống:

Sự cố mất điện diện rộng (Correlated Power Failure): Nếu tất cả các máy chủ trong cụm Kafka nằm chung một trung tâm dữ liệu và bị mất điện đột ngột. Toàn bộ dữ liệu nằm trên Page Cache chưa kịp sync xuống đĩa cứng ở cả Leader lẫn Followers đều biến mất. Cách duy nhất để giảm thiểu rủi ro này là phân bổ các Broker sang các vùng khả dụng khác nhau (Multi-AZ) và cấu hình ổ đĩa cứng có hỗ trợ nguồn pin dự phòng (Battery-Backed Write Cache).
Độc độ trễ do commit đồng bộ (Commit Sync Bottleneck): Nếu consumer gọi commitSync() sau mỗi tin nhắn đơn lẻ để đảm bảo tuyệt đối không mất dữ liệu, hiệu năng của consumer có thể giảm đi hàng chục lần do network round-trip liên tục gửi về Kafka. Người thiết kế phải cân nhắc gom nhóm commit (batch commit) hoặc chấp nhận cơ chế xử lý lặp (at-least-once) kết hợp với thiết kế Idempotence (nhận diện trùng lặp) ở database đích.

Lời kết & Góc nhìn từ kỹ sư hệ thống

Độ tin cậy của Kafka không phải là một thuộc tính tĩnh có sẵn ngay khi cài đặt. Nó là một sự thỏa hiệp liên tục giữa độ bền vững dữ liệu (durability), hiệu năng hệ thống (throughput/latency) và tính sẵn sàng (availability).

Một kỹ sư giỏi không phải là người luôn luôn đặt cấu hình an toàn nhất trong mọi trường hợp, mà là người hiểu rõ giá trị của từng byte dữ liệu mà hệ thống xử lý để đưa ra quyết định kiến trúc phù hợp:

Đối với dữ liệu clickstream, log phân tích hành vi người dùng: Chọn hiệu năng cao (acks=1, enable.auto.commit=true). Mất một vài event không làm ảnh hưởng tới kết quả thống kê chung.
Đối với dữ liệu thanh toán, biến động số dư, đơn hàng: Bắt buộc phải chọn an toàn tối đa (acks=all, min.insync.replicas=2, manual offset commit).

Để đảm bảo các cấu hình như acks=all hoạt động ổn định và có các bản sao (replicas) đáng tin cậy để bám đuổi dữ liệu, Kafka cần có một cụm máy chủ hoạt động và phối hợp nhịp nhàng dưới sự điều phối của các thành phần quản lý phân tán. Bài viết tiếp theo sẽ giải mã cách thức hoạt động của một cụm Kafka Cluster và cơ chế bầu chọn tự động để giữ cho "trái tim" của hệ thống phân tán luôn đập ổn định.

🧭 Học theo lộ trình

TechCraft không hướng tới việc chia sẻ những mẹo kỹ thuật rời rạc.

Mục tiêu của TechCraft là xây dựng một lộ trình học giúp Developer từng bước phát triển từ người biết implement feature thành người có thể thiết kế, vận hành và mở rộng các hệ thống production.

Nếu bạn muốn tiếp tục hành trình đó, Dev Insider sẽ là điểm đến tiếp theo.

🚀 Dev Insider https://www.patreon.com/techcraft_official/posts/vi-sao-dev-ra-161163881?collection=2220113

📘 Facebook https://www.facebook.com/techcraft.official

🎥 YouTube https://www.youtube.com/@techcraft.official

🎵 TikTok https://www.tiktok.com/@techcraft.official

Hiểu hệ thống. Không chỉ framework.