Uber Tăng Tốc Xử Lý Sổ Cái Tài Chính Nhờ Hệ Thống Batching
Uber đã triển khai một hệ thống xử lý sổ cái tài chính có khả năng chịu tải cao, giải quyết vấn đề xung đột ghi dữ liệu trên các tài khoản "nóng". Bằng cách sử dụng kỹ thuật gộp lô 250ms và phối hợp qua Redis, hệ thống đạt tốc độ hơn 30 cập nhật mỗi giây cho mỗi tài khoản, rút ngắn thời gian xử lý từ hàng giờ xuống còn vài phút.

Uber gần đây đã giới thiệu một hệ thống xử lý sổ cái tài chính có độ trễ thấp, được thiết kế để xử lý tình trạng xung đột ghi dữ liệu liên tục trên các tài khoản cá nhân trong hạ tầng kế toán phân tán của mình. Hệ thống này nhắm đến các kịch bản mà một tài khoản đơn lẻ trải qua các đợt cập nhật tập trung có thể vượt quá giới hạn của các mô hình xử lý giao dịch theo yêu cầu truyền thống. Theo các kỹ sư của Uber, thiết kế mới này hỗ trợ hơn 30 cập nhật mỗi giây cho mỗi tài khoản trong khi vẫn duy trì các yêu cầu nghiêm ngặt về tính nhất quán và khả năng kiểm toán.
Nền tảng sổ cái tài chính của Uber được xây dựng dựa trên mô hình kế toán kép (double-entry accounting), ghi lại mọi dòng tiền trong hệ thống. Mô hình này mang lại các đảm bảo mạnh mẽ về tính chính xác và khả năng truy xuất nguồn tin từ đầu đến cuối, nhưng yêu cầu việc tuần tự hóa các cập nhật ở cấp độ tài khoản phải nghiêm ngặt. Trong điều kiện xung đột cao, chẳng hạn như điều chỉnh hàng loạt, đối soát hoặc sửa lỗi vận hành, các tài khoản riêng lẻ có thể trải qua tốc độ cập nhật bền vững, làm lộ ra các điểm nghẽn trong luồng thực thi giao dịch truyền thống.
Trong mô hình thực thi trước đây, mỗi lần cập nhật sổ cái sẽ kích hoạt một chu trình xử lý độc lập bao gồm truy xuất trạng thái, xác thực, tính toán số dư và lưu trữ các mục đã cập nhật cùng với nhật ký kiểm toán. Cách tiếp cận thực thi theo từng yêu cầu này đã tạo ra chi phí đáng kể trong các kịch bản tài khoản "nóng" do các tương tác lưu trữ lặp đi lặp lại và chi phí phối hợp.
Quy trình xử lý tuần tự truyền thống của các sự kiện tài khoản người dùng
Trong thiết kế mới, Uber đã giới thiệu mô hình thực thi dựa trên batching (gộp lô) để xử lý có độ trễ thấp. Thay vì xử lý từng cập nhật một cách độc lập, hệ thống tổng hợp nhiều hoạt động nhắm đến cùng một tài khoản vào các cửa sổ thời gian ngắn. Các lô dữ liệu này sau đó được xử lý cùng nhau, cho phép nhiều cập nhật chia sẻ một chu kỳ đọc và ghi sổ cái duy nhất.
Raghav Kumar Gautam, Kỹ sư Phần mềm Cấp cao tại Uber, nhấn mạnh:
"Chúng tôi đã xây dựng một hệ thống xử lý giao dịch để xử lý lưu lượng truy cập cực đoan mà không hy sinh tính nhất quán. Sử dụng batching 250ms, phối hợp qua Redis và các cập nhật nguyên tử lạc quan, hệ thống xử lý hơn 30 giao dịch mỗi giây cho mỗi tài khoản trên một kiến trúc có khả năng mở rộng theo chiều ngang - rút ngắn các quy trình xử lý kéo dài hàng giờ xuống còn vài phút."
Kiến trúc hệ thống xử lý theo lô cho tài khoản người dùng
Quy trình làm việc được cấu trúc thành ba giai đoạn. Đầu tiên, các cập nhật đầu vào được nhóm thành các lô dữ liệu dựa trên thời gian và mối liên hệ với tài khoản. Tiếp theo, các hoạt động đã được gộp lô được thực thi như một đơn vị nguyên tử đối với trạng thái sổ cái, nơi xác thực và cập nhật số dư được áp dụng một lần cho mỗi lô. Cuối cùng, kết quả được lưu trữ và truyền tải đến các hệ thống hạ nguồn, bao gồm ghi nhật ký kiểm toán và quy trình đối soát.
Khoảng thời gian gộp lô khoảng 250 mili-giây. Việc phối hợp để nhóm các cập nhật được xử lý bằng Redis, trong khi các cơ chế cập nhật nguyên tử lạc quan đảm bảo tính chính xác dưới các mẫu truy cập đồng thời. Thiết kế này cho phép khả năng mở rộng theo chiều ngang trong khi vẫn duy trì các đảm bảo về tính nhất quán cần thiết cho độ chính xác tài chính.
Một cân nhắc thiết kế quan trọng trong hệ thống là sự đánh đổi giữa kích thước cửa sổ batching và độ trễ đầu cuối. Các cửa sổ nhỏ hơn giảm độ trễ nhưng tăng chi phí tổng thể, trong khi các cửa sổ lớn hơn cải thiện hiệu suất xử lý nhưng làm chậm thời gian xử lý. Cấu hình cuối cùng sử dụng các cửa sổ batching được kiểm soát chặt chẽ để cân bằng giữa các yêu cầu xử lý gần thời gian thực và hiệu quả của hệ thống.
Hệ thống cũng kết hợp các cơ chế cô lập lỗi để xử lý các lỗi từng phần trong một lô. Các sự cố lưu trữ hoặc mạng tạm thời được cô lập ở cấp độ hoạt động nếu có thể, giúp giảm thiểu việc thử lại quá mức và cải thiện tính ổn định trong điều kiện tải cao.
Uber báo cáo rằng kiến trúc này làm giảm đáng kể thời gian xử lý cho các khối lượng công việc lớn, cải thiện tốc độ đối soát tài chính và quy trình làm việc vận hành trên các hệ thống thị trường của họ.
Bài viết liên quan

Công nghệ
CEO Palantir: 10% thế giới "ghét chúng tôi một cách chuyên nghiệp"
05 tháng 5, 2026

Phần mềm
GitLab cắt giảm 14% nhân sự để tái cấu trúc hạ tầng phục vụ AI
03 tháng 6, 2026
Phần mềm
Lo ngại về Bun: Liệu sự suy giảm của Claude Code có phải là điềm báo cho tương lai của runtime này?
04 tháng 5, 2026
