Khoá chống trùng: chặn được trùng nào, để lọt trùng nào?

TL;DR: Tin trùng trong luồng gửi ít nhất một lần đến từ hai chỗ. Job lặp sinh ra trước bảng job (client gọi lại API, consumer xử lý lại sự kiện), và ràng buộc duy nhất trên khoá (người dùng, loại, mã nghiệp vụ) cộng ON CONFLICT DO NOTHING chặn được toàn bộ. Tin trùng do timeout sinh ra sau lời gọi nhà cung cấp nên khoá phía bạn không thấy. Phần đó chỉ thu hẹp được khi nhà cung cấp nhận khoá gửi kèm; với SMS không nhận khoá, khoảng 0,25% tin trùng vẫn còn nguyên.

Bài 03 đã chọn gửi ít nhất một lần cho tin giao dịch: thà trùng còn hơn mất. Cho 100.000 tin giao dịch chạy qua vòng gửi của bài 02, người dùng nhận về 103.202 tin. Gắn một khoá chống trùng là xong? Tuỳ khoá: khoá sai còn nuốt luôn tin thật.

1. Hai loại tin trùng, hai chỗ sinh ra

Hai nhân viên cùng nhập một đơn vào sổ thì sổ chặn được bằng mã đơn: dòng thứ hai bị từ chối. Gọi điện báo khách mà máy rớt giữa chừng thì sổ bó tay: không biết khách đã nghe hay chưa, sổ chỉ thấy "chưa có xác nhận", và gọi lại có thể làm khách nghe hai lần. Chỉ khi khách nhớ đã được báo đơn đó rồi thì mới hết trùng.

Những dòng của bảng ràng buộc chuẩn mà bài này dùng:

Job lặp tới trước bảng job: hai hàng cùng mô tả một tin. Trùng do timeout sinh ra sau: bảng chỉ có một job, nhưng job đó được gửi hai lần, vì trong lượt timeout có những lượt nhà cung cấp đã gửi rồi (bài 03 giả định một nửa).

Mỗi chỗ chỉ thấy một nửa: bảng job thấy mọi yêu cầu đi vào nhưng mù với mạng của nhà cung cấp, còn nhà cung cấp thấy mọi lượt gửi nhưng không biết hai yêu cầu khác id là cùng một tin nghiệp vụ.

2. Ba ứng viên khoá: mỗi khoá chặn được job lặp nào?

Khoá chống trùng là tổ hợp cột có ràng buộc duy nhất trên bảng job: yêu cầu sau cùng khoá thì chèn 0 hàng.

Mỗi khoá định nghĩa "cùng một tin" bằng thứ khác. Khoá A tin vào id do người gửi sinh, nên chỉ nhận ra trùng khi id được tái dùng. Khoá B tin vào nghĩa nghiệp vụ: "người dùng 812 nhận xác nhận đơn 55.001" chỉ tồn tại một lần, bất kể yêu cầu đi đường nào. Khoá C đoán từ bề ngoài, và đoán sai thì đắt: người chuyển 50.000đ hai lần trong một phút cho hai người bạn đáng nhận hai tin.

3. Đo trên Postgres: mỗi khoá chặn được bao nhiêu?

Lab tái hiện một giờ tin giao dịch, với giả định riêng của lab: 100.000 tin thật, trong đó 300 tin là giao dịch "sinh đôi" (cùng người, cùng số tiền, cách một phút); 2% sự kiện bị consumer xử lý lại, trễ tới 30 phút; 1% bị client gọi lại API sau 3 giây.

SELECT setseed(0.42);
CREATE TABLE msg AS
SELECT g AS order_id, (random() * 500000)::int AS user_id,
       (10 + (random() * 490)::int) * 1000 AS amount,
       timestamptz '2026-10-17 20:00+07'
         + random() * interval '1 hour' AS at
FROM generate_series(1, 99700) g;
INSERT INTO msg  -- 300 legit twins, one minute later
SELECT 99700 + order_id, user_id, amount, at + interval '1 minute'
FROM msg WHERE order_id <= 300;

CREATE TABLE req AS
SELECT gen_random_uuid() AS event_id, order_id, user_id, at,
       format('Ban vua chuyen %s d', amount) AS body
FROM msg;
INSERT INTO req  -- replay keeps event_id; API retry gets a new one
SELECT event_id, order_id, user_id,
       at + random() * interval '30 minutes', body
FROM req WHERE random() < 0.02
UNION ALL
SELECT gen_random_uuid(), order_id, user_id,
       at + interval '3 seconds', body
FROM req WHERE random() < 0.01;

Mỗi khoá là một bảng job riêng. Khoá C dùng ô 10 phút cố định, vì ràng buộc duy nhất không biểu diễn được cửa sổ trượt.

CREATE TABLE jobs_a (event_id uuid PRIMARY KEY, order_id int);
CREATE TABLE jobs_b (user_id int, kind text, order_id int,
                     PRIMARY KEY (user_id, kind, order_id));
CREATE TABLE jobs_c (user_id int, body_hash text, bucket bigint,
                     order_id int,
                     PRIMARY KEY (user_id, body_hash, bucket));
INSERT INTO jobs_a SELECT event_id, order_id FROM req ORDER BY at
ON CONFLICT DO NOTHING;
INSERT INTO jobs_b SELECT user_id, 'giao_dich', order_id FROM req
ORDER BY at ON CONFLICT DO NOTHING;
INSERT INTO jobs_c
SELECT user_id, md5(body),
       floor(extract(epoch FROM at) / 600)::bigint, order_id
FROM req ORDER BY at ON CONFLICT DO NOTHING;

Câu đo giả lập: mỗi job gửi một lần, thêm một lần khi timeout mà nhà cung cấp đã gửi.

WITH j AS (
  SELECT 'none' AS k, order_id FROM req
  UNION ALL SELECT 'A', order_id FROM jobs_a
  UNION ALL SELECT 'B', order_id FROM jobs_b
  UNION ALL SELECT 'C', order_id FROM jobs_c
), sent AS (
  SELECT k, order_id,
         1 + (random() < 0.005 AND random() < 0.5)::int AS n
  FROM j
)
SELECT k, count(*) - count(DISTINCT order_id) AS job_dups,
       sum(n) - count(*) AS timeout_dups,
       100000 - count(DISTINCT order_id) AS lost
FROM sent GROUP BY k ORDER BY k;

Lần chạy của tác giả trên Postgres 16.14, setseed(0.42) (hai seed khác chênh vài chục đơn vị):

Đáp án: 0,5% × 50% × 100.000 = 250 tin. Cột "trùng do timeout" dao động 219–265 vì mỗi dòng bốc thăm riêng; nó không đổi theo khoá.

Khoá A chặn 1.968 trên 2.983 job lặp, khoảng 66%: đúng phần consumer chạy lại. Khoá C chỉ chặn khoảng 46%, vì sự kiện chạy lại trễ hơn 10 phút rơi sang ô khác, mà còn nuốt 264 trên 300 tin sinh đôi: khoảng 53 cuộc gọi CSKH mỗi 100.000 tin.

Khoá B kéo tổng tin trùng từ 3.202 xuống 262; phần còn lại sinh ra ở chỗ khoá không nhìn tới.

4. Vì sao phần trùng do timeout chỉ thu hẹp được ở nhà cung cấp?

Khi timeout, bảng job vẫn một hàng, trạng thái vẫn "đang gửi". Thêm ràng buộc nào cũng không đổi được, vì thông tin "đã gửi" nằm trong hệ thống của người khác.

Nên phần trùng do timeout thu hẹp được tới đâu là do từng kênh quyết định:

Thời gian nhớ khoá và mã lỗi khi payload lệch khác nhau theo từng nhà cung cấp; số liệu thật nằm ở bài 06. SMS thì chịu: luồng SMS chạy ít nhất một lần thì 0,25% tin trùng, mỗi tin 700đ, là giá đã chọn ở bài 03.

POST /messages
Idempotency-Key: ______

Lời giải: khoá sinh từ job, không từ lượt gọi, ví dụ Idempotency-Key: giao_dich:812:55001. Chuỗi kind:user_id:order_id chính là khoá B, nên worker nào gửi lần thứ mấy cũng mang cùng khoá. UUID mới mỗi lượt thì nhà cung cấp gửi cả hai. Payload cũng phải y hệt vì nhà cung cấp thường từ chối cùng khoá khác payload, nên render nội dung một lần và lưu vào job.

5. Giữ khoá bao lâu, và tốn bao nhiêu?

Khoá chỉ chặn được khi hàng cũ còn trong bảng; xoá sớm thì sự kiện chạy lại muộn lọt qua. Consumer lag (thời gian một sự kiện nằm chờ trước khi được xử lý) sau sự cố tính bằng giờ, nên giữ khoá tính bằng ngày. Dung lượng thì rẻ: index khoá chính của 100.000 hàng jobs_b khoảng 4,9 MB, cỡ 50 MB mỗi triệu tin.

Dọn bằng partition theo ngày thì Postgres 16 báo unique constraint on partitioned table must include all partitioning columns. Thêm created_on vào khoá thì chạy được, nhưng sự kiện chạy lại vắt qua nửa đêm sẽ lọt. Hoặc giữ khoá trong bảng thường và xoá theo lô, hoặc partition và gọi tên phần lọt đó.

6. Bẫy hay gặp

❌ Kiểm trùng bằng SELECT rồi mới INSERT:

SELECT 1 FROM jobs_b
WHERE user_id = 812 AND kind = 'giao_dich' AND order_id = 55001;
-- 0 rows -> INSERT; two replaying consumers can both see 0 rows

✅ Một câu INSERT ... ON CONFLICT DO NOTHING trên ràng buộc duy nhất; hai consumer cùng chạy lại thì một bên chèn 0 hàng:

INSERT INTO jobs_b (user_id, kind, order_id)
VALUES (812, 'giao_dich', 55001)
ON CONFLICT DO NOTHING;
-- 0 rows inserted: the replay is dropped, no race window

❌ Sinh idempotency key mới cho mỗi lượt gọi nhà cung cấp: toàn bộ 0,25% trùng do timeout vẫn tới máy. ✅ Dẫn khoá từ job (Idempotency-Key: giao_dich:812:55001), như mục 4.

❌ Băm nội dung cho tin giao dịch "cho khỏi truyền mã đơn": nuốt 264 giao dịch thật, vẫn lọt 1.617 job lặp. ✅ Chỉ đáng cân nhắc khi tin không có mã nghiệp vụ và giá mất gần bằng 0.

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

• Bài 02: Gửi rồi đánh dấu: nguồn của số 103.202 tin ở đầu bài, và của vòng gửi mà khoá chống trùng đứng chặn phía trước.
• Bài 03: Mất hay trùng theo loại: quyết định khiến bài này tồn tại; chỉ luồng ít nhất một lần mới cần khoá chống trùng.
• Bài 05: Cách ly luồng gửi: nhà cung cấp chậm thì phần trùng do timeout tăng theo.

Tóm tắt

• Thấy tin trùng thì hỏi trước: nó sinh ra trước bảng job hay sau lời gọi nhà cung cấp? Hai nguồn cần hai cách chặn.
• Chọn khoá theo nghĩa nghiệp vụ, không theo id người gửi sinh hay bề ngoài nội dung.
• Kênh nào nhận khoá gửi kèm thì dẫn khoá từ job; phần trùng của kênh không nhận khoá thì ghi vào giá.
• Giữ khoá lâu hơn độ trễ tối đa của job lặp, kể cả consumer lag sau sự cố.

Tự kiểm tra

Bài tiếp theo: Cách ly luồng gửi: OTP không kẹt sau năm triệu tin khuyến mãi