IOSOR

IOSOR ความรู้

Webhook ที่ซ้ำกันต้องไม่สร้างการหักเงินครั้งที่สอง

เส้นทางความล้มเหลว: การลองใหม่และการเล่นซ้ำจะคงความเป็น Idempotent บนเงิน prepaid และ inbox — ID เหตุการณ์เดียว แถวหักเงินเดียว และบรรทัด inbox เดียว

การส่งแบบ at-least-once จะมีการลองใหม่ Webhook ที่ซ้ำกัน ซึ่งโพสต์การหักเงินครั้งที่สองหรือบรรทัด inbox ที่สอง ถือเป็นอุบัติการณ์ด้านเงินและปฏิบัติการ ไม่ใช่ «การตอบรับที่ไม่เป็นอันตราย» หน้าตานี้คือ เส้นทางความล้มเหลว: การลองใหม่และการเล่นซ้ำจะยังคงเป็น Idempotent บนเงิน prepaid และ inbox ไม่ใช่บทความเกี่ยวกับการส่ง API แบบ idempotency และไม่ใช่คู่มือการลองใหม่ของ SMS ขาเข้า.

ที่เกี่ยวข้อง: เกตลายเซ็นและหน้าต่างเล่นซ้ำ, สัญญาเว็บโฮกก่อนการส่งข้อความครั้งแรก, แถว debit กับสถานะจัดส่งบน ledger เดียวกัน

IOSOR เป็นระบบ prepaid ป้ายขาว USD 20 เป็นทุนสำหรับการทดสอบเหตุการณ์ซ้ำในผู้ใช้รายเดียว การตรวจสอบแบบนุ่มนวลใกล้ USD 1,000/ต่อเดือน จะตีราคา «การลองใหม่ = การคิดเงินใหม่»

ความเป็น Idempotent คือเส้นทางความล้มเหลว ไม่ใช่คำขวัญ

เส้นทางปกติ: เหตุการณ์ที่เซ็นชื่อแล้วหนึ่งรายการ, การยอมรับหนึ่งรายการ, การหักเงินหนึ่งรายการ เส้นทางความล้มเหลวจะทำลายความไว้วางใจ — การหมดเวลา, 5xx, การเล่นซ้ำจากผู้ให้บริการ, การพุชซ้ำโดยผู้ปฏิบัติงาน จัดเก็บคีย์ idempotency จาก สัญญาเว็บโฮกก่อนการส่งข้อความครั้งแรก ก่อน จะเกิดผลกระทบข้างเคียง: ledger, inbox, CRM การตรวจสอบแบบนุ่มนวล USD 1,000/ต่อเดือน มองว่า «การตอบรับแล้วสร้างคีย์ใหม่»

อะไรนับเป็นความซ้ำซ้อน

สัญญาณ ถือเป็นซ้ำเมื่อ ผลลัพธ์ที่ปลอดภัย
ID เหตุการณ์ ยอมรับ ID เดิมในหน้าต่างเวลาแล้ว ตอบรับ (ACK); ไม่มีหักเงินครั้งที่สอง
ID ข้อความ เชื่อมโยงข้อความเดิมกับ ledger แล้ว ใช้แถวเดิมซ้ำ; ไม่มีค่าใช้จ่ายใหม่
คีย์ Inbox ยื่น MO/MT เดิมแล้ว ไม่มีบรรทัด inbox ที่สอง
นอกหน้าต่างเล่นซ้ำ ลองใหม่ที่เก่าหลังเกตปฏิเสธ ปฏิเสธ; ไม่เขียนเงิน/สถานะ
ชนิดที่ไม่รู้จัก ไม่อยู่ในรายการเหตุการณ์ตามสัญญา ทิ้ง;

เงินต้องไม่เคลื่อนย้ายสองครั้ง

การหักเงินครั้งที่สองสำหรับ ID เหตุการณ์เดิมถือเป็นข้อผิดพลาด แม้ว่าผลิตภัณฑ์จะ «ยังคงแสดงว่าจัดส่งแล้ว» ฝ่ายการเงินกรองตาม ID เหตุการณ์หรือข้อความและจะเห็นแถว prepaid เพียงแถวเดียวสำหรับหน้าต่าง UTC นั้น ผลกระทบข้างเคียงบางส่วนหลังจากตอบรับ — CRM ก่อน, ledger ทีหลัง — จะสร้างความจริงสองชุด หากการประมวลผลล้มเหลวหลังจากบันทึก ให้ลอง worker อีกครั้งบนคีย์เดิม อย่าตอบรับเนื้อหา HTTP ซ้ำเป็นการคิดเงินครั้งใหม่.

Inbox ต้องไม่เป็นสองเท่าเช่นกัน

Idempotency ไม่ได้มีไว้สำหรับเงินเท่านั้น เหตุการณ์ขาเข้าหรือการจัดส่งที่เล่นซ้ำและเปิดเธรด inbox ที่สอง จะฝึกให้ฝ่ายสนับสนุนไล่ตามเงาและอาจกระعتรุ้นลูปการตอบกลับอัตโนมัติ จัดเก็บคีย์ inbox ด้วย ID เหตุการณ์เดียวกันกับที่ใช้สำหรับการหักเงิน ผลิตภัณฑ์และการเงินใช้คำปฏิเสธ/ซ้ำร่วมกัน: ภาษาสถานะร่วมสำหรับผลิตภัณฑ์และการเงิน USD 20 พิสูจน์ว่าการบังคับเล่นซ้ำหนึ่งครั้งทำให้จำนวนเธรด inbox.

รายการตรวจสอบของผู้ซื้อสำหรับเว็บโฮกที่ปลอดภัยต่อความซ้ำซ้อน

  1. รูปร่างของคีย์ idempotency ตกลงในสัญญาและจัดเก็บก่อนเกิดผลกระทบข้างเคียงหรือไม่
  2. ID เหตุการณ์ที่ซ้ำกันในหน้าต่างเวลา → ตอบรับโดยไม่มีการหักเงินครั้งที่สอง?
  3. ID ข้อความเดิมไม่เปิดแถว ledger prepaid ที่สองใช่หรือไม่
  4. การแทรก inbox ใช้คีย์เดียวกัน — ไม่มีเธรดที่สองเมื่อเล่นซ้ำ?
  5. ความล้มเหลวของลายเซ็นและการปฏิเสธหน้าต่างนับแยกจากเหตุการณ์ซ้ำที่แท้จริงได้หรือไม่
  6. การพูดคุยเรื่อง USD 1,000/ต่อเดือน

เริ่มต้นด้วย IOSOR

บังคับเล่นซ้ำที่มีลายเซ็นหนึ่งครั้งในหน้าต่าง บนทางเดินที่ตัดเงินแล้ว ส่งออก id เหตุการณ์ข้าง id สมุด และพิสูจน์แถวหักหนึ่งแถวกับแถวกล่องเข้าหนึ่งแถว ถ้ามีหักที่สอง ให้หยุดผู้บริโภคนั้นและคืนแถวเกิน ห้ามไปหักล้างกับทราฟฟิกหลัง นี่คือประตูเงินเล่นซ้ำ ไม่ใช่ตรวจ E.164 และไม่ใช่คำ SMS ส่งของ

สรุป IOSOR

การเล่นซ้ำไม่ใช่การส่งใหม่ id เหตุการณ์หนึ่งเขียนหักหนึ่งครั้ง

ทำ: เปิดลายเซ็นกับหน้าต่างเล่นซ้ำ แล้วพิสูจน์หักหนึ่งครั้งหลัง POST ในหน้าต่าง อย่า: หักทุก POST หรือมองการลองใหม่ของเครือข่ายเป็นใบแจ้งหนี้ใบที่สอง

คู่มือนี้มีประโยชน์ไหม?

คู่มือที่เกี่ยวข้อง