📚 Mục Lục

Mục Đích
Vòng Đời Sự Kiện
Dòng Sự Kiện (Chủ Đề)
- events.raw (tầng tiếp nhận)
- events.cleaned (dòng dữ liệu chuẩn hóa)
- trip.events (dòng dữ liệu quan trọng cho doanh nghiệp)
- driver.location (cập nhật tần suất cao)
- dispatch.commands
- billing.events
- analytics.events (phát tán tùy chọn)
Mô Hình Xử Lý
Khả Năng Chịu Lỗi & Độ Tin Cậy
Các Thương Lượng
Ví Dụ Dòng Chảy Tóm Tắt

Hệ Thống Xử Lý Sự Kiện Chuyến Đi Tương Tự Uber (Chi Tiết)

🎯 Mục Đích

Xử lý hàng triệu sự kiện vòng đời chuyến đi mỗi giây.
Hỗ trợ khớp thời gian thực, tính phí, giá cả tăng cường, tính toán ETA, phát hiện gian lận và phân tích.
Đảm bảo độ trễ thấp, độ tin cậy, và tính toán phí chính xác ngay cả khi có sự cố.

Vòng Đời Sự Kiện

Hãy tưởng tượng một hành khách đặt chuyến đi → tài xế chấp nhận → chuyến đi bắt đầu → chuyến đi kết thúc → thanh toán → biên lai.
Mỗi bước tạo ra sự kiện, và Kafka là xương sống vận chuyển và xử lý chúng.

Dòng Sự Kiện (Chủ Đề)

1. `events.raw` (tầng tiếp nhận)

Nó là gì:
- Tất cả các sự kiện thô (yêu cầu người dùng, tín hiệu tài xế, cập nhật chuyến đi, sự kiện thanh toán, nhật ký) sẽ đến đây trước tiên.
- Tương tự như một khu vực staging.
Tại sao:
- Các sự kiện thô có thể không đầy đủ, sai định dạng, bị trùng lặp, hoặc chứa nhiễu (ví dụ: nhiều tín hiệu GPS mỗi giây).
- Bằng cách ghi vào events.raw, bạn không mất mát gì.
- Hành động như một hồ chứa dữ liệu bên trong Kafka — tốt cho việc phát lại, gỡ lỗi, xử lý lại.
Phân vùng:
- Thường phân vùng theo eventType (chuyến đi, vị trí, thanh toán).
- Giữ cho việc tiếp nhận có thể mở rộng trên nhiều người tiêu dùng.

2. `events.cleaned` (dòng dữ liệu chuẩn hóa)

Nó là gì:
- Các sự kiện từ events.raw được xác thực, loại bỏ trùng lặp, kiểm tra định dạng, làm phong phú → ghi vào đây.
- Ví dụ:
- Các sự kiện GPS được tổng hợp thành 1 tín hiệu mỗi X giây.
- Các sự kiện yêu cầu chuyến đi được kiểm tra ID người lái/ hành khách hợp lệ.
- Các sự kiện thanh toán được gán với ID giao dịch.
Tại sao:
- Đảm bảo các hệ thống hạ nguồn nhận dữ liệu nhất quán, có cấu trúc.
- Tách biệt rõ ràng việc xử lý dữ liệu bẩn so với logic kinh doanh.
Phân vùng:
- Theo ID thực thể (ví dụ: tripId, driverId) → giữ nguyên thứ tự cho thực thể đó.

3. `trip.events` (dòng dữ liệu quan trọng cho doanh nghiệp)

Nó là gì:
- Chỉ các sự kiện vòng đời chuyến đi đã được làm sạch (yêu cầu → chấp nhận → bắt đầu → kết thúc → hủy).
- Tình trạng chuyển tiếp của mỗi chuyến đi phải được sắp xếp đúng cách.
Tại sao:
- Hệ thống điều phối sử dụng điều này để khớp hành khách ↔ tài xế.
- Dịch vụ tính phí sử dụng điều này để tính toán phí.
- Phân tích sử dụng điều này để hiểu nhu cầu/cung cấp.
Phân vùng:
- Theo tripId → tất cả các cập nhật chuyến đi sẽ được gửi đến cùng một phân vùng, giữ nguyên thứ tự.

4. `driver.location` (cập nhật tần suất cao)

Nó là gì:
- Các cập nhật GPS liên tục của tài xế (mỗi vài giây).
Tại sao:
- Cần thiết cho:
- Tìm kiếm tài xế gần nhất.
- Tính toán ETA.
- Giá cả tăng cường (tỷ lệ cung-cầu).
Phân vùng:
- Theo driverId (để giữ các cập nhật cho một tài xế theo thứ tự).
- Hoặc theo khu vực geoHash (nhóm tài xế theo các ô vị trí → giúp cân bằng tải).
Xử lý bổ sung:
- Các tín hiệu GPS thô → được làm sạch → sau đó tổng hợp (ví dụ: một vị trí mỗi 5 giây thay vì mỗi 1 giây).

5. `dispatch.commands`

Nó là gì:
- Các lệnh từ hệ thống điều phối/khớp → tài xế.
- Ví dụ: “Tài xế 123, hãy đón hành khách 456”.
Tại sao:
- Đảm bảo giao hàng nhanh và tin cậy của các quyết định khớp.
- Hành động như là tầng điều khiển của hệ thống.
Phân vùng:
- Theo driverId → đảm bảo các lệnh cho một tài xế ở đúng thứ tự.

6. `billing.events`

Nó là gì:
- Các sự kiện quan trọng về tài chính → chuyến đi đã bắt đầu, chuyến đi đã kết thúc, thanh toán đã khởi tạo, thanh toán đã được xác nhận.
Tại sao:
- Cần xử lý chính xác một lần ở đây (không tính phí gấp đôi).
- Phải là nguyên tử: cam kết offset + cập nhật DB + xuất bản sự kiện.
Phân vùng:
- Theo tripId hoặc paymentId.
- Giữ các cập nhật thanh toán cho một chuyến đi theo thứ tự.

7. `analytics.events` (phát tán tùy chọn)

Nó là gì:
- Dòng sự kiện không quan trọng được làm phong phú → bảng điều khiển BI, quy trình máy học.
- Ví dụ: xu hướng nhu cầu, bản đồ nhiệt, báo cáo doanh thu.
Tại sao:
- Giảm tải xử lý phân tích nặng nề khỏi các chủ đề điều phối/ thanh toán cốt lõi.
- Có thể chịu đựng độ trễ nhẹ.

Mô Hình Xử Lý

Xác Thực & Làm Sạch

events.raw → events.cleaned.
Loại bỏ trùng lặp, kiểm tra định dạng, làm phong phú.

Khớp & Điều Phối

events.cleaned + driver.location → hệ thống điều phối.
Kafka Streams KTable để lưu trữ các tài xế hoạt động.
Yêu cầu hành khách khớp với tài xế gần nhất có sẵn.

Quản Lý Vòng Đời Chuyến Đi

trip.events được tiêu thụ bởi máy trạng thái chuyến đi.
Đảm bảo các chuyển tiếp là hợp lệ (không có “trip.end” mà không có “trip.start”).

Tính Phí & Thanh Toán

trip.events + billing.events.
Giao dịch Kafka đảm bảo ghi chính xác một lần vào DB + Kafka.

Phân Tích & ML

analytics.events được sử dụng để dự đoán nhu cầu, giá cả tăng cường, phát hiện gian lận.

Khả Năng Chịu Lỗi & Độ Tin Cậy

Hệ số Nhân bản = 3 cho các chủ đề quan trọng (trip.events, billing.events).
Nhà sản xuất Idempotent = tránh trùng lặp.
Giao dịch Kafka = ghi thanh toán nguyên tử.
Nhân bản đa vùng = MirrorMaker 2 cho việc phục hồi qua vùng.

Các Thương Lượng

Độ trễ thấp so với Chi phí → nhiều phân vùng & broker có tốc độ nhưng chi phí hạ tầng.
Chỉ tính phí một lần cho thanh toán → phần còn lại có thể chịu đựng ít nhất một lần.
Nhiễu tín hiệu vị trí tài xế → phải giảm mẫu để tránh tràn ngập Kafka.

✅ Ví Dụ Dòng Chảy Tóm Tắt:

Hành khách yêu cầu → events.raw → làm sạch → trip.events.
Tài xế gửi GPS → events.raw → làm sạch → driver.location.
Hệ thống khớp tiêu thụ cả hai → tạo ra dispatch.commands.
Khi chuyến đi kết thúc → billing.events → dịch vụ thanh toán.
Tất cả các sự kiện được sao chép vào analytics.events cho BI/ML.

Nếu bạn muốn, hãy bình luận về thiết kế hệ thống gợi ý của Netflix với Kafka nhé!

Tìm hiểu thêm về thiết kế hệ thống

Tìm tất cả các bài viết liên quan đến thiết kế hệ thống
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali
GitHub: https://github.com/ZeeshanAli-0704/SystemDesignWithZeeshanAli

Hệ Thống Xử Lý Sự Kiện Chuyến Đi Tương Tự Uber với Kafka

📚 Mục Lục

Hệ Thống Xử Lý Sự Kiện Chuyến Đi Tương Tự Uber (Chi Tiết)

🎯 Mục Đích

Vòng Đời Sự Kiện

Dòng Sự Kiện (Chủ Đề)

1. `events.raw` (tầng tiếp nhận)

2. `events.cleaned` (dòng dữ liệu chuẩn hóa)

3. `trip.events` (dòng dữ liệu quan trọng cho doanh nghiệp)

4. `driver.location` (cập nhật tần suất cao)

5. `dispatch.commands`

6. `billing.events`

7. `analytics.events` (phát tán tùy chọn)

Mô Hình Xử Lý

Khả Năng Chịu Lỗi & Độ Tin Cậy

Các Thương Lượng

Tìm hiểu thêm về thiết kế hệ thống

Bình luận

Hệ Thống Xử Lý Sự Kiện Chuyến Đi Tương Tự Uber với Kafka

📚 Mục Lục

Hệ Thống Xử Lý Sự Kiện Chuyến Đi Tương Tự Uber (Chi Tiết)

🎯 Mục Đích

Vòng Đời Sự Kiện

Dòng Sự Kiện (Chủ Đề)

1. events.raw (tầng tiếp nhận)

2. events.cleaned (dòng dữ liệu chuẩn hóa)

3. trip.events (dòng dữ liệu quan trọng cho doanh nghiệp)

4. driver.location (cập nhật tần suất cao)

5. dispatch.commands

6. billing.events

7. analytics.events (phát tán tùy chọn)

Mô Hình Xử Lý

Khả Năng Chịu Lỗi & Độ Tin Cậy

Các Thương Lượng

Tìm hiểu thêm về thiết kế hệ thống

Bình luận

1. `events.raw` (tầng tiếp nhận)

2. `events.cleaned` (dòng dữ liệu chuẩn hóa)

3. `trip.events` (dòng dữ liệu quan trọng cho doanh nghiệp)

4. `driver.location` (cập nhật tần suất cao)

5. `dispatch.commands`

6. `billing.events`

7. `analytics.events` (phát tán tùy chọn)