Thiết kế tính lũy đẳng (Idempotency) và độ tin cậy của hệ thống phân tán
1. Tổng quan
A. Định nghĩa
Tính lũy đẳng (Idempotency) là tính chất mà dù một thao tác được thực hiện một lần hay lặp lại nhiều lần thì trạng thái cuối cùng của hệ thống và kết quả quan sát được cũng không thay đổi. Về mặt toán học, nó tương đương với việc hàm f thỏa mãn f(f(x)) = f(x).
Tính lũy đẳng vốn là khái niệm trong đại số, chỉ tính chất mà áp dụng lặp lại một phép toán lên một phần tử thì giá trị không đổi. Trong phần mềm, khái niệm này được mở rộng thành thuộc tính ổn định "dù gửi yêu cầu nhiều lần thì tác dụng phụ (side effect) chỉ được phản ánh một lần". Ví dụ, thao tác "đặt số dư tài khoản thành 100,000 won" dù chạy bao nhiêu lần kết quả cũng như nhau nên có tính lũy đẳng, còn thao tác "rút 10,000 won từ tài khoản" làm số dư giảm theo số lần thực thi nên không lũy đẳng.
Tính lũy đẳng thường bị nhầm với "tính an toàn (Safety)" nhưng cần phân biệt. Thao tác an toàn (ví dụ: truy vấn) hoàn toàn không thay đổi trạng thái nên tự động có tính lũy đẳng, nhưng thao tác lũy đẳng không nhất thiết an toàn. Chẳng hạn thao tác "xóa tài nguyên" thay đổi trạng thái (không an toàn) nhưng chạy hai lần thì trạng thái cuối cùng "không có tài nguyên" vẫn như nhau nên có tính lũy đẳng. Như vậy tính lũy đẳng không được định nghĩa theo "có hay không có tác dụng phụ" mà theo "ảnh hưởng của việc lặp lại lên trạng thái cuối cùng".
B. Bối cảnh ra đời và sự cần thiết
Đằng sau việc tính lũy đẳng nổi lên thành nguyên tắc cốt lõi của thiết kế hệ thống phân tán là sự bất định của mạng. Trong môi trường phân tán, khi client gửi yêu cầu tới server mà không nhận được phản hồi, client không thể phân biệt được "yêu cầu chưa tới server" hay "server đã xử lý nhưng phản hồi bị mất". Đây chính là sự bất định căn bản được hình thức hóa thành bài toán hai vị tướng (Two Generals' Problem), và không giao thức truyền thông nào có thể giải quyết hoàn toàn. Do đó client buộc phải coi là thất bại và thử lại (retry), nhưng nếu yêu cầu ban đầu đã được xử lý thì việc thử lại sẽ gây xử lý trùng lặp.
Vấn đề này đặc biệt nghiêm trọng trong các hệ thống có dòng tiền. Ví dụ trong thanh toán trực tuyến, khi người dùng bấm nút "Thanh toán" mà phản hồi trễ quá 3 giây, người dùng sẽ tải lại trang hoặc bấm lại nút. Nếu không bảo đảm tính lũy đẳng, cùng một đơn hàng bị thanh toán hai lần — tính phí kép (double charge) — dẫn thẳng đến chi phí xử lý hoàn tiền và suy giảm lòng tin của khách hàng. Thực tế, các cổng thanh toán lớn như Stripe, PayPal áp dụng khóa lũy đẳng (Idempotency-Key) do client phát hành làm header bắt buộc hoặc khuyến nghị để ngăn vấn đề này về mặt cấu trúc.
Ngoài ra, sự lan rộng của kiến trúc bất đồng bộ dựa trên message broker cũng làm tăng tầm quan trọng của tính lũy đẳng. Các hệ thống thông điệp như Kafka, RabbitMQ, AWS SQS phần lớn chọn phân phối ít nhất một lần (at-least-once delivery) làm bảo đảm mặc định vì hiệu năng và tính sẵn sàng. Điều này có nghĩa là thông điệp không bị mất nhưng có thể bị phân phối trùng, nên nếu bên tiêu thụ (consumer) không được thiết kế lũy đẳng thì cùng một sự kiện bị xử lý nhiều lần và tính nhất quán dữ liệu bị phá vỡ. Tức là tính lũy đẳng là chìa khóa thực dụng hiện thực lý tưởng "chính xác một lần (exactly-once)" bằng tổ hợp thực tế "ít nhất một lần + bên tiêu thụ lũy đẳng".
C. Mục tiêu và phạm vi áp dụng
Mục tiêu của thiết kế lũy đẳng là: thứ nhất, bảo đảm an toàn khi thử lại (yên tâm thử lại khi mạng lỗi); thứ hai, vô hại hóa yêu cầu trùng và thông điệp trùng; thứ ba, ổn định hóa việc xử lý lại khi khôi phục sự cố; thứ tư, bảo vệ trải nghiệm người dùng (ngăn tính phí kép, đơn hàng trùng). Phạm vi áp dụng bao trùm các thao tác ghi của API REST/gRPC, bên tiêu thụ thông điệp, tác vụ batch xử lý lại, xử lý bù trừ của giao dịch phân tán, và toàn bộ miền thay đổi trạng thái như thanh toán, quyết toán, trừ tồn kho. Ngược lại, với các thao tác không có tác dụng phụ hoặc vốn đã lũy đẳng như truy vấn thuần túy hay tổng hợp luồng thì gánh nặng thiết kế riêng không lớn.
2. Các loại tính lũy đẳng và tiêu chí đánh giá
A. Tính lũy đẳng của bản thân thao tác
Hình thức lý tưởng nhất là khi định nghĩa của thao tác tự thân đã lũy đẳng.
"Đặt giá trị trường thành X (SET)" hoặc "thêm phần tử vào tập hợp (phép toán tập hợp lũy đẳng)" lặp lại thì kết quả vẫn như nhau.
Trong cơ sở dữ liệu, dùng INSERT ... ON CONFLICT DO UPDATE (UPSERT) hoặc cập nhật có điều kiện có thể tạo nên thao tác ghi lũy đẳng một cách tự nhiên.
Ngược lại, các thao tác tương đối (relative) như "tăng bộ đếm (INCREMENT)", "trừ số dư", "append vào danh sách" về bản chất không lũy đẳng nên cần cơ chế chống trùng riêng.
Sự phân biệt này rất quan trọng ở giai đoạn thiết kế API. Nếu có thể, thiết kế lại thao tác tương đối thành thao tác tuyệt đối (absolute) là giải pháp căn bản. Ví dụ, thay yêu cầu "giảm tồn kho 3 đơn vị" bằng thao tác tuyệt đối có điều kiện (Compare-And-Set) "đặt tồn kho thành 47 chỉ khi giá trị hiện tại là 50", thì dù thử lại, điều kiện không khớp nên không bị phản ánh hai lần. Như vậy, bảo đảm tính lũy đẳng ở cấp mô hình hóa miền nghiệp vụ có thể giảm độ phức tạp của tầng hạ tầng.
B. Quy ước lũy đẳng của phương thức HTTP
Chuẩn web (RFC 9110) quy định rõ tính lũy đẳng và tính an toàn theo từng phương thức HTTP. Quy ước này là căn cứ để proxy, bộ đệm, trình duyệt, thư viện client quyết định có tự động thử lại yêu cầu thất bại hay không, nên người thiết kế API phải tuân thủ chính xác. Bảng dưới đây tổng hợp tính chất của các phương thức chính, và "vì sao" mỗi tính chất được quy định như vậy được giải thích bằng ảnh hưởng của việc lặp lại tác dụng phụ.
| Phương thức | An toàn (Safe) | Lũy đẳng (Idempotent) | Giải thích |
|---|---|---|---|
| GET | O | O | Chỉ truy vấn nên không thay đổi trạng thái |
| HEAD | O | O | Chỉ truy vấn header |
| PUT | X | O | Thay thế toàn bộ (nghĩa SET) nên lặp lại vẫn cùng trạng thái |
| DELETE | X | O | Xóa lặp lại vẫn hội tụ về trạng thái "không có" |
| POST | X | X | Tạo tài nguyên (nghĩa append) — lặp lại sẽ tạo trùng |
| PATCH | X | △ | Tùy hiện thực (cập nhật tuyệt đối thì lũy đẳng, cập nhật tương đối thì không) |
Ở đây, việc POST được quy định là không lũy đẳng chính là thách thức cốt lõi trong thực tiễn.
Bởi vì phần lớn các thao tác "tạo" như tạo đơn hàng, yêu cầu thanh toán, đăng bình luận đều được hiện thực bằng POST.
Vì vậy để POST có tính lũy đẳng, chỉ quy ước giao thức là không đủ mà phải đưa vào cơ chế ở tầng ứng dụng như khóa lũy đẳng sẽ trình bày sau.
PATCH có điều kiện (△) cũng vì lý do tương tự: chỉ định giá trị tuyệt đối như {"balance": 100} thì lũy đẳng, còn chỉ định gia số như {"balance": "+10"} thì không.
C. Quan hệ giữa ngữ nghĩa phân phối và tính lũy đẳng
Bảo đảm phân phối thông điệp chia thành ba loại chính, và tính lũy đẳng đóng vai trò cây cầu nâng bảo đảm "ít nhất một lần" thành "chính xác một lần" trên thực chất.
graph LR
subgraph DS["Ngữ nghĩa phân phối"]
A["Nhiều nhất một lần (at-most-once)<br/>có thể mất, không trùng"]
B["Ít nhất một lần (at-least-once)<br/>không mất, có thể trùng"]
C["Chính xác một lần (exactly-once)<br/>lý tưởng nhưng chi phí cao"]
end
B -->|"Kết hợp bên tiêu thụ lũy đẳng"| D["Hiệu quả chính xác một lần<br/>(effectively-once)"]
C -.->|"Hiện thực thực tế"| D
A -.->|"Thiếu độ tin cậy"| E["Phần lớn không phù hợp"]
Như hình trên cho thấy, phân phối "chính xác một lần" thuần túy trong môi trường phân tán cực kỳ đắt đỏ (commit hai pha…) hoặc gần như bất khả thi. Vì vậy phần lớn các hệ thống trưởng thành đạt hiệu quả chính xác một lần trên thực tế (effectively-once) bằng tổ hợp "phân phối ít nhất một lần + bên tiêu thụ lũy đẳng". Ví dụ, Kafka cung cấp tính lũy đẳng phía producer (enable.idempotence) và chức năng giao dịch, nhưng khi ứng dụng consumer tạo tác dụng phụ lên hệ thống bên ngoài (DB, API thanh toán) thì rốt cuộc vẫn cần xử lý lũy đẳng ở cấp bên tiêu thụ. Đây là nơi ngộ nhận "hạ tầng sẽ bảo đảm tính lũy đẳng thay cho ta" bị phá vỡ: ngay khi vượt qua ranh giới của tác dụng phụ, ứng dụng phải chịu trách nhiệm.
3. Kiến trúc hiện thực và quy trình
A. Xử lý dựa trên khóa lũy đẳng (Idempotency-Key)
Phương pháp chuẩn để biến thao tác vốn không lũy đẳng như POST thành lũy đẳng là client gán một khóa lũy đẳng duy nhất cho mỗi yêu cầu, và server xác định trùng lặp dựa trên khóa này. Client giữ nguyên cùng một khóa kể cả khi thử lại đối với "cùng một lần thử" về mặt logic, và phát hành khóa mới (ví dụ: UUID v4) cho "lần thử mới". Server ghi khóa và kết quả xử lý vào kho lưu trữ, khi cùng khóa đến lần nữa thì bỏ qua xử lý thực tế và trả nguyên kết quả đã lưu.
Dưới đây là luồng điển hình của xử lý khóa lũy đẳng.
flowchart TD
S["Nhận yêu cầu<br/>(kèm Idempotency-Key)"] --> Q{"Khóa đã tồn tại<br/>trong kho lưu trữ?"}
Q -->|"Không"| L["Chiếm giữ nguyên tử khóa ở trạng thái 'đang xử lý'<br/>(INSERT, ràng buộc duy nhất)"]
L --> P["Thực hiện logic nghiệp vụ thực tế"]
P --> R["Lưu kết quả và phản hồi vào khóa<br/>(đổi trạng thái thành 'hoàn tất')"]
R --> OUT["Trả phản hồi"]
Q -->|"Có: hoàn tất"| CACHE["Trả nguyên phản hồi đã lưu"]
Q -->|"Có: đang xử lý"| WAIT["409/gợi ý thử lại hoặc chờ"]
CACHE --> OUT
WAIT --> OUT
Điều quan trọng mang tính quyết định trong luồng này là "chiếm giữ khóa" phải mang tính nguyên tử.
Trong điều kiện tranh chấp (race condition) khi hai yêu cầu cùng khóa đến gần như đồng thời, phải dùng ràng buộc duy nhất (unique constraint) của cơ sở dữ liệu hoặc INSERT ... ON CONFLICT để chỉ một yêu cầu chiếm giữ thành công.
Yêu cầu chiếm giữ thất bại sẽ chờ xử lý đang diễn ra hoặc phản hồi 409 Conflict để client truy vấn lại sau ít phút.
Nếu thiếu tính nguyên tử này, các yêu cầu trùng đồng thời đều thực hiện logic thực tế và tính lũy đẳng sụp đổ.
Ngoài ra, khóa và kết quả đã lưu không thể giữ vô hạn nên cần đặt thời hạn lưu giữ (TTL). Cổng thanh toán thường đặt TTL từ 24 giờ đến vài ngày, chỉ xử lý lũy đẳng các lần thử lại trong khoảng đó, sau đó coi là yêu cầu mới. TTL quá ngắn thì có rủi ro lần thử lại bị trễ bị xử lý trùng, quá dài thì chi phí lưu trữ và khả năng xung đột khóa tăng, nên cần cân bằng theo đặc tính thử lại của miền nghiệp vụ.
B. Loại bỏ trùng lặp bằng khóa tự nhiên, khóa nghiệp vụ
Ngay cả không có khóa lũy đẳng riêng, vẫn có thể ngăn trùng lặp bằng cách lấy các thuộc tính phải duy nhất về mặt nghiệp vụ làm ràng buộc. Ví dụ, nếu cưỡng chế quy tắc "với cùng một mã đơn hàng chỉ được tồn tại một giao dịch thanh toán" bằng chỉ mục duy nhất (order_id UNIQUE) trên bảng thanh toán, yêu cầu thanh toán trùng sẽ bị từ chối ở cấp cơ sở dữ liệu. Ở bên tiêu thụ thông điệp cũng vậy, bảo đảm tính lũy đẳng bằng cách ghi ID duy nhất của thông điệp (event_id) một cách duy nhất vào bảng "nhật ký đã xử lý", nếu đã tồn tại thì bỏ qua.
Cách này có ưu điểm là đơn giản vì có thể hiện thực chỉ bằng ràng buộc của mô hình dữ liệu hiện có mà không cần hạ tầng riêng. Tuy nhiên khi tác dụng phụ trải trên nhiều kho lưu trữ hoặc hệ thống bên ngoài thì khó bảo vệ toàn bộ chỉ bằng một ràng buộc duy nhất. Trong trường hợp đó cần song song dùng kho lũy đẳng riêng ghi trạng thái xử lý và mẫu transactional outbox gói tác dụng phụ vào một giao dịch cục bộ.
C. Bên tiêu thụ lũy đẳng và ổn định hóa xử lý lại
Trong pipeline bất đồng bộ, bên tiêu thụ phải kiểm tra trước "thông điệp này đã được xử lý chưa" rồi mới thực hiện tác dụng phụ. Hình thức vững chắc nhất là commit việc lưu tạo tác dụng phụ và "đánh dấu đã xử lý" trong cùng một giao dịch. Ví dụ, gói việc trừ tồn kho và ghi event_id vào một giao dịch DB, thì dù sự cố xảy ra sau xử lý nhưng trước khi phản hồi (ack) khiến thông điệp được phân phối lại, lần xử lý thứ hai sẽ bị bỏ qua do trùng event_id. Lúc này nếu lưu tác dụng phụ và đánh dấu hoàn tất nằm ở hai giao dịch khác nhau, khi sự cố xảy ra ở giữa thì tác dụng phụ đã phản ánh nhưng chưa đánh dấu hoàn tất, dẫn đến trùng lặp khi xử lý lại, nên thiết lập ranh giới nguyên tử là cốt lõi.
4. So sánh với các khái niệm tương tự
Tính lũy đẳng được dùng cùng với nhiều khái niệm liên quan đến tính nhất quán nên cần làm rõ sự khác biệt. Bảng dưới đây là phần so sánh, kèm theo giải thích bằng văn xuôi về lý do tạo nên khác biệt và hàm ý thực tiễn.
| Phân loại | Trọng tâm | Hiệu quả khi lặp lại | Kỹ thuật tiêu biểu |
|---|---|---|---|
| Tính lũy đẳng (Idempotency) | Trạng thái cuối cùng giống nhau khi thực hiện lặp lại | Chỉ phản ánh một lần | Khóa lũy đẳng, UPSERT |
| Tính nguyên tử (Atomicity) | Thao tác thực hiện toàn bộ hoặc không gì cả | Ngăn phản ánh một phần | Giao dịch, 2PC |
| Tính nhất quán (Consistency) | Duy trì quy tắc, bất biến | — | Ràng buộc, kiểm tra |
| Chính xác một lần (Exactly-once) | Kiểm soát số lần phân phối, xử lý | Xử lý đúng 1 lần | Ít nhất một lần + lũy đẳng |
Tính lũy đẳng và tính nguyên tử thường được nhắc cùng nhau nhưng giải quyết các vấn đề khác nhau. Tính nguyên tử xử lý "một thao tác có hoàn tất mà không có trạng thái trung gian hay không", còn tính lũy đẳng xử lý "thao tác đã hoàn tất có được lặp lại nhiều lần hay không". Trong thực tế phải kết hợp cả hai mới an toàn; ví dụ gói việc chiếm giữ khóa lũy đẳng và xử lý nghiệp vụ vào một giao dịch (tính nguyên tử) để dù thử lại cũng không bị trùng (tính lũy đẳng).
"Chính xác một lần" là mục tiêu lý tưởng, nhưng như đã giải thích, đạt được một cách thuần túy thì chi phí lớn. Vì vậy trong thực tế, câu "hỗ trợ exactly-once" chính xác hơn nên được hiểu là "bọc phân phối ít nhất một lần bằng xử lý lũy đẳng để tạo hiệu quả một lần trên thực tế". Nếu không hiểu khác biệt diễn giải này, rất dễ phán đoán sai rằng chỉ cần cấu hình hạ tầng là trùng lặp sẽ biến mất.
5. Chuyên sâu: Tình huống áp dụng thực tiễn và xu hướng mới nhất
A. Chuẩn hóa khóa lũy đẳng của cổng thanh toán
Từ khoảng năm 2017, Stripe đưa header Idempotency-Key vào mọi API ghi, để khi client tạo và gửi UUID thì việc thử lại do lỗi mạng không dẫn tới tính phí trùng.
Theo tài liệu công khai của Stripe, khóa này mặc định được lưu trong 24 giờ, và khi yêu cầu lại với cùng khóa thì phản hồi đầu tiên (bao gồm mã trạng thái HTTP) được tái hiện nguyên vẹn.
Nhờ thiết kế này, SDK phía client có thể thử lại an toàn với backoff lũy thừa khi gặp lỗi 5xx hoặc timeout, còn server bảo đảm thanh toán được phản ánh chính xác một lần.
Tại Hàn Quốc, trong tích hợp thanh toán của các công ty PG, Open Banking, Toss, KakaoPay…, cơ chế chống trùng dựa trên mã giao dịch duy nhất (transaction ID) cũng vận hành theo nguyên lý thực chất giống hệt.
B. Tăng cường hỗ trợ lũy đẳng trên các nền tảng đám mây và nhắn tin
Apache Kafka từ phiên bản 0.11 cung cấp tính lũy đẳng của producer (enable.idempotence=true) và API giao dịch, loại bỏ thông điệp trùng do broker thử lại bằng số thứ tự của producer.
AWS: trong khi hàng đợi chuẩn của SQS bảo đảm phân phối ít nhất một lần, hàng đợi FIFO có cửa sổ loại bỏ trùng lặp (deduplication) 5 phút để hỗ trợ loại trùng dựa trên message ID.
Bước sang 2023–2024, khi kiến trúc serverless và hướng sự kiện lan rộng, hỗ trợ ở cấp framework như tiện ích lũy đẳng của AWS Lambda (Powertools Idempotency) — lưu đệm kết quả thực thi hàm theo khóa để ngăn thực thi lại — cũng đang được chuẩn hóa.
Tuy nhiên các chức năng hạ tầng này thường chỉ có hiệu lực trong ranh giới nội bộ của nền tảng mình, nên tính lũy đẳng ở thời điểm tác dụng phụ vượt sang hệ thống thanh toán, quyết toán bên ngoài vẫn là trách nhiệm của ứng dụng.
C. Hướng ra đề dự kiến và chiến lược cấu trúc bài làm
Từ góc nhìn Kỹ sư chuyên nghiệp Quản lý Thông tin, tính lũy đẳng nhiều khả năng được ra đề như một thành phần con của "phương án bảo đảm độ tin cậy cho giao dịch phân tán, microservice" hơn là giải thích thuật ngữ đơn lẻ. Trong bài làm, cấu trúc thuyết phục là: ① trước hết xác lập định nghĩa tính lũy đẳng và phân biệt với tính an toàn, tính nguyên tử; ② dựa trên quy ước phương thức HTTP và ngữ nghĩa phân phối để nêu tình huống vấn đề (yêu cầu trùng, thông điệp trùng); ③ triển khai các tầng hiện thực gồm khóa lũy đẳng, khóa tự nhiên, bên tiêu thụ lũy đẳng kèm hình vẽ; ④ củng cố tính hiệu quả bằng tình huống thanh toán, nhắn tin. Đặc biệt nếu đề cập liên kết với "thử lại, timeout, circuit breaker, mẫu outbox" thì bài làm trở thành bài chuyên sâu bao quát toàn bộ thiết kế khả năng phục hồi.
6. Lưu ý và hàm ý
Thứ nhất, tính lũy đẳng phải được thiết kế như trách nhiệm của tầng miền nghiệp vụ/ứng dụng chứ không phải của hạ tầng. Việc loại trùng do message broker hay đám mây cung cấp chỉ có hiệu lực trong ranh giới của chúng, và ngay khi tác dụng phụ mở rộng sang hệ thống bên ngoài (thanh toán, quyết toán, gửi email), ứng dụng phải tự quản lý khóa lũy đẳng và trạng thái xử lý. Khi rà soát kiến trúc cần chiến lược nhận diện "ranh giới tác dụng phụ" và bố trí cơ chế lũy đẳng tại mỗi điểm đó.
Thứ hai, phải quản lý sự đánh đổi giữa tính lũy đẳng với hiệu năng và chi phí lưu trữ. Lưu và truy vấn khóa cùng kết quả của mọi yêu cầu sẽ phát sinh độ trễ bổ sung và tải cho kho lưu trữ. Với API lưu lượng lớn, cần phân tầng bộ đệm trong bộ nhớ (Redis) và kho lưu trữ bền vững, kiểm soát chi phí lưu trữ bằng TTL và phân vùng, đồng thời xác định thời hạn lưu giữ phù hợp đặc tính miền để các yêu cầu trễ vượt thời hạn thử lại hợp lệ không bị xử lý trùng.
Thứ ba, bảo đảm tính đồng thời và tính nguyên tử quyết định thành bại của tính lũy đẳng. Trong điều kiện tranh chấp của các yêu cầu song song cùng khóa, nếu việc chiếm giữ khóa không nguyên tử thì tính lũy đẳng sụp đổ. Cần chọn cơ chế chiếm giữ nguyên tử phù hợp miền giữa ràng buộc duy nhất, INSERT có điều kiện, khóa phân tán, và thiết kế gói tác dụng phụ cùng đánh dấu hoàn tất trong một ranh giới giao dịch là bắt buộc. Tại điểm này, việc kết hợp với mẫu transactional outbox, mẫu Saga được đòi hỏi một cách tự nhiên.
Thứ tư, phải tiếp cận từ góc nhìn tích hợp với các mẫu khả năng phục hồi. Tính lũy đẳng là tiền đề để thử lại (retry) an toàn, và chỉ khi được thiết kế cùng timeout, backoff lũy thừa, circuit breaker mới tạo thành hệ thống ứng phó sự cố hoàn chỉnh. Nếu đưa vào thử lại mà không bảo đảm tính lũy đẳng thì ngược lại còn khuếch đại tác dụng phụ trùng lặp, nên hai kỹ thuật này nhất định phải được xem xét thành cặp.
Thứ năm, phải kiểm chứng tính lũy đẳng bằng khả năng quan sát (Observability) và kiểm thử. Lỗi lũy đẳng không lộ ra trong luồng bình thường mà chỉ xuất hiện khi thử lại hoặc có sự cố, nên cần liên tục kiểm chứng hành vi thực tế qua kiểm thử bơm yêu cầu trùng (chaos test) và giám sát chỉ số xử lý khóa (số lần phát hiện trùng, tỷ lệ trúng bộ đệm). Chỉ review mã thì dễ bỏ sót điều kiện tranh chấp, nên kiểm thử đồng thời trong tình huống tải đặc biệt quan trọng.
Tài liệu tham khảo
- Stripe API Docs, "Idempotent requests": https://docs.stripe.com/api/idempotent_requests
- RFC 9110, "HTTP Semantics" (Method properties: Safe/Idempotent): https://www.rfc-editor.org/rfc/rfc9110
- Apache Kafka Documentation, "Idempotent Producer / Transactions": https://kafka.apache.org/documentation/#semantics
- AWS, "Amazon SQS FIFO queues — message deduplication": https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html
Tóm tắt một câu: Tính lũy đẳng là tính chất mà thực hiện cùng một thao tác nhiều lần thì trạng thái cuối cùng không đổi, là nguyên tắc cốt lõi về độ tin cậy của hệ thống phân tán giúp vô hại hóa việc thử lại và thông điệp trùng trong môi trường mạng bất định và phân phối ít nhất một lần, hiện thực "chính xác một lần trên thực tế" bằng khóa lũy đẳng, khóa tự nhiên, bên tiêu thụ lũy đẳng và thiết kế chiếm giữ nguyên tử.