Thiết kế cơ chế khóa tồn kho tạm thời (Inventory Reservation) chống bán vượt tồn kho khi chạy Flash Sale đa kênh

1. Giải phẫu lỗi Điều kiện tranh chấp (Race Condition) khiến Website bán âm tồn kho dịp Flash Sale

Nguyên nhân gốc rễ khiến phần lớn Website thương mại điện tử truyền thống bị bán lố số lượng tồn kho khi chạy Flash Sale nằm ở mô hình lập trình Đọc trước - Kiểm tra - Ghi sau (Check-Then-Act) không nguyên tử. Cụ thể, khi người mua bấm nút Đặt hàng, mã nguồn ứng dụng thường thực hiện câu lệnh SELECT để kiểm tra xem số lượng tồn kho hiện tại trong cơ sở dữ liệu có lớn hơn hoặc bằng số lượng khách mua hay không; nếu thỏa mãn mới tiến hành tạo đơn hàng và chạy câu lệnh UPDATE trừ tồn kho.

Trong điều kiện lưu lượng ngày thường, khoảng thời gian vài chục mili giây giữa câu lệnh SELECT và câu lệnh UPDATE hiếm khi xảy ra va chạm. Thế nhưng, đúng vào giây 00:00 của chương trình Flash Sale, khi sản phẩm chỉ còn đúng 1 chiếc cuối cùng trong kho mà có tới 200 yêu cầu HTTP đồng thời đi vào các tiến trình máy chủ ứng dụng, cả 200 luồng cùng chạy câu lệnh SELECT tại một thời điểm và đều nhận được kết quả tồn kho đang bằng 1. Hệ quả là cả 200 luồng đều vượt qua bước kiểm tra điều kiện và lần lượt chạy lệnh trừ kho, khiến hệ thống ghi nhận thành công 200 đơn hàng và đẩy số tồn kho trong bảng dữ liệu về mức âm (-199).

Nguy cơ thứ hai đến từ độ trễ đồng bộ đa kênh. Khi một doanh nghiệp vừa mở bán trên Website, vừa bán trực tiếp tại chuỗi cửa hàng vật lý (POS) và các kênh trực tuyến khác trên cùng một bể tồn kho dùng chung (Shared Pool), khoảng trễ chỉ từ 5 đến 30 giây trong việc cập nhật số liệu giữa các kênh cũng đủ để hàng trăm sản phẩm đã bán hết tại quầy thu ngân vẫn tiếp tục cho phép đặt mua trên Website.

Vuốt ngang để xem đủ bảng →

3. Thực thi nguyên tử với Redis Lua Script và đồng bộ xuống cơ sở dữ liệu quan hệ (PostgreSQL / MySQL)

Để chịu được áp lực hàng chục nghìn lượt bấm mua trong cùng một giây mở màn Flash Sale mà không làm sập cơ sở dữ liệu PostgreSQL hay MySQL, toàn bộ thao tác kiểm tra và giữ chỗ tồn kho ở Bước 1 phải được đưa lên tầng bộ nhớ trong (In-Memory Data Store) bằng **Redis**. Vì kiến trúc xử lý lệnh của Redis hoạt động theo mô hình đơn luồng (Single-threaded Event Loop), mọi tập lệnh **Lua Script** chạy qua lệnh EVAL hoặc EVALSHA đều được thực thi nguyên tử (Atomic): không một yêu cầu nào khác có thể xen ngang vào giữa lúc tập lệnh Lua đang kiểm tra và trừ số dư tồn kho.

Trước giờ mở bán Flash Sale khoảng 15 phút, một tiến trình khởi tạo (Warm-up Job) sẽ nạp số lượng suất bán Flash Sale đã được duyệt của từng mã SKU từ cơ sở dữ liệu lên các khóa Redis (ví dụ: flashsale:stock:{campaign_id}:{sku_id}). Khi người dùng bấm nút mua, máy chủ API gọi tập lệnh Lua trên Redis để thực hiện trọn gói 3 việc trong chưa đầy 1 mili giây: kiểm tra xem tài khoản người dùng (User ID) đã vượt quá giới hạn số lượng mua tối đa mỗi tài khoản hay chưa, kiểm tra số dư tồn kho trên Redis có đủ không, và nếu đủ thì giảm ngay số dư đồng thời ghi nhận mã phiên giữ chỗ.

Chỉ những yêu cầu nào nhận được kết quả trả về thành công (1) từ Redis Lua Script mới được phép đi tiếp vào hàng đợi Message Queue để khởi tạo bản ghi đơn hàng trong cơ sở dữ liệu PostgreSQL/MySQL. Toàn bộ hàng nghìn yêu cầu đến muộn vài mili giây khi kho đã về 0 sẽ bị chặn lại ngay tại tầng Redis và nhận phản hồi “Sản phẩm vừa hết suất Flash Sale” tức thì mà không hề chạm tới ổ cứng của cơ sở dữ liệu chính.

• Tách biệt bể tồn kho chiến dịch (Campaign Quota Allocation): khi chạy Flash Sale đa kênh, doanh nghiệp nên trích trước một số lượng cố định (ví dụ 200 chiếc dành riêng cho Flash Sale Website) tách khỏi bể tồn kho bán thường tại cửa hàng POS để tránh xung đột chéo trong khung giờ cao điểm.
• Xử lý trường hợp biên “Thanh toán trễ sau khi hết hạn TTL” (Late Payment Webhook): nếu khách hàng quét mã chuyển khoản ở phút thứ 9:58 nhưng do mạng ngân hàng trễ nên đến phút 10:05 Webhook mới báo về (lúc này suất giữ chỗ đã bị hủy), hệ thống phải tự động kiểm tra xem kho còn hàng tự do để cấp lại hay không; nếu đã hết sạch hàng thì lập tức kích hoạt luồng hoàn tiền tự động (Auto-Refund) và gửi thông báo ngay cho khách.
• Cấu hình Redis Persistence (AOF - Append Only File ở chế độ everysec kết hợp Redis Sentinel/Cluster) kèm cơ chế đối chiếu nhanh với bảng inventory_reservations dưới DB để khôi phục chính xác trạng thái giữ chỗ nếu nút Redis gặp sự cố khởi động lại.