Stripe ghi nhớ yêu cầu của bạn khi phản hồi biến mất

Nội dung video này đề cập

• Tính bất biến liên quan đến hiệu ứng dự kiến của việc lặp lại một thao tác. API Stripe v1 bổ sung một hợp đồng phát lại phản hồi đã lưu được ghi lại.
• Việc thử lại cùng một hành động logic sử dụng cùng khóa và tham số. Duy trì khóa thao tác trên các lệnh gọi SDK riêng biệt hoặc các lần khởi động lại ứng dụng; một hành động thực sự mới cần có khóa riêng.
• Sau khi quá trình thực thi điểm cuối bắt đầu, API Stripe v1 sẽ lưu trạng thái và nội dung của yêu cầu đầu tiên, bao gồm lỗi 500, và trả về phản hồi đã lưu đó khi thử lại.
• Các tham số đã thay đổi với cùng một khóa sẽ tạo ra sự không khớp. Lỗi xác thực và xung đột thực thi đồng thời không lưu trữ kết quả bất biến nào cho lần thử đó và có thể được thử lại.
• Stripe lưu giữ các khóa API v1 trong ít nhất 24 giờ và có thể xóa chúng sau đó. Giới hạn các lần thử lại mạng chưa được giải quyết trong 24 giờ đầu tiên, sau đó dừng lại và đối chiếu trước khi lặp lại thao tác.
• Lỗi 500 được lưu trong bộ nhớ cache có thể tiếp tục phát lại sau khi kết nối được phục hồi. Thao tác ban đầu có thể có tác dụng phụ; hãy sử dụng đối tượng có liên quan, yêu cầu Dashboard và webhooks để xác định kết quả của nó.
• API v2 sử dụng ngữ nghĩa phát lại khác. Khóa không thiết lập việc phân phối chính xác một lần chung cho email, hàng tồn kho và mọi thao tác cơ sở dữ liệu cục bộ.

Bản ghi đã dịch

Được dịch từ lời tường thuật tiếng Anh gốc. Âm thanh và phụ đề có sẵn được điều khiển bởi YouTube.

Lỗi thời gian chờ có hủy thanh toán của bạn không?

0:00 Bạn nghĩ lỗi thời gian chờ có nghĩa là khoản thanh toán của bạn đã thất bại. Máy chủ có thể hoàn tất trong khi phản hồi biến mất, khiến trang thanh toán của bạn tự tin hiển thị hoàn toàn không có gì. Tại sao việc thử lại có thể tính phí lần nữa? Stripe ghi nhớ một lần thử như thế nào? Khi nào bạn nên ngừng thử lại? Và hãy ghi nhớ một chi tiết khó chịu. Một lỗi đã ghi nhớ có thể tồn tại lâu hơn sự cố mạng.

0:17 Chúng ta sẽ quay lại vấn đề đó. Đây là The Daily Diff, dưới mui xe.

Khóa bất biến xác định điều gì?

0:21 Tính bất biến có nghĩa là việc lặp lại một thao tác có cùng hiệu ứng dự kiến như việc thực hiện nó một lần. Một khóa bất biến gắn nhãn một hành động logic. API phiên bản một của Stripe nhận dạng nhãn đó trên các lần thử lại và phát lại một phản hồi đã lưu. Hãy hình dung việc mua một ly cà phê. Stripe hoàn tất yêu cầu thanh toán của bạn và phản hồi bị mất khi quay lại trang chủ. Khách hàng nhìn thấy một biểu tượng quay. Ngân hàng của họ có thể có một cách giải thích thú vị hơn. Một yêu cầu tạo không được bảo vệ có thể lặp lại tác dụng phụ.

Làm cách nào để cùng một khóa giúp thử lại an toàn?

0:45 Đính kèm một khóa duy nhất trước lần thử đầu tiên và giữ nó cho các lần thử lại. Nếu ứng dụng của bạn khởi động lại, hãy bảo toàn khóa đó với thao tác trong hồ sơ của bạn. Đối với API phiên bản một của Stripe, một khi quá trình thực thi điểm cuối bắt đầu, trạng thái và nội dung của yêu cầu đầu tiên được lưu. Gửi cùng khóa và tham số một lần nữa, và Stripe trả về phản hồi đã lưu. Ly cà phê vẫn giữ nguyên vị trí trong khi biên lai của nó lại được gửi đi.

Stripe lưu chính xác những gì?

1:07 Đây là cách diễn đạt thực tế của Stripe. Các lần thử lại với cùng khóa sẽ trả về phản hồi đã lưu, bao gồm cả lỗi năm trăm. Tài liệu thực hiện nhiều việc hơn là trình trợ giúp thử lại được đặt tên đầy lạc quan của bạn. Khách hàng chạm lại. Ứng dụng của bạn quyết định xem điều đó tiếp tục giao dịch mua đang chờ xử lý hay bắt đầu một giao dịch khác. Một ly cà phê thực sự mới sẽ có một khóa mới. Một khóa mới cho mỗi lần thử lại mạng sẽ làm mất tác dụng bảo vệ.

1:27 Các tham số khác nhau với cùng một khóa sẽ gây ra sự không khớp.

Điều gì xảy ra khi yêu cầu thay đổi?

1:30 Nếu các tham số không vượt qua quá trình xác thực, hoặc một yêu cầu khác với khóa đó vẫn đang được thực thi, Stripe không lưu trữ kết quả bất biến nào cho lần thử đó. Những yêu cầu đó có thể được thử lại. Một yêu cầu chạy đua sẽ gặp xung đột. Đây là các quy tắc của phiên bản một. Phiên bản hai hoạt động khác. Một tiêu đề không thể hứa hẹn việc phân phối chính xác một lần trên toàn hệ thống của bạn. Email, hàng tồn kho và cơ sở dữ liệu của bạn đều cần xử lý lỗi.

1:52 Khóa bảo vệ thao tác trong phạm vi được ghi lại của nó. Stripe lưu giữ các khóa phiên bản một trong ít nhất hai mươi bốn giờ và có thể xóa

Kết quả đã ghi nhớ an toàn để thử lại trong bao lâu?

1:59 chúng sau đó. Một khóa đã bị xóa có thể thực thi một yêu cầu mới. Giữ các lần thử lại chưa được giải quyết trong ngày đầu tiên. Ngoài ra, hãy dừng lại và đối chiếu kết quả ban đầu. Sử dụng chế độ lùi lũy thừa và rung để máy chủ có không gian thở. Nếu không, các lần thử lại sẽ tạo thành một hàng đợi bên ngoài một quán cà phê đang cháy. Các thư viện của Stripe xử lý các lần thử lại, nhưng hãy kiểm tra các cài đặt mặc định của thư viện của bạn. Lỗi khó chịu đó chính là điểm mấu chốt.

Tại sao lỗi đã ghi nhớ có thể tiếp tục quay lại?

2:20 Một phản hồi năm trăm được lưu trong bộ nhớ cache tiếp tục phát lại sau khi kết nối được phục hồi. Thao tác ban đầu có thể đã tạo ra tác dụng phụ. Giải quyết kết quả của nó bằng cách sử dụng các đối tượng, Dashboard và webhooks. Một khóa mới có thể lặp lại hành động. Nếu bạn muốn đọc điều này hơn là nghe tôi nói, the diff sẽ đến hộp thư đến của bạn mỗi sáng, miễn phí tại the daily diff dot dev, liên kết bên dưới.

Tôi có nên đưa một nút thử lại với hợp đồng này không?

2:39 Phán quyết, dưới mui xe. Giao hàng. Tôi sẽ giao các khóa ổn định với các lần thử lại có giới hạn và đối chiếu, để khách hàng nhận được cà phê mà không phải tài trợ cho việc giáo dục hệ thống phân tán của bạn. Và đó là the diff cho ngày hôm nay. Tôi là Niko từ Axrisi. Hợp nhất có trách nhiệm.

Nguồn

1. Idempotent requestsStripe Docs
2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
3. Advanced error handlingStripe Docs
4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor