Ràng buộc và ước lượng: bao nhiêu tiền đang treo?

TL;DR: Case này đặt đỉnh 3.000 lượt thanh toán mỗi giây trong 10 phút sale. Với 0,2% lượt không rõ kết quả sau một phút (gọi là giao dịch mập mờ), mỗi đợt để lại khoảng 3.600 giao dịch, trong đó chừng 2.160 giao dịch khách đã bị trừ thật: khoảng 540 triệu đồng đang treo mà hệ thống chưa biết. Mỗi lượt ghi bốn bút toán (bốn dòng ghi tiền vào sổ) và chạm cả ba tài khoản chung (tài khoản mà lượt thanh toán nào cũng ghi vào), nên mỗi tài khoản chung nhận 3.000 lượt ghi mỗi giây, trong khi một hàng Postgres bị ghi dồn chỉ chịu cỡ 1.200. Bạn sẽ tự đo trần đó bằng pgbench.

Đợt sale chạy từ 21 giờ tới 21 giờ 10. Sau đó tổng đài báo hơn 600 cuộc gọi trong nửa giờ, dashboard vẫn xanh: "App trừ tiền tôi rồi mà đơn vẫn chờ thanh toán". Mấy lệnh trừ tiền đó chưa có câu trả lời, chứ chưa thất bại.

Lệnh trừ tiền chạy ở nhà cung cấp: bạn không khoá được, không rollback được, có lúc không biết nó đã chạy chưa. Bài này công bố bảng ràng buộc của case rồi biến nó thành bốn con số, chưa có thiết kế nào.

1. Analogy: chuyển khoản lúc app quay mãi

Bạn chuyển khoản, app quay mãi rồi báo mất kết nối. Tiền đi chưa? Bấm lại thì sợ chuyển hai lần, nên bạn chờ tin nhắn số dư, mở lịch sử giao dịch, cuối tháng dò sao kê. Server của bạn gặp đúng chuyện này vài nghìn lần mỗi đợt sale.

2. Bảng ràng buộc: những con số cả case đứng trên

Bảng dưới là ràng buộc tự đặt, các bài sau trích lại đúng bộ số này. Trang cổng là trang thanh toán của nhà cung cấp, nơi khách tự quét QR hay nhập thẻ. IPN (Instant Payment Notification) là lời gọi HTTP nhà cung cấp chủ động gửi vào URL của bạn để báo kết quả. Một chạm là kiểu server của bạn tự gọi lệnh trừ tiền từ ví hay thẻ đã liên kết.

p99 là mốc mà 99% lượt nhanh hơn nó. Dòng "10 năm" lấy từ Luật Kế toán 88/2015, Điều 41 khoản 5 điểm b, vốn quy định cho chứng từ dùng trực tiếp để ghi sổ; case áp mức đó cho cả bút toán trong sổ cái.

3. Lúc đỉnh có bao nhiêu lượt thanh toán mỗi giây?

Ước lượng thô (back-of-envelope), đủ để biết bậc độ lớn:

• Ngày thường: 400.000 ÷ 86.400 giây ≈ 4,6, làm tròn 5 lượt mỗi giây.
• Đỉnh sale: 3.000 lượt mỗi giây, gấp 600 lần ngày thường.

Khác flash sale, đỉnh ở đây kéo dài 10 phút, đủ lâu để mọi hàng đợi phía sau kịp đầy. 30% lượt là lệnh một chạm: 900 lệnh mỗi giây server tự gọi ra ngoài.

Thử ngẫmmột thiết kế chỉ hỏng khi tải gấp 600 lần ngày thường thì sẽ lộ ra ở ngày thường hay chỉ ở đêm sale, và vì sao đó là cái bẫy?

4. Bao nhiêu giao dịch mập mờ, bao nhiêu tiền thật sự treo?

Giao dịch mập mờ là giao dịch sau một phút vẫn chưa rõ kết quả: lệnh một chạm hết timeout, hoặc khách đã trả trên trang cổng mà IPN chưa tới.

Lời giải:

Dòng (d) chỉ tính khách đã bị trừ. Bạn đâu biết giao dịch nào chưa trừ, nên cả 3.600 đều phải được chốt.

Mất bao lâu để biết? Tra cứu một vòng: 3.600 ÷ 10 lượt mỗi giây = 6 phút. IPN gửi lại trong khoảng 50 phút, endpoint chết lâu hơn thì mất hẳn. File đối soát: giao dịch lúc 0:01 chờ khoảng 30 giờ.

Nguồn nhanh nhất bị giới hạn lượt gọi, nguồn chắc nhất lại muộn hơn hạn. Lúc đỉnh, 6 giao dịch mập mờ mới mỗi giây đã ăn 60% hạn mức tra cứu.

Thử ngẫmlần tra cứu đầu trả về "đang xử lý". Với 6 giao dịch mập mờ mới mỗi giây, hạn mức 10 lượt còn đủ cho lần hỏi thứ hai không?

5. Ba tài khoản chung nhận bao nhiêu lượt ghi mỗi giây?

Bút toán là một dòng ghi số tiền vào một tài khoản kế toán, ở cột Nợ hoặc cột Có; nhóm bút toán của một lượt thanh toán phải có tổng Nợ bằng tổng Có. Đơn 250.000 đ, phí nhà cung cấp 1,1% do sàn chịu, phí sàn 5%:

Hai cột cùng ra 250.000. Tài khoản chung là tài khoản lượt nào cũng ghi vào; tài khoản người bán thì mỗi người một cái.

Lúc đỉnh, mỗi tài khoản chung nhận 3.000 lượt ghi mỗi giây. Mười năm ngày thường là 400.000 × 4 × 365 × 10 ≈ 5,84 tỉ dòng, chưa cộng đợt sale.

Nếu mỗi lượt UPDATE một cột số dư, ba hàng của ba tài khoản chung là ba hàng bị mọi lượt ghi dồn vào.

6. Tự đo trần ghi một hàng tài khoản

pgbench là công cụ benchmark đi kèm Postgres: mở nhiều kết nối, chạy lặp một script SQL, rồi in TPS (transaction mỗi giây). Tạo 10.003 tài khoản, id 1 đến 3 là ba tài khoản chung:

createdb paylab
psql paylab -c "CREATE TABLE accounts (
  id int PRIMARY KEY, balance bigint NOT NULL);"
psql paylab -c "INSERT INTO accounts
  SELECT g, 0 FROM generate_series(1, 10003) g;"

Lưu hai file: one.sql chỉ ghi tài khoản phải thu, four.sql ghi đủ bốn dòng (dấu cộng trừ chỉ là quy ước):

-- one.sql
BEGIN;
UPDATE accounts SET balance = balance + 247250 WHERE id = 1;
COMMIT;

-- four.sql
\set seller random(4, 10003)
BEGIN;
UPDATE accounts SET balance = balance + 247250 WHERE id = 1;
UPDATE accounts SET balance = balance + 2750 WHERE id = 2;
UPDATE accounts SET balance = balance - 12500 WHERE id = 3;
UPDATE accounts SET balance = balance - 237500 WHERE id = :seller;
COMMIT;

pgbench -n -f one.sql  -c 1  -j 1 -T 10 paylab
pgbench -n -f one.sql  -c 50 -j 5 -T 10 paylab
pgbench -n -f four.sql -c 50 -j 5 -T 10 paylab

-c là số kết nối, -j số luồng, -T 10 chạy 10 giây, -n bỏ vacuum. Số tác giả: Postgres 16.15 trong Docker, Apple M4 10 nhân, hai lần chạy.

Lời giải phép thử đoán: xấp xỉ bằng, thấp hơn khoảng 20%. Mọi transaction xếp hàng ngay ở hàng id 1; ai giữ được nó thì gần như đi thẳng qua hàng 2 và 3, vì người khác còn chờ ở hàng 1. Trần vẫn là trần của một hàng.

Lúc máy bận, one.sql ở 50 kết nối từng rơi xuống 680 TPS, nên mang theo tỉ lệ: 3.000 ÷ 1.200 = 2,5 lần.

2,5 lần nghe nhẹ hơn chừng 40 lần của flash sale, nhưng tải vượt trần kéo dài 10 phút và thứ xếp hàng là bút toán tiền. Ngày thường cách trần hơn hai trăm lần, nên cột số dư không lộ gì cho tới tối sale.

7. Hai lỗi ước lượng hay gặp

❌ Nhầm 1: đo trần bằng script ghi rải nhiều tài khoản.

\set seller random(4, 10003)
BEGIN;
UPDATE accounts SET balance = balance - 237500 WHERE id = :seller;
COMMIT;

✅ Script này đạt 14.000 đến 22.000 TPS ở 50 kết nối trên máy tác giả, vì lượt ghi rải ra 10.000 hàng. Lượt thanh toán thật luôn ghi cùng ba hàng chung, nên phải đo one.sql:

BEGIN;
UPDATE accounts SET balance = balance + 247250 WHERE id = 1;
COMMIT;

❌ Nhầm 2: tính tiền treo bằng cả 3.600 giao dịch mập mờ (ra 900 triệu đ).

✅ Chỉ 60% đã trừ, nên tiền thực sự treo là 540 triệu đ; 1.440 giao dịch còn lại vẫn phải chốt.

SELECT 3600 * 250000;        -- 900000000: wrong, counts uncharged too
SELECT 3600 * 0.6 * 250000;  -- 540000000: right, charged share only

8. Câu hỏi nào bảng số này chưa trả lời?

1. Giữ hàng 10 phút mà hạn trả 15 phút: khách trả ở phút thứ 12 thì hàng đã về kho. Bài 02.
2. Một hàng chịu cỡ 1.200 lượt ghi mỗi giây: số dư giữ ở đâu mà vẫn đọc được 500 lượt mỗi giây, p99 dưới 50 ms? Bài 04.
3. File tới sau 30 giờ, hạn 24 giờ: ghép ba nguồn kết quả thế nào? Bài 05.

9. Đào sâu: nguồn để tự kiểm số của mình

• pgbench (PostgreSQL 16): các cờ đã dùng, dòng tps =, hàm random trong \set.
• Explicit Locking (PostgreSQL 16): khoá mức hàng, vì sao UPDATE cùng hàng chờ tới khi transaction kia kết thúc.
• Luật Kế toán 88/2015/QH13: Điều 41 khoản 5, nguồn của dòng "lưu vết 10 năm".

10. Liên hệ các bài khác

• Bài 02: Tin kết quả trả về: dùng bảng này để tái hiện bốn kiểu lệch tiền.
• Bài 04: Sổ cái chỉ ghi thêm: quay lại tỉ lệ 2,5 lần và 5,84 tỉ dòng.

11. Tóm tắt

• Ước lượng tiền treo: nhân số giao dịch mập mờ với tỉ lệ đã trừ, rồi mới nhân giá đơn.
• Đo trần cho sổ tiền: đo đúng hàng mà mọi lượt cùng ghi, đừng đo hàng rải đều.
• Việc cần làm: chạy one.sql và four.sql ở 50 kết nối, rồi chia 3.000 cho trần của bạn.

12. Tự kiểm tra

Bài tiếp theo: Tin kết quả trả về: tiền đi đâu khi khách đóng trình duyệt?