การออกแบบการเชื่อมต่อ SMM API ที่ทนต่อความล้มเหลว

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

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

ซ้อนการลองใหม่ด้วย backoff ทับลงไป ข้อผิดพลาดชั่วคราว (429 rate limit, 503, การรีเซ็ตเครือข่าย) ควรลองใหม่ด้วยการหน่วงเวลาที่เพิ่มขึ้นเรื่อย ๆ และมีเพดานจำกัด ไม่ใช่ยิงถล่มในทันที ส่วนข้อผิดพลาดถาวร (400 bad request, การตอบกลับว่ายอดคงเหลือไม่พอ) ควรล้มเหลวทันทีและแจ้งให้คนรับรู้ เพราะการลองใหม่กับมันเป็นเพียงการเสียเวลาและบดบังปัญหาที่แท้จริง

สุดท้าย จงกระทบยอด บันทึกทุกคำขอและการตอบกลับพร้อม idempotency key และ order ID และรันงานตามรอบที่เปรียบเทียบบันทึกของคุณกับสถานะคำสั่งซื้อของ panel การกระทบยอดคือสิ่งที่จับคำสั่งซื้อที่สำเร็จบน panel แต่ล้มเหลวในการบันทึกฝั่งคุณได้ API ของ SocialGO คืนค่า order ID และสถานะที่สม่ำเสมอโดยเฉพาะ เพื่อให้สร้างวงจรนี้ได้อย่างตรงไปตรงมา นั่นคือความแตกต่างระหว่างระบบอัตโนมัติที่คุณไว้ใจได้ กับระบบอัตโนมัติที่คุณต้องคอยเฝ้า