Kafka
Engineering · Phạm Mạnh Lực
APACHE KAFKA --- ## 1. Phần Mở đầu: Bối cảnh & Nỗi đau **Tại sao bạn cần quan tâm?** Hãy tưởng tượng bạn đang vận hành một hệ thống bán hàng online...
APACHE KAFKA
1. Phần Mở đầu: Bối cảnh & Nỗi đau
Tại sao bạn cần quan tâm?
Hãy tưởng tượng bạn đang vận hành một hệ thống bán hàng online cực lớn như Shopee hay Lazada vào ngày Sale 11/11.
Mỗi khi có một khách hàng bấm nút "Đặt mua", hệ thống phải làm hàng tá việc cùng lúc:
- Trừ kho hàng (Inventory).
- Tính tiền và thanh toán (Payment).
- Gửi thông báo cho người bán (Notification).
- Gửi email xác nhận cho khách (Email Service).
- Lưu lịch sử để gợi ý món đồ tiếp theo (Analytics).
Nỗi đau ("Cơn ác mộng mỳ ý"): Ngày xưa, cách làm cũ là nối dây trực tiếp: Dịch vụ Đặt hàng sẽ gọi thẳng cho 5 dịch vụ kia.
- Vấn đề 1 (Chết chùm): Nếu ông "Gửi email" bị lỗi mạng, ông "Đặt hàng" cũng bị treo theo để chờ. Khách hàng bấm mua mà cứ quay vòng vòng.
- Vấn đề 2 (Quá tải): Ngày Sale, 1 triệu đơn hàng ập đến. Hệ thống kho hàng không kịp xử lý, sập nguồn. Dữ liệu đơn hàng bị mất sạch.
- Vấn đề 3 (Rối rắm): Khi bạn muốn thêm một chức năng mới (ví dụ: Tích điểm), bạn phải sửa lại code của ông Đặt hàng để nối thêm dây. Lâu dần, hệ thống rối như một đĩa mỳ ý (Spaghetti code).
Giải pháp: Chúng ta cần một "người vận chuyển trung gian". Người này có nhiệm vụ: Nhận đơn hàng cực nhanh, cất vào một chỗ an toàn, ai cần xử lý thì cứ thong thả vào lấy mà làm. Dù hệ thống con có chết, đơn hàng vẫn nằm đó, không mất đi đâu cả.
"Người vận chuyển" siêu đẳng đó chính là Apache Kafka.
2. Phần Lý thuyết cốt lõi (20% Quan trọng nhất)
Định nghĩa đơn giản (Tư duy Ẩn dụ)
Đừng nghĩ Kafka là phần mềm phức tạp. Hãy tưởng tượng Kafka giống như một Hệ thống băng chuyền chuyển phát nhanh khổng lồ tại một trung tâm Logistics.
- Người gửi (Producer): Là các ứng dụng tạo ra dữ liệu (ví dụ: App đặt hàng). Họ chỉ việc quăng gói hàng (dữ liệu) lên băng chuyền và đi làm việc khác. Họ không cần biết ai sẽ nhận, cũng không cần chờ người nhận ký tên.
- Băng chuyền (Kafka): Chạy liên tục, cực nhanh, có khả năng chứa hàng tấn gói hàng mà không bị tắc nghẽn. Nó lưu trữ gói hàng theo thứ tự, an toàn và bền vững.
- Người nhận (Consumer): Là các ứng dụng xử lý (Kho, Ship, Email). Họ đứng cuối băng chuyền, lấy gói hàng xuống và xử lý theo tốc độ của riêng họ. Nếu ông "Ship" làm chậm, hàng vẫn nằm trên băng chuyền đợi, không bị mất.
Nguyên lý hoạt động (Visual Thinking)
Dòng chảy dữ liệu (Data Pipeline) trong Kafka diễn ra như sau:
INPUT (Đầu vào) --> KAFKA (Đường ống) --> OUTPUT (Đầu ra)
- Input: Một sự kiện xảy ra (ví dụ: "Khách A vừa quẹt thẻ 500k").
- Kafka: Ghi chép sự kiện này vào một cuốn nhật ký (Log) không thể tẩy xóa, sắp xếp theo thời gian.
- Output: Các hệ thống khác (Ngân hàng, App thông báo) đọc dòng nhật ký đó và thực hiện hành động tương ứng.
Các thuật ngữ "Xương sống" (Phải nhớ)
Để nói chuyện được với dân kỹ thuật, bạn chỉ cần nắm 4 từ khóa này:
| Thuật ngữ | Giải thích đời thường (Ẩn dụ) | Ví dụ thực tế |
|---|---|---|
| Topic | Chủ đề/Ngăn chứa. Trên băng chuyền có nhiều làn. Bạn không thể ném lẫn lộn giày dép với đồ ăn. Topic chính là tên của cái làn đó. | Topic "Don_Hang", Topic "Dinh_Vi_Xe", Topic "Lich_Su_Click". |
| Producer | Người phát tin. Bất cứ ai tạo ra dữ liệu và đẩy vào Kafka. | App Grab trên máy tài xế (gửi tọa độ GPS về). |
| Consumer | Người tiêu thụ. Bất cứ ai đăng ký lắng nghe và lấy dữ liệu từ Kafka về dùng. | Bản đồ trên máy khách (lấy tọa độ để hiển thị xe đang chạy). |
| Partition | Phân luồng cao tốc. Nếu Topic "Don_Hang" quá đông, Kafka xẻ nó ra làm nhiều rãnh nhỏ (Partition 1, 2, 3) để nhiều người cùng xếp hàng xử lý cho nhanh. | Giống như trạm thu phí mở thêm làn để xe qua nhanh hơn. |
3. Phần Ứng dụng thực tế (80% Giá trị)
Đây là lý do tại sao Kafka trở thành "xương sống" của các tập đoàn công nghệ lớn như Netflix, Uber, LinkedIn (nơi đẻ ra Kafka), và Shopee.
Case Study 1: Theo dõi vị trí tài xế (Grab/Uber/Be)
- Bối cảnh: Hàng triệu tài xế di chuyển liên tục. Mỗi giây, vị trí của họ thay đổi.
- Vấn đề: Làm sao cập nhật vị trí này lên bản đồ của khách hàng, đồng thời tính cước phí, và lưu lại lộ trình để giải quyết khiếu nại mà không làm sập server vì quá nhiều dữ liệu?
- Cách Kafka giải quyết:
- App tài xế (Producer) bắn tọa độ GPS liên tục vào Kafka Topic
Vi_Tri_Tai_Xe. - Hệ thống Kafka nhận hàng triệu tọa độ mỗi giây, xếp hàng ngay ngắn.
- Consumer 1 (App Khách): Đọc tọa độ mới nhất để vẽ cái xe chạy trên bản đồ.
- Consumer 2 (Hệ thống tính tiền): Đọc quãng đường để tính tiền cuối chuyến.
- Consumer 3 (Big Data): Lưu lại để phân tích khu vực nào hay kẹt xe.
- Kết quả: Mọi thứ diễn ra theo thời gian thực (Real-time), mượt mà.
- App tài xế (Producer) bắn tọa độ GPS liên tục vào Kafka Topic
Case Study 2: Gợi ý phim/sản phẩm (Netflix/Shopee)
- Bối cảnh: Bạn vừa xem xong phim "Người Nhện".
- Vấn đề: Netflix muốn ngay lập tức gợi ý cho bạn xem tiếp "Iron Man" hoặc "Avengers".
- Cách Kafka giải quyết:
- Hành động "Xem xong phim" của bạn được bắn vào Kafka.
- Hệ thống Phân tích (Recommendation Engine) ngay lập tức vợt lấy thông tin đó từ Kafka, chạy thuật toán và bắn ngược lại danh sách phim gợi ý lên màn hình của bạn chỉ trong vài tích tắc.
- Nếu không có Kafka, hệ thống sẽ phải đợi đến cuối ngày chạy "batch" (xử lý lô) thì sáng mai bạn mới thấy gợi ý, lúc đó thì mất hứng rồi.
Case Study 3: Giám sát Log hệ thống (Log Aggregation)
- Bối cảnh: Một công ty có 100 con server. Khi có lỗi xảy ra, kỹ sư phải đi lục lọi từng con server để xem file báo lỗi (Log file). Rất mất thời gian.
- Cách Kafka giải quyết:
- Tất cả 100 con server đều bắn log lỗi về một Kafka Topic chung là
System_Logs. - Một hệ thống giám sát trung tâm sẽ đọc Topic này và hiển thị lên màn hình dashboard.
- Kỹ sư chỉ cần nhìn một chỗ là biết ngay server nào đang "hắt hơi sổ mũi".
- Tất cả 100 con server đều bắn log lỗi về một Kafka Topic chung là
Bảng Ưu/Nhược điểm (Sự thật trần trụi)
| Ưu điểm (Được) | Nhược điểm (Mất/Thách thức) |
|---|---|
| Thông lượng cực cao (High Throughput): Xử lý hàng triệu tin nhắn/giây là chuyện bình thường. | Khó cài đặt & Vận hành: Kafka rất mạnh nhưng cấu hình nó rất "chua". Cần đội ngũ kỹ sư xịn (DevOps) để nuôi nó. |
| Độ trễ thấp (Low Latency): Gần như tức thì (Real-time). | Quá cồng kềnh cho dự án nhỏ: Nếu bạn làm web bán hàng cho tiệm tạp hóa, dùng Kafka là "lấy dao mổ trâu giết gà". |
| Độ bền (Durability): Dữ liệu được lưu trên ổ cứng, sao chép ra nhiều bản, rất khó mất. | Không phải Database: Đừng dùng Kafka để truy vấn dữ liệu phức tạp như SQL. Nó chỉ là nơi lưu trữ dòng chảy sự kiện. |
4. Góc nhìn đa chiều
Hiểu lầm phổ biến
- "Kafka là cái hàng đợi (Queue) giống RabbitMQ thôi mà?"
- Sai. RabbitMQ giống như hòm thư: Bạn lấy thư ra là thư mất tiêu (xử lý xong là xóa). Còn Kafka giống như cuốn băng ghi âm: Bạn nghe xong, cuộn băng vẫn còn đó. Người khác có thể tua lại để nghe. Điều này cực quan trọng nếu bạn muốn "tua lại" dữ liệu để sửa lỗi (Replay).
- "Kafka thay thế được Database."
- Sai. Kafka lưu dữ liệu có thời hạn (thường mặc định là 7 ngày). Nó tối ưu cho việc di chuyển dữ liệu, không phải để lưu trữ vĩnh viễn và truy vấn phức tạp.
Cảnh báo
- Chi phí ẩn: Kafka miễn phí (Open source), nhưng tiền server để chạy nó (cần RAM to, ổ cứng xịn) và tiền lương trả cho kỹ sư vận hành nó là rất lớn. Hãy cân nhắc kỹ trước khi dùng.
5. Thực hành & Hành động
Vì cài đặt Kafka trên máy tính cá nhân khá phức tạp với người mới (phải cài Java, Zookeeper...), tôi đề xuất bạn "sờ" thử khái niệm của nó qua cách đơn giản hơn:
Hành động 1: Trải nghiệm tư duy "Pub/Sub" (Publish/Subscribe)
- Hãy thử trang web: MQTT.fx hoặc các trang demo online về WebSocket. Tuy không phải là Kafka, nhưng nó dùng chung tư duy: Một bên gửi (Pub), một bên nhận (Sub) theo thời gian thực.
Hành động 2: Xem trực quan (Dành cho ai muốn thấy tận mắt)
- Vào trang chủ của Confluent (Công ty đứng sau Kafka). Họ có rất nhiều video mô phỏng (Visualizer) cách các hạt dữ liệu chạy trong đường ống.
- Hoặc tìm kiếm từ khóa trên YouTube: "Kafka visualizer demo" để xem các chấm tròn (dữ liệu) chạy từ Producer sang Consumer như thế nào.
Hành động 3: Tư duy thiết kế (Dành cho dân văn phòng)
- Hãy nhìn lại quy trình làm việc của team bạn. Có khâu nào đang bị tắc nghẽn vì phải chờ đợi nhau không?
- Hãy vẽ ra giấy: Nếu áp dụng tư duy Kafka (bỏ việc vào một chỗ chung, ai rảnh thì lấy làm), quy trình sẽ thay đổi thế nào? Đó chính là cách áp dụng tư duy công nghệ vào quản trị.
6. Tổng kết & Kiểm tra
3 Điểm cốt lõi phải nhớ (Take-away)
- Kafka là "Đường ống dẫn nước": Nó giúp vận chuyển dữ liệu khổng lồ từ nơi này sang nơi khác một cách siêu tốc và an toàn.
- Tách rời (Decoupling): Giúp người gửi và người nhận không cần biết nhau, không cần chờ nhau. Hệ thống này chết, hệ thống kia vẫn sống.
- Không xóa ngay: Khác với các hàng đợi tin nhắn thường, Kafka lưu dữ liệu lại (như cuốn băng), cho phép tua lại xử lý khi cần.
Câu hỏi kiểm tra (Tự ôn tập)
- Nếu Consumer (người nhận) bị mất điện 1 tiếng đồng hồ, dữ liệu trong Kafka có bị mất không? Tại sao?
- Trong ví dụ về Grab, ai là Producer và ai là Consumer?
- Topic trong Kafka được ví với cái gì trong đời sống?
- Tại sao nói dùng Kafka cho một blog cá nhân đơn giản là "lấy dao mổ trâu giết gà"?
- Kafka giải quyết vấn đề "Spaghetti code" (rối rắm) như thế nào?
Bạn hãy để lại câu trả lời cho phần bài tập dưới phần bình luận nhé!