Tổng kết case thông báo: thiết kế hoàn chỉnh và các cái giá

TL;DR: Thiết kế gửi thông báo hoàn chỉnh của case có ba quyết định, mỗi quyết định đứng ở một chặng trên đường đi của một tin. Ở cửa bảng job, ràng buộc duy nhất trên khoá (người dùng, loại, mã nghiệp vụ) chặn job lặp. Ở chỗ worker nhặt job, OTP có sàn 60 worker riêng và được mượn pool chung. Quanh lượt gọi nhà cung cấp, vị trí COMMIT quyết định mức giao nhận: OTP và tin giao dịch gửi ít nhất một lần, tin khuyến mãi gửi tối đa một lần. Phần còn lại không xoá được: khoảng 0,25% lượt gửi vẫn mất hoặc trùng, tuỳ loại, vì nhà cung cấp SMS không chống trùng.

Bạn bắt đầu case bằng hai khiếu nại ngược chiều sau một tối thứ Sáu: "tôi nhận một tin khuyến mãi ba lần" và "tôi không nhận được mã OTP". Sáu bài sau, hai khiếu nại đó đã có số, có nguồn và có giá. Bài này không dạy thêm cơ chế nào. Việc của nó là ráp các mảnh lại, gom cái giá vào một bảng, rồi để bạn tự kiểm xem đổi một ràng buộc thì quyết định nào lật.

1. Ráp thành một thiết kế

Hình dung một bưu cục nhận hàng gửi đi qua hãng xe bên ngoài. Bưu cục kiểm soát được quầy nhận, các làn xếp hàng và cuốn sổ của mình, nhưng không kiểm soát được hãng xe:

Đi theo đường của một tin, từ ngoài vào trong. Yêu cầu gửi tới từ API hoặc từ consumer xử lý sự kiện, và được chèn vào bảng jobs bằng INSERT ... ON CONFLICT DO NOTHING trên khoá (người dùng, loại, mã nghiệp vụ). Job lặp, dù do client gọi lại API hay consumer chạy lại sự kiện, chèn 0 hàng (bài 04). Worker nhặt job bằng FOR UPDATE SKIP LOCKED: 60 worker chỉ nhận OTP, 1.140 worker còn lại nhặt theo ORDER BY priority, id nên OTP vẫn được ưu tiên khi cần mượn (bài 05). Trước khi gọi nhà cung cấp, worker đọc bảng notif_type để biết COMMIT đứng ở đâu: khuyến mãi đánh dấu trước rồi mới gọi, OTP và tin giao dịch gọi trước rồi mới đánh dấu (bài 03). Gặp timeout, job ít nhất một lần quay về hàng kèm thời điểm chạy lại, giữ nguyên khoá và nội dung.

Vì sao ba quyết định tách được thành ba trục? Vì mỗi trục trả lời một câu hỏi mà hai trục kia không chạm tới. Khoá chống trùng hỏi "hai yêu cầu này có phải cùng một tin không", cách ly hỏi "tin này chờ sau ai", còn mức giao nhận hỏi "khi không biết kết quả thì sai về phía nào". Vòng gửi ngây thơ của bài 02 gộp cả ba vào một vòng lặp và trả lời cả ba bằng mặc định: không khoá, chung một hàng, thử lại mọi thứ.

2. Bảng cái giá bạn đã chấp nhận

Cột "lựa chọn" chỉ đúng dưới ràng buộc chuẩn của case. Đừng mang nó đi như khuyến nghị chung.

Đọc theo hàng ngang, cái giá nào cũng có một con số đứng sau. Có người hỏi "sao không gửi lại mọi thứ cho chắc" thì chỉ vào hàng bài 03: 25.000 lượt mập mờ mỗi đợt, khoảng 12.500 người nhận tin khuyến mãi hai lần, và khoảng 25.000 lượt gọi thêm dồn vào nhà cung cấp đúng lúc nó đang chậm.

Hàng bài 04 cần đọc kèm một chú thích. Khoá chống trùng chỉ thấy những gì đi qua cửa bảng job, nên phần trùng do timeout không giảm theo khoá nào. Phần đó chỉ thu hẹp được ở chặng nhà cung cấp, và bài 06 cho thấy đó là điều khoản hợp đồng (Resend nhớ khoá 24 giờ).

3. Chỗ ba trục chạm nhau: lượt thử lại

Ba trục độc lập, trừ một chỗ. Luồng ít nhất một lần sinh ra lượt thử lại, và lượt thử lại tiêu tốn worker, đúng tài nguyên mà trục cách ly đang chia. Thử lại ngay trong worker, ngủ backoff 1, 2, 4 giây, thì khi push treo mỗi job giữ worker tới 15 giây, và OTP chạy trên worker mượn có thể chờ ngần ấy (bài 05).

Lỗi hay tái phạm nhất khi ráp ba trục lại là viết một chính sách thử lại chung cho mọi loại tin:

-- moi loai cung mot luat: timeout thi thu lai, toi da 3 lan
UPDATE jobs SET status = 'pending', attempts = attempts + 1
WHERE id = :job_id AND attempts < 3;

Câu này gửi lại cả tin khuyến mãi (đẩy 0,25% mập mờ về đúng phía đắt hơn), và gửi lại OTP cả khi mã đã quá hạn 15 giây. Bản đúng đọc notif_type, trả job về hàng kèm run_after để worker nhả ngay:

UPDATE jobs j SET status = 'pending', attempts = j.attempts + 1,
       run_after = clock_timestamp() + interval '2 seconds'
FROM notif_type t
WHERE j.id = :job_id AND t.code = j.kind
  AND t.delivery = 'at_least_once'
  AND j.attempts < t.max_tries
  AND (t.deadline IS NULL
       OR j.created_at + t.deadline > clock_timestamp());

Chạy trên PostgreSQL 16.14 với bốn job đang sending, câu này chỉ đưa đúng một job về hàng: OTP tạo 3 giây trước. Tin khuyến mãi, OTP đã quá 15 giây và tin giao dịch hết 5 lượt đều đứng yên, nên worker phải có một câu tiếp theo đánh chúng sang failed. Bỏ câu đó là tái tạo đúng ô kẹt sending của bài 02.

4. Đổi ràng buộc, quyết định nào đổi?

Ba tình huống dưới đây mỗi cái đổi một dòng của bảng ràng buộc. Tự viết câu trả lời trước khi mở đáp án mẫu: trục nào lật, trục nào giữ nguyên, và con số nào chứng minh.

Đào sâu

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

• Bài 06: Đối chiếu thực tế: hệ thống thật chọn khác bạn vì ràng buộc của họ khác. Bảng cái giá ở mục 2 là công cụ để làm phép so đó.
• Bài 01: Ràng buộc và ước lượng: nơi mọi con số trong bảng bắt đầu.

Tóm tắt

• Khi thiết kế một hệ gửi qua nhà cung cấp ngoài, tách ba câu hỏi ra ba chặng: cùng một tin hay không, chờ sau ai, sai về phía nào.
• Khi có người đề xuất một luật thử lại chung, hỏi lại giá mất và giá trùng của từng loại tin.
• Khi một ràng buộc đổi, đổi đúng dòng đó trong bảng rồi xem trục nào lật, đừng thiết kế lại từ đầu.

✅ Self-assessment

• Ước lượng số lượt gửi mỗi giây theo loại, số lượt gửi mập mờ do timeout và cái giá của một tin mất so với một tin trùng từ bảng ràng buộc tự đặt, rồi so tải đỉnh với trần ghi job đo trên máy mình
  • Nếu chưa: đọc lại bài 01, mục 4 (phần đuôi sau timeout) và mục 5 (bảng giá).
• Chẩn đoán được nguồn sinh tin trùng (timeout rồi retry) và tin mất (kẹt trạng thái đang gửi, hết lượt retry) trong vòng nhận job, gọi nhà cung cấp rồi đánh dấu xong
  • Nếu chưa: đọc lại bài 02, mục 3 và mục 4.
• Chọn giữa gửi tối đa một lần và gửi ít nhất một lần cho từng loại thông báo bằng cách so tỉ lệ mất nhân giá mất với tỉ lệ trùng nhân giá trùng
  • Nếu chưa: đọc lại bài 03, mục 5 và điều kiện q / (1 − q).
• Thiết kế khoá chống trùng chặn job lặp phía mình, kèm ranh giới của nó: phần trùng do timeout nằm ngoài tầm khoá đó và chỉ thu hẹp được bằng khoá gửi kèm nhà cung cấp
  • Nếu chưa: đọc lại bài 04, mục 3 (số đo ba khoá) và mục 4 (khoá gửi kèm).
• Thiết kế cách ly luồng gửi theo loại để OTP vẫn tới trong hạn khi một trong hai nhà cung cấp (push hoặc SMS) chậm giữa đợt gửi khuyến mãi
  • Nếu chưa: đọc lại bài 05, mục 6 (bảng ba kịch bản).
• Biện luận vì sao một hệ thống thông báo thật chọn khác thiết kế của bạn dựa trên ràng buộc của họ
  • Nếu chưa: đọc lại bài 06, mục 6 (bảng tổng hợp theo chặng).

Bài tiếp theo

Case thông báo khép lại ở đây. Muốn đào sâu hai nguyên lý cả case đứng trên, đọc lại Mạng không tin cậy trong khoá Phân tán, nơi timeout chỉ là phỏng đoán, và Stream join và exactly-once trong khoá Dữ liệu phái sinh, nơi exactly-once chỉ đứng được khi mọi bên cùng hợp tác.