คำสั่งซื้อซ้ำเมื่อใช้งาน API: สาเหตุและการป้องกัน

ทำไมรายการซ้ำจึงเกิดขึ้นหลังการกระทำครั้งเดียว

เจ้าของแผงควบคุมอาจกดปุ่มเพียงครั้งเดียวแต่กลับเห็นคำสั่งซื้อซ้ำหลายรายการ: ผู้ติดตาม ยอดวิว รีแอคชัน หรือบริการอื่น โดยปกติปัญหาไม่ได้อยู่ที่การคลิก本身 แต่อยู่ในห่วงโซ่ระหว่างไคลเอนต์ API ฐานข้อมูล และผู้ให้บริการ

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

การหมดเวลาไม่ได้หมายความว่าคำสั่งซื้อไม่ได้ถูกสร้าง

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

ผลคือคำสั่งซื้อแรกมีอยู่ในฐานข้อมูลแล้ว และคำขอที่สองสร้างอีกหนึ่งรายการ สิ่งนี้เกิดขึ้นบ่อยโดยเฉพาะเมื่อ API ภายนอกตอบช้า คิวโอเวอร์โหลด หรือการเชื่อมต่อระหว่างบริการไม่เสถียร

การหมดเวลาแสดงเพียงว่าไม่ได้รับคำตอบ ไม่ได้แสดงว่าไม่มีการประมวลผลคำขอ

การส่งซ้ำอัตโนมัติฝั่งไคลเอนต์

ไลบรารีสำหรับคำขอ HTTP งานเบื้องหลัง และบริการเชื่อมต่อต่างๆ มักส่งคำขอซ้ำโดยอัตโนมัติ สาเหตุอาจเป็นข้อผิดพลาดในการเชื่อมต่อ รหัสตอบกลับจากเซิร์ฟเวอร์ เครือข่ายขาด หรือการตอบกลับที่ใช้เวลานานเกินไป

การส่งซ้ำมีประโยชน์ในตัวเอง: ช่วยลดจำนวนคำสั่งซื้อที่สูญหายเมื่อเกิดความขัดข้องชั่วคราว ข้อเสียของวิธีนี้คือหากไม่มีการป้องกันการประมวลผลซ้ำ มันจะเปลี่ยนความไม่เสถียรของเครือข่ายใดๆ ให้กลายเป็นรายการซ้ำ

• การส่งซ้ำอาจเริ่มทำงานในโค้ดของเว็บไซต์หรือบอท;
• คิวอาจรีสตาร์ทงาน;
• พร็อกซีหรือโมดูลเชื่อมต่ออาจส่งคำขอซ้ำ;
• ผู้ปฏิบัติงานอาจส่งคำสั่งซื้อซ้ำด้วยตนเองหลังเกิดข้อผิดพลาด

คำขอซ้ำมาถึงก่อนคำตอบแรก

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

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

สถานการณ์นี้เรียกว่า race condition การตรวจสอบเบื้องต้นในโค้ดเพียงอย่างเดียวไม่สามารถป้องกันได้อย่างสมบูรณ์ ข้อเสียของการตรวจสอบโดยไม่มีข้อจำกัดในระดับฐานข้อมูลคือมันล้มเหลวภายใต้ภาระแบบขนาน

คำสั่งซื้อถูกบันทึกแล้ว แต่คำตอบ API สูญหาย

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

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

คีย์ idempotency สำหรับการสร้างคำสั่งซื้อ

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

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

หนึ่งคีย์ควรสอดคล้องกับการดำเนินการทางธุรกิจหนึ่งรายการ ไม่ใช่การเชื่อมต่อ HTTP หนึ่งครั้ง

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

ความเป็นเอกลักษณ์ต้องถูกควบคุมโดยฐานข้อมูล

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

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

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

คิวอาจส่งงานมากกว่าหนึ่งครั้ง

คิวงานมักทำงานตามหลักการ "ส่งอย่างน้อยหนึ่งครั้ง" หากเวิร์กเกอร์ประมวลผลงานแล้วแต่ยังไม่ได้ยืนยันการเสร็จสิ้น คิวอาจส่งงานเดิมซ้ำให้เวิร์กเกอร์อื่น

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

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

รายการซ้ำเกิดขึ้นระหว่างแผงควบคุมและผู้ให้บริการ

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

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

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

เว็บฮุกไม่ควรสร้างคำสั่งซื้อใหม่

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

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

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

บันทึกใดช่วยค้นหาแหล่งที่มาของรายการซ้ำได้

สำหรับการสอบสวน การเห็นเพียงหมายเลขคำสั่งซื้อสองหมายเลขนั้นไม่เพียงพอ จำเป็นต้องมีข้อมูลของแต่ละขั้นตอนการประมวลผล: เวลาคำขอ คีย์ idempotency รหัสไคลเอนต์ พารามิเตอร์คำสั่งซื้อ หมายเลขงานเบื้องหลัง คำตอบจาก API ภายนอก และความพยายามในการส่งซ้ำ

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

ข้อเสียของบันทึกที่สั้นเกินไปคือแหล่งที่มาของปัญหาหายไปก่อนที่จะถูกวิเคราะห์ ข้อเสียของการบันทึกมากเกินไปคือบันทึกอาจมีโทเค็น ข้อมูลส่วนบุคคล และฟิลด์ที่ละเอียดอ่อนอื่นๆ ดังนั้นจึงต้องปิดบัง

วิธีจัดการกับผลลัพธ์คำขอที่ไม่ชัดเจน

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

1. สร้างคีย์การดำเนินการก่อนคำขอแรก
2. ส่งคีย์เดิมทุกครั้งที่ส่งซ้ำ
3. บันทึกคีย์และคำสั่งซื้อในการดำเนินการฐานข้อมูลที่มีการป้องกันเดียวกัน
4. ส่งรหัสการดำเนินการไปยังคิวและ API ภายนอก
5. ส่งคืนคำสั่งซื้อที่สร้างไว้ก่อนหน้าเมื่อมีการเรียกซ้ำ

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