IOSOR

IOSOR ความรู้

Webhook SMS ขาเข้า: การลองใหม่ ลำดับเหตุการณ์ และความเป็น idempotent เมื่อรับ

คู่มือการสร้างสำหรับทีม B2B ที่จัดการ SMS ขาเข้า: ทำไมการลองใหม่จึงเกิดขึ้น ทำไมลำดับเหตุการณ์จึงไม่รับประกัน และวิธีทำให้ endpoint การรับของคุณเป็น idempotent แทนที่จะทำให้การสนทนาและการจัดการ STOP ซ้ำซ้อน

ตัวจัดการข้อความขาเข้าทุกตัวในที่สุดจะเจอกับความประหลาดใจสามอย่างเดียวกัน: webhook เดียวกันทำงานสองครั้ง เหตุการณ์ "delivered" มาถึงหลังจาก "failed" ที่มันควรจะแทนที่ และการตอบกลับ STOP ของลูกค้าถูกประมวลผลสองครั้งเพราะเซิร์ฟเวอร์สองเครื่องได้รับการลองใหม่แบบเดียวกัน ไม่มีสิ่งใดในนี้เป็นบั๊กของแพลตฟอร์มที่ส่ง webhook ให้คุณ — มันคือพฤติกรรมปกติของระบบส่งมอบแบบ "อย่างน้อยหนึ่งครั้ง" ใดๆ และ endpoint การรับของคุณต้องถูกสร้างขึ้นสำหรับความเป็นจริงนี้ตั้งแต่วันแรก.

IOSOR ส่งมอบ SMS ขาเข้า คำสำคัญ STOP/HELP และเหตุการณ์การส่งมอบเป็น webhook เติมเงินแบบ white-label — พฤติกรรมการลองใหม่และการจัดลำดับด้านล่างคือสิ่งที่การผสานรวม B2B ที่จริงจังใดๆ ควรสมมติ ไม่ว่าแพลตฟอร์มใดจะอยู่เบื้องหลัง.

ทำไม webhook จึงลองใหม่เลย

ผู้ให้บริการ webhook ไม่สามารถทราบได้อย่างแน่ชัดว่า endpoint ของคุณประมวลผลการส่งมอบแล้วหรือไม่ เซิร์ฟเวอร์ของคุณอาจส่งคืน 200 หลังจากคอมมิตในฐานข้อมูลที่ถูกย้อนกลับในภายหลัง; load balancer อาจสูญเสียการตอบสนองระหว่างทางกลับแม้ว่าตัวจัดการของคุณจะสำเร็จ; การปรับใช้อาจรีสตาร์ทกระบวนการของคุณกลางคำขอ เนื่องจาก "สูญเสียเหตุการณ์อย่างเงียบๆ" แย่กว่า "ส่งมันสองครั้งเป็นครั้งคราว" ระบบ webhook ที่จริงจังทุกระบบจึงเลือก.

สามโหมดความล้มเหลวที่คุณต้องออกแบบรองรับ

โหมดความล้มเหลว เกิดอะไรขึ้น อะไรพังถ้าคุณเพิกเฉย
การส่งมอบซ้ำซ้อน ID เหตุการณ์เดียวกันมาถึง 2 ครั้งขึ้นไป การตอบกลับถูกนับซ้ำ การประมวลผล STOP ซ้ำซ้อน เธรดการสนทนาซ้ำซ้อน
เหตุการณ์ไม่เรียงลำดับ เหตุการณ์ที่มีการประทับเวลาใหม่กว่ามาถึงก่อนเหตุการณ์ที่เก่ากว่า สถานะ "delivered" ถูกเขียนทับกลับเป็น "sent"
ความล้มเหลวบางส่วน/คลุมเครือ

Idempotency: คุณสมบัติเดียวที่แก้ไขทั้งสามอย่าง

endpoint การรับที่เป็น idempotent จะสร้างสถานะสุดท้ายเดียวกันไม่ว่าเหตุการณ์เดียวกันจะถูกส่งมอบกี่ครั้งก็ตาม กลไกนี้เรียบง่ายและเข้าใจได้ดี: ทุกเหตุการณ์ขาเข้ามี ID เหตุการณ์ที่ไม่ซ้ำกัน; ก่อนการประมวลผล คุณตรวจสอบว่าคุณได้บันทึก ID นั้นไว้แล้วหรือไม่; ถ้าใช่ คุณจะส่งคืนความสำเร็จทันทีโดยไม่ต้องประมวลผลใหม่.

ลำดับเหตุการณ์: ทำไม "การเขียนครั้งล่าสุดชนะ" จึงเป็นอันตราย

เหตุการณ์ webhook สำหรับข้อความเดียวกันไม่รับประกันว่าจะมาถึงตามลำดับที่เกิดขึ้น การลองใหม่ของเหตุการณ์ "queued" ก่อนหน้านี้อาจมาถึงหลังจากเหตุการณ์ "delivered" ในภายหลังเนื่องจากความสั่นไหวของเครือข่าย การจัดคิวฝั่งผู้ให้บริการ หรือ worker pool ของคุณเองประมวลผลคำขอไม่เรียงลำดับ หา.

STOP, HELP และคำสำคัญขาเข้าอื่นๆ ต้องการวินัยแบบเดียวกัน

คำสำคัญขาเข้าที่สำคัญต่อการปฏิบัติตามข้อกำหนดสมควรได้รับ idempotency ที่เข้มงวดที่สุด STOP ที่ซ้ำซ้อนไม่ควรบันทึกเหตุการณ์เลิกรับข้อมูลสองครั้งหรือส่งการตอบกลับยืนยันสองครั้งเลย HELP ที่ซ้ำซ้อนไม่ควรเรียกใช้ข้อความข้อมูลสนับสนุนแยกกันสองข้อความไปยังหมายเลขเดียวกันในนาทีเดียวกันเลย กำหนดเส้นทางการประมวลผลคำสำคัญผ่านตารางลบข้อมูลซ้ำเดียวกับข้อความขาเข้าปกติ — STOP.

เริ่มต้นกับ IOSOR

ดึงบันทึก webhook ขาเข้าสัปดาห์ก่อน นับ event ID ที่มาเกินครั้ง. เล่นซ้ำหนึ่งซ้ำและคู่ลำดับสลับ (failed แล้ว delivered). ฝั่งรับเก็บผลเดียว: แถวกล่องหนึ่ง เขียน STOP หนึ่ง แตะกระเป๋าหนึ่ง. Last-write-wins ที่ถอน STOP ถือว่าตก. นี่คือความไม่แปรผันตอนรับกับลำดับลองใหม่ ไม่ใช่ตรวจลายเซ็น และไม่ใช่กุญแจเกตเวย์ก่อนคิว.

สรุป IOSOR

webhook ขาเข้าลองใหม่. ความไม่แปรผันตอนรับคือคำตอบปลอดภัยเดียว; ลำดับไม่ใช่สัญญา.

ทำ: กุญแจเหตุการณ์และทิ้งแฝด. อย่า: last-write-wins บน STOP หรือหักเหตุการณ์เดียวกันสองครั้ง.

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

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