Stripe จดจำคำขอของคุณเมื่อการตอบกลับหายไป
การหมดเวลาอาจทำให้การชำระเงินไม่แน่นอนหลังจากที่เซิร์ฟเวอร์ดำเนินการเสร็จสิ้น คำอธิบาย Under the Hood นี้ใช้สัญญา idempotency ที่บันทึกไว้ของ Stripe API v1 เพื่อแสดงคีย์การทำงานที่เสถียร การเล่นซ้ำการตอบกลับที่บันทึกไว้ ข้อจำกัดพารามิเตอร์และการทำงานพร้อมกัน ขอบเขตการเก็บรักษา และการกระทบยอดผลลัพธ์
การหมดเวลาอาจทำให้การชำระเงินไม่แน่นอนหลังจากที่เซิร์ฟเวอร์ดำเนินการเสร็จสิ้น คำอธิบาย Under the Hood นี้ใช้สัญญา idempotency ที่บันทึกไว้ของ Stripe API v1 เพื่อแสดงคีย์การทำงานที่เสถียร การเล่นซ้ำการตอบกลับที่บันทึกไว้ ข้อจำกัดพารามิเตอร์และการทำงานพร้อมกัน ขอบเขตการเก็บรักษา และการกระทบยอดผลลัพธ์
อ่านฉบับลายลักษณ์อักษร (ภาษาอังกฤษ) ↗
วิดีโอนี้ครอบคลุมอะไรบ้าง
- Idempotency เกี่ยวข้องกับผลลัพธ์ที่ตั้งใจไว้ของการดำเนินการซ้ำ Stripe API v1 เพิ่มสัญญาการเล่นซ้ำการตอบกลับที่บันทึกไว้
- การลองใหม่ของการดำเนินการเชิงตรรกะเดียวกันใช้คีย์และพารามิเตอร์เดียวกัน เก็บรักษาคีย์การดำเนินการข้ามการเรียก SDK แยกกันหรือการรีสตาร์ทแอปพลิเคชัน การดำเนินการใหม่จริง ๆ ต้องมีคีย์ของตัวเอง
- หลังจากที่การดำเนินการปลายทางเริ่มขึ้น Stripe API v1 จะบันทึกสถานะและเนื้อหาของคำขอแรก รวมถึงข้อผิดพลาด 500 และส่งคืนการตอบกลับที่บันทึกไว้ในการลองใหม่
- พารามิเตอร์ที่เปลี่ยนแปลงไปพร้อมกับคีย์เดียวกันจะทำให้เกิดความไม่ตรงกัน ความล้มเหลวในการตรวจสอบความถูกต้องและความขัดแย้งในการดำเนินการพร้อมกันจะไม่บันทึกผลลัพธ์ที่เป็น idempotency สำหรับความพยายามนั้นและสามารถลองใหม่ได้
- Stripe เก็บรักษาคีย์ API v1 ไว้เป็นเวลาอย่างน้อย 24 ชั่วโมงและสามารถลบออกได้หลังจากนั้น จำกัดการลองใหม่ของเครือข่ายที่ไม่ได้รับการแก้ไขภายใน 24 ชั่วโมงแรก จากนั้นหยุดและกระทบยอดก่อนที่จะดำเนินการซ้ำ
- ข้อผิดพลาด 500 ที่แคชไว้อาจยังคงเล่นซ้ำได้หลังจากที่การเชื่อมต่อกลับมาทำงานได้ การดำเนินการเดิมอาจมีผลข้างเคียง ใช้วัตถุที่เกี่ยวข้อง คำขอใน Dashboard และ webhooks เพื่อสร้างผลลัพธ์
- API v2 ใช้ความหมายการเล่นซ้ำที่แตกต่างกัน คีย์ไม่ได้สร้างการส่งมอบแบบ 'exactly-once' ทั่วไปสำหรับการส่งอีเมล สินค้าคงคลัง และการดำเนินการฐานข้อมูลในเครื่องทุกครั้ง
บทถอดเสียงที่แปลแล้ว
แปลจากการบรรยายภาษาอังกฤษต้นฉบับ เสียงและคำบรรยายที่มีให้จะควบคุมโดย YouTube
การหมดเวลาทำให้การชำระเงินของคุณถูกยกเลิกหรือไม่?
0:00 คุณคิดว่าการหมดเวลาหมายถึงการชำระเงินของคุณล้มเหลว เซิร์ฟเวอร์สามารถเสร็จสิ้นในขณะที่การตอบกลับหายไป ทำให้การชำระเงินของคุณแสดงผลเป็นศูนย์อย่างมั่นใจ ทำไมการลองใหม่ถึงเรียกเก็บเงินอีกครั้งได้? Stripe จดจำความพยายามได้อย่างไร? คุณควรหยุดลองใหม่เมื่อใด? และจำรายละเอียดที่น่ารังเกียจอย่างหนึ่งไว้ ข้อผิดพลาดที่จำได้สามารถอยู่รอดได้นานกว่าปัญหาเครือข่าย
0:17 เราจะกลับมาเรื่องนั้น นี่คือ The Daily Diff, ภายใต้ฝากระโปรง
คีย์ Idempotency ระบุอะไร?
0:21 Idempotency หมายถึงการดำเนินการซ้ำมีผลลัพธ์ที่ตั้งใจไว้เหมือนกับการทำ มันครั้งเดียว คีย์ Idempotency ระบุการดำเนินการเชิงตรรกะหนึ่งรายการ Stripe API เวอร์ชันหนึ่งจดจำป้ายกำกับนั้นในการลองใหม่และเล่นซ้ำการตอบกลับที่บันทึกไว้ ลองนึกภาพการซื้อกาแฟ Stripe ดำเนินการตามคำขอชำระเงินของคุณเสร็จสิ้น และการตอบกลับหายไปในระหว่างทาง ลูกค้าเห็นวงกลมหมุน ธนาคารของพวกเขาอาจมีการตีความที่น่าตื่นเต้นกว่า คำขอสร้างที่ไม่ได้รับการป้องกันสามารถทำซ้ำผลข้างเคียงได้
คีย์เดียวกันทำให้การลองใหม่ปลอดภัยได้อย่างไร?
0:45 แนบคีย์ที่ไม่ซ้ำกันก่อนความพยายามแรกและเก็บไว้สำหรับการลองใหม่ หากแอปพลิเคชันของคุณรีสตาร์ท ให้เก็บรักษาคีย์นั้นไว้พร้อมกับการดำเนินการในบันทึกของคุณ สำหรับ Stripe's version one API เมื่อการดำเนินการปลายทางเริ่มขึ้น สถานะและเนื้อหาของคำขอแรกจะถูกบันทึกไว้ ส่งคีย์และพารามิเตอร์เดียวกันอีกครั้ง แล้ว Stripe จะส่งคืนการตอบกลับที่บันทึกไว้ กาแฟยังคงอยู่ขณะที่ใบเสร็จเดินทางอีกครั้ง
Stripe บันทึกอะไรบ้าง?
1:07 นี่คือถ้อยคำจริงของ Stripe การลองใหม่ด้วยคีย์เดียวกันจะส่งคืนการตอบกลับที่บันทึกไว้ รวมถึงข้อผิดพลาดห้าร้อยรายการ เอกสารประกอบทำงานได้มากกว่าตัวช่วยลองใหม่ที่ตั้งชื่ออย่างมองโลกในแง่ดีของคุณ ลูกค้าแตะอีกครั้ง แอปของคุณตัดสินใจว่าจะดำเนินการซื้อที่รอดำเนินการต่อหรือเริ่มการซื้ออีกครั้ง กาแฟใหม่จริง ๆ จะได้รับคีย์ใหม่ คีย์ใหม่สำหรับการลองใหม่ของเครือข่ายทุกครั้งจะทำให้การป้องกันใช้ไม่ได้ผล
1:27 พารามิเตอร์ที่แตกต่างกันด้วยคีย์เดียวกันจะทำให้เกิดความไม่ตรงกัน
จะเกิดอะไรขึ้นเมื่อคำขอเปลี่ยนแปลงไป?
1:30 หากพารามิเตอร์ไม่ผ่านการตรวจสอบความถูกต้อง หรือคำขออื่นที่มีคีย์นั้นยังคง กำลังดำเนินการอยู่ Stripe จะไม่บันทึกผลลัพธ์ที่เป็น idempotency สำหรับความพยายามนั้น คำขอเหล่านั้นสามารถลองใหม่ได้ คำขอที่แข่งขันกันจะเกิดข้อขัดแย้ง นี่คือกฎเวอร์ชันหนึ่ง เวอร์ชันสองมีพฤติกรรมแตกต่างกัน ส่วนหัวไม่สามารถรับประกันการส่งมอบแบบ 'exactly once' ทั่วทั้งระบบของคุณได้ อีเมล สินค้าคงคลัง และฐานข้อมูลของคุณแต่ละรายการต้องการการจัดการข้อผิดพลาด
1:52 คีย์ปกป้องการดำเนินการภายในขอบเขตที่กำหนดไว้ Stripe เก็บรักษาคีย์เวอร์ชันหนึ่งไว้เป็นเวลาอย่างน้อยยี่สิบสี่ชั่วโมงและสามารถลบออกได้
ผลลัพธ์ที่จำได้ปลอดภัยที่จะลองใหม่อีกครั้งนานแค่ไหน?
1:59 หลังจากนั้น คีย์ที่ถูกลบออกสามารถดำเนินการคำขอใหม่ได้ เก็บการลองใหม่ที่ยังไม่ได้รับการแก้ไขไว้ภายในวันแรก หลังจากนั้น ให้หยุดและกระทบยอดผลลัพธ์เดิม ใช้ exponential backoff และ jitter เพื่อให้เซิร์ฟเวอร์มีพื้นที่หายใจ มิฉะนั้นการลองใหม่จะก่อตัวเป็นคิวภายนอกร้านกาแฟที่กำลังลุกไหม้ ไลบรารีของ Stripe จัดการการลองใหม่ แต่ตรวจสอบค่าเริ่มต้นของไลบรารีของคุณ ข้อผิดพลาดที่เหนียวแน่นนั้นคือจุดสำคัญ
ทำไมข้อผิดพลาดที่จำได้ถึงกลับมาได้อีก?
2:20 การตอบกลับห้าร้อยรายการที่แคชไว้ยังคงเล่นซ้ำได้หลังจากที่การเชื่อมต่อกลับมาทำงานได้ การดำเนินการเดิมอาจมีผลข้างเคียง แก้ไขผลลัพธ์โดยใช้ออบเจกต์, Dashboard และ webhooks คีย์ใหม่สามารถทำซ้ำการดำเนินการได้ หากคุณต้องการอ่านข้อความนี้มากกว่าฟังฉันพูด, diff จะส่งถึงกล่องจดหมายของคุณ ทุกเช้า, ฟรีที่ the daily diff dot dev, ลิงก์ด้านล่าง
ฉันจะส่งปุ่มลองใหม่พร้อมสัญญานี้หรือไม่?
2:39 คำตัดสิน, ภายใต้ฝากระโปรง SHIP IT. ฉันจะ SHIP คีย์ที่เสถียรพร้อมการลองใหม่ที่มีขอบเขตและการกระทบยอด เพื่อให้ลูกค้าได้กาแฟโดยไม่ต้องเป็นเงินทุนในการศึกษาด้านระบบกระจายของคุณ และนั่นคือ diff สำหรับวันนี้ ฉันชื่อ Niko จาก Axrisi รวมอย่างรับผิดชอบ
แหล่งที่มา
- Idempotent requestsStripe Docs
- Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
- Advanced error handlingStripe Docs
- HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor



