Chuyển tiền ví với nhà cung cấp API: giữ hàng đợi yêu cầu thông suốt
Chuỗi lời gọi chuyển tiền giữa nền tảng và các nhà cung cấp API làm tràn hàng đợi yêu cầu ra sao, và hàng đợi, phản hồi nhanh cùng kết quả được đẩy giữ nền tảng ổn định khi một nhà cung cấp chậm như thế nào.
Nền tảng giữ ví của người dùng; nhà cung cấp API chạy các máy chủ đứng sau những dịch vụ mà nền tảng cung cấp. Trước khi người dùng dùng dịch vụ của một nhà cung cấp, tiền chuyển từ nền tảng sang nhà cung cấp, và khi dùng xong thì chuyển về. Phần lớn các tích hợp làm việc chuyển tiền này thành một chuỗi lời gọi HTTP đồng bộ theo cả hai chiều. Khi tải tăng, chuỗi đó làm đầy hàng đợi yêu cầu của cả hai bên, và chỉ một nhà cung cấp chậm cũng có thể kéo sập cả nền tảng. Độ ổn định của nền tảng bạn không nên phụ thuộc vào máy chủ của người khác.
Một lần chuyển tiền là một chuỗi yêu cầu
Worker của nền tảng bị giữ suốt cả vòng, kể cả đoạn nhà cung cấp gọi ngược lại nền tảng. Worker của nhà cung cấp bị giữ trong lúc chờ lời gọi ngược đó. Hai bên chờ nhau, nên khi lưu lượng tăng, pool của cả hai cùng đầy. Một lần hết thời gian khiến trạng thái chuyển tiền không rõ, kéo theo polling trạng thái và thử lại; không có khóa idempotency thì một lần thử lại có thể chuyển tiền hai lần.
Một nhà cung cấp chậm trở thành vấn đề của mọi người ra sao
Đây là ví dụ tính toán, không phải kết quả đo (viết ngày 2026-11-09): 500 lượt chuyển mỗi giây chia cho ba nhà cung cấp, và pool của nền tảng có 200 worker. Định luật Little cho số worker đang dùng: số lượt chuyển mỗi giây × số giây mỗi lượt giữ một worker.
| HTTP nối chuỗi | Hàng đợi, nhận nhanh và đẩy kết quả | |
|---|---|---|
| Thời gian yêu cầu của người dùng giữ worker của nền tảng | 20 ms + lời gọi nhà cung cấp 150 ms = 170 ms | 20 ms |
| Số worker bận ở 500 lượt chuyển mỗi giây | 500 × 0,17 giây = 85 | 500 × 0,02 giây = 10 |
| Một trong ba nhà cung cấp treo đến khi hết thời gian 5 giây | khoảng 900: pool 200 cạn và mọi nhà cung cấp đều lỗi | vẫn 10: chỉ các lượt chuyển của nhà cung cấp đó phải chờ |
| Yêu cầu trong lúc chờ kết quả | mỗi lượt chuyển đang chờ polling trạng thái mỗi 2 giây | không có, chỉ một lần kiểm tra theo lô mỗi nhà cung cấp sau vài phút |
Sau: nhận nhanh, xử lý ở nền, đẩy kết quả
- Nền tảng trả lời người dùng trước. Ghi lượt chuyển vào sổ cái ở trạng thái đang xử lý, đưa vào hàng đợi rồi trả lời. Trang của người dùng hiện "đang xử lý" và tự cập nhật khi sự kiện đến.
- Bộ điều phối gửi lượt chuyển tới từng nhà cung cấp, kèm khóa idempotency, thời gian chờ ngắn và số chỗ cố định cho mỗi nhà cung cấp. Nhà cung cấp trả 202 ngay khi đã ghi nhận lượt chuyển, nên thử lại với cùng khóa luôn an toàn.
- Không gọi ngược. Yêu cầu mang đủ mọi thứ nhà cung cấp cần, có chữ ký, nên nhà cung cấp không phải gọi ngược nền tảng để kiểm tra.
- Kết quả được đẩy. Nhà cung cấp phát
transfer.settledlên một kênh riêng tư dành cho nền tảng đó, ví dụprivate-partner-acme. Backend của nền tảng giữ một kết nối WebSocket và đăng ký, được endpoint xác thực của nhà cung cấp cấp quyền. Nó cập nhật sổ cái rồi phátbalance.updatedlên kênh ví của người dùng, như trong đồng bộ số dư giữa các sản phẩm. - Một lần kiểm tra cho những gì bị lỡ. Vài phút một lần, nền tảng hỏi mỗi nhà cung cấp các lượt chuyển còn đang xử lý bằng một yêu cầu theo lô, thay vì polling từng lượt.
Giữ nền tảng ổn định khi nhà cung cấp không ổn định
- Mỗi nhà cung cấp một nhóm chỗ riêng. Nhà cung cấp bị chậm chỉ lấp đầy chỗ của chính nó trong bộ điều phối. Đăng nhập, nạp tiền và mọi nhà cung cấp khác vẫn giữ worker của mình.
- Ngừng gửi cho nhà cung cấp không trả lời. Sau một loạt lần hết thời gian, tạm dừng hàng đợi của nhà cung cấp đó, hiển thị dịch vụ của họ là tạm thời không dùng được, rồi thử lại sau một lúc. Lượt chuyển nằm chờ trong sổ cái của bạn ở trạng thái đang xử lý, không nằm trong những kết nối bị giữ.
- Mất kết nối WebSocket không chặn gì cả. Lượt chuyển vẫn được nhận. Khi kết nối trở lại, lần kiểm tra theo lô xử lý những gì xảy ra trong lúc đó.
- Người dùng không bao giờ phải chờ thời gian phản hồi của nhà cung cấp. Trang trả lời theo tốc độ của chính nền tảng, và kết quả hiện ra khi đã sẵn sàng.
Câu hỏi thường gặp
Vì sao một nhà cung cấp API chậm lại làm chậm cả nền tảng?
Vì worker của nền tảng chờ nhà cung cấp đó. Mỗi lời gọi đồng bộ giữ một worker cho đến khi nhà cung cấp trả lời, và các worker đó được dùng chung với mọi thứ khác. Khi một nhà cung cấp chậm lại, worker cạn dần, và cả những yêu cầu không hề liên quan đến nhà cung cấp đó cũng phải xếp hàng phía sau.
WebSocket có thay thế API chuyển tiền không?
Không. Bản thân lượt chuyển vẫn là yêu cầu HTTP có khóa idempotency, được ghi vào sổ cái của cả hai bên. WebSocket thay thế việc chờ: kết nối bị giữ, polling trạng thái và lời gọi ngược. Kết quả đến dưới dạng sự kiện.
Nếu nền tảng đang mất kết nối đúng lúc lượt chuyển hoàn tất thì sao?
Không mất gì, vì sổ cái của cả hai bên đã ghi lượt chuyển. pusher-js và các thư viện client khác tự kết nối lại, và lần kiểm tra theo lô các lượt chuyển đang xử lý sẽ hoàn tất những gì bị lỡ. Dùng ID lượt chuyển để bỏ qua sự kiện đã áp dụng.
Cần bao nhiêu kết nối?
Một kết nối WebSocket từ backend của nền tảng tới kênh của mỗi nhà cung cấp là đủ cho mọi lượt chuyển với nhà cung cấp đó, dù phục vụ bao nhiêu người dùng. Trên Hibira mỗi lần phát tính là một tin nhắn; trên các gói trả phí, lượt gửi tới người đăng ký không được tính. Xem bảng giá.
Tên sản phẩm là nhãn hiệu của chủ sở hữu.