Node.js Worker: วิธีแก้ปัญหา Background Queue วนซ้ำไม่หยุด

ปัญหาลูปการลองใหม่ (retry loop) ถือเป็นปัญหาความพร้อมใช้งานของระบบก่อนที่จะเป็นเพียงแค่เรื่องของการตั้งค่าคิว เพราะมันสามารถดึงเอาช่องทำงานทั้งหมดไปใช้กับงานที่ไม่วันสำเร็จ พร้อมทั้งเพิ่มอายุของข้อความที่ควรจะปกติ คำตอบสั้น ๆ คือ ให้งานเบื้องหลังแต่ละชิ้นมีงบประมาณความพยายามที่จำกัด จัดประเภทความล้มเหลวแบบถาวรก่อนจะกำหนดรอบการส่งใหม่ และเก็บระบบกู้คืน dead-letter queue ไว้เป็นปฏิบัติการที่ควบคุมโดยผู้ดูแลระบบ สำหรับ worker ของ Node.js ที่มีการลองใหม่ไม่หยุด เริ่มต้นด้วยการพิสูจน์ให้ได้ว่าตัวนับตัวไหนกำลังเพิ่มขึ้น เนื่องจากตัวโบรกเกอร์ ไลบรารีของ worker และโค้ดแอปพลิเคชันต่างก็สามารถรักษาค่าตัวนับที่แตกต่างกันได้

การถอยหลังทิ้งช่วง (backoff) จะเปลี่ยนไปเมื่อแต่งานส่งผลลัพธ์กลับมา แต่มันไม่ได้เป็นตัวตัดสินใจว่างานควรหยุดส่งกลับมา การติดตามข้อความหนึ่งข้อความไปตลอดเส้นทางก่อนที่จะเปลี่ยนการตั้งค่าจำนวนความพยายามสูงสุดเป็นสิ่งจำเป็น บันทึกรหัสข้อความที่ไม่สามารถเปลี่ยนแปลงได้ รหัสงานเชิงตรรกะ ประทับเวลาการเข้าคิว จำนวนการส่งของโบรกเกอร์ จำนวนความพยายามของแอปพลิเคชัน ประเภทข้อผิดพลาด เวอร์ชันของ worker และผลลัพธ์การรับทราบ การจัดการข้อผิดพลาดที่จับข้อยกเว้นแล้วสร้างงานทดแทนขึ้นมาใหม่อาจทำให้เกิดกระแสความพยายามครั้งแรกที่ดูเหมือนจริง การหมดอายุของสัญญาการมองเห็น (visibility lease) อาจทำให้เกิดการส่งซ้ำโดยไม่มีการเข้าคิวใหม่ และการเรดไรฟ (redrive) อาจแนะนำข้อความทางกายภาพชิ้นใหม่ในขณะที่ปฏิบัติการทางธุรกิจเดิมยังคงดำเนินอยู่

ความเหลื่อมล้ำของนาฬิกาเหล่านี้ทำให้เกิดรายงานคุ้นเคยที่ว่าข้อความพิษ (poison message) เพิกเฉยต่อขีดจำกัดสูงสุด คำถามวินิจฉัยแรกจึงดูน่าเบื่อแต่เด็ดขาด นั่นคือ ส่วนประกอบใดเป็นเจ้าของช่วงเปลี่ยนผ่านการลองใหม่ และค่าที่ตรวจสอบนั้นรอดพ้นทุกเส้นทางที่ส่งงานกลับเข้าสู่ระบบบริการหรือไม่ ตรวจสอบเส้นทางความสำเร็จด้วย การรับทราบในเส้นทางทำความสะอาดที่ถูกเลื่อนออกไป สัญญาที่ไม่ได้รอผลลัพธ์ หรือตัวจัดการข้อผิดพลาดกว้าง ๆ ที่แปลงการกระทำทางธุรกิจที่ล้มเหลวให้กลายเป็นความสำเร็จ ล้วนแต่ลบข้อความออกจากคิวในขณะที่ปล่อยให้สถานะที่ตั้งใจไว้หายไป

"A retry loop is an availability problem before it is a queue-setting problem: it can spend all worker slots on work that cannot succeed and raise the age of healthy messages."

Dev.to

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