+− THE DAILY DIFFdev & AI news
SHIP IT

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 รวมอย่างรับผิดชอบ

แหล่งที่มา

  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

วิดีโอที่เกี่ยวข้อง

under-the-hood · th · 10 ต.ค. 2569

Shopify ย้ายการจองสินค้าคงคลังไปที่ MySQL

Shopify ย้ายระบบการจองสินค้าคงคลังจาก Redis ไปยังฐานข้อมูล MySQL ซึ่งเป็นที่จัดเก็บข้อมูลบัญชีสินค้าคงคลังอยู่แล้ว กลุ่มแถวของหน่วยที่สามารถล็อกได้ทีละรายการในขอบเขตที่กำหนดช่วยให้การชำระเงินที่เกิดขึ

2:58 ↗
under-the-hood · th · 24 ก.ย. 2569

SAML, เจาะลึก: ลายเซ็นต์ภายในจดหมาย

SAML ทำให้คุณสามารถเข้าสู่ระบบแอปทำงานเกือบทุกแอป และลายเซ็นต์ของมันอาศัยอยู่ภายใน XML ที่มันลงนาม เจาะลึก: การเต้นรำของการเข้าสู่ระบบระหว่างแอป, เบราว์เซอร์ และผู้ให้บริการระบุตัวตน, ลักษณะของ Assert

3:02 ↗
under-the-hood · th · 23 ก.ย. 2569

เมื่อโมเดลตาย ภายใต้กลไกการทำงาน

โมเดล AI ไม่ได้ตาย — มันได้รับวันปิดตัว และเช้าวันรุ่งขึ้น การเรียก API ของคุณจะส่งคืน 404: "โมเดลนี้เลิกใช้งานแล้ว เรียนรู้เพิ่มเติมที่นี่" ภายใต้กลไกการทำงาน: กระบวนการสี่สถานะ (active → legacy → de

3:15 ↗
under-the-hood · th · 21 ก.ย. 2569

Claude แยกตัวประกอบ RSA-896 นี่คือวิธีที่ RSA ถูกทำลายจริง ๆ

เมื่อวันที่ 19 กันยายน วิศวกรของ Anthropic ได้แยกตัวประกอบ RSA-896 ซึ่งเป็นหมายเลขท้าทาย 270 หลัก ด้วย Claude ซึ่งเป็นพอร์ต GPU ของตะแกรง CADO-NFS แบบโอเพนซอร์ส และใช้ GPU ประมาณ 30 ปี บน GPU ที่ไม่ได

3:39 ↗