Hàng đợi BullMQ & khoá số dư

Tiền đã vào ví an toàn ở bài trước. Còn hai chỗ chưa ổn: (1) gửi email biến động số dư mà bắt khách đứng chờ thì tệ; (2) lúc khách mua hàng, nếu nhiều yêu cầu trừ tiền cùng lúc, số dư dễ bị trừ lố. Bài này lo cả hai: hàng đợi cho việc (1), khoá số dư cho việc (2).

Gửi email có thể mất một, hai giây (hoặc lỗi rồi phải thử lại). Nếu làm ngay trong lúc khách bấm nút, khách phải đợi cả khoảng đó. Cách đúng: bỏ việc vào hàng đợi rồi trả lời khách ngay; một worker chạy nền lấy ra làm sau:

Khoá dùng BullMQ - một thư viện hàng đợi chạy trên nền Redis (chính Redis mèo con đã thêm để cache). Vậy Redis vừa làm cache vừa làm nền cho hàng đợi.

• ▸App bỏ job vào queue (vd "gửi email biến động cho khách X"), trả lời khách ngay.
• ▸Worker chạy nền lấy job ra xử lý - không nằm trong đường đi của request.
• ▸Job lỗi được THỬ LẠI tự động; quá số lần thì vào dead-letter để xem lại.

Sang việc thứ hai, khó hơn. Giả sử ví khách còn 100, và khách (hoặc hệ thống) gửi hai yêu cầu mua 80 gần như cùng lúc. Đáng lẽ lần hai phải bị từ chối vì không đủ tiền. Nhưng nếu cả hai cùng đọc số dư trước khi ai kịp ghi:

Đây là race condition: nhiều yêu cầu đọc-rồi-ghi cùng một dữ liệu, dẫm lên nhau. Lỗi này khó bắt vì chỉ xảy ra khi đông và đúng nhịp - nhưng ở chỗ tiền thì một lần cũng đủ đau.

Cách nhẹ: không khoá trước. Cứ đọc số dư, nhưng lúc ghi thì kèm điều kiện "số dư vẫn đúng như lúc tôi đọc". Nếu ai đó đã đổi nó giữa chừng, lệnh ghi không khớp và bị huỷ - app thử lại từ đầu với số dư mới.

# đọc số dư hiện tại
so_du = doc()                       # vd 100
# CHỈ trừ nếu số dư vẫn đúng 100 lúc ghi
ok = ghi_neu_con_dung(so_du, so_du - 80)
if not ok:
    thu_lai()                       # ai đó đã đổi -> làm lại từ đầu

Hợp khi ít đụng độ: phần lớn lần ghi trót lọt, thỉnh thoảng mới phải thử lại.

Cách chắc: khoá dòng số dư ngay khi bắt đầu xử lý. Yêu cầu khác đụng tới ví đó phải chờ tới lượt, nên không thể cùng đọc số dư cũ. Xử lý xong, nhả khoá, yêu cầu kế mới vào - và nó thấy số dư đã cập nhật.

• ▸Optimistic: không khoá, kiểm lúc ghi, thử lại nếu lệch - nhẹ, hợp ít đụng độ.
• ▸Pessimistic: khoá dòng khi xử lý, request khác chờ - chắc, hợp chỗ hay đụng và rất nhạy cảm.
• ▸Số dư ví là tiền: ưu tiên chắc. Pessimistic lock (hoặc trừ tiền trong một transaction có khoá) là lựa chọn an toàn.

Hai mảnh ghép lại: hàng đợi để việc nặng không bắt khách chờ, và khoá số dư để tiền không bị trừ lố. Cả hai đều ở chỗ nhạy cảm, nên trước khi mở hãy cho subagent bảo mật rà phần tiền và xử lý đồng thời.