ระบบคิวที่รองรับด้วยฐานข้อมูลกลายเป็นทางออกสำหรับปัญหาการสูญหายข้อมูลในระบบกระจาย

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

การอภิปรายนี้เกิดขึ้นจากการสะท้อนของอดีตวิศวกรโครงสร้างพื้นฐานของ Reddit เกี่ยวกับปัญหาที่ยืดเยื้อของแพลตฟอร์มในเรื่องการสูญหายของโหวต ความคิดเห็น และการส่งข้อมูล ระบบของ Reddit เช่นเดียวกับระบบอื่นๆ พึ่งพาตัวกลางส่งข้อความในหน่วยความจำอย่าง RabbitMQ และ Redis เพื่อความเร็ว แต่สิ่งนี้มาพร้อมกับการสูญเสียความน่าเชื่อถือ

ภาพนี้แสดงถึงแนวคิดของคิวในการออกแบบระบบ สะท้อนความท้าทายที่กล่าวถึงในบทความเกี่ยวกับการจัดการงานแบบกระจาย

บริบททางประวัติศาสตร์เผยให้เห็นความท้าทายทั่วทั้งอุตสาหกรรม

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

สิ่งที่น่าสนใจเป็นพิเศษคือแต่ละองค์กรดูเหมือนจะแก้ปัญหานี้แยกกัน บริษัทอย่าง Skype ใช้ PostgreSQL พร้อมเครื่องมือกำหนดเอง ในขณะที่ eBay สร้างโซลูชันที่ใช้ Oracle การขาดทางเลือกโอเพนซอร์สหมายความว่าความรู้และโซลูชันยังคงแยกออกจากกันภายในแต่ละบริษัท

จุดสำคัญทางเทคนิค:

• 1990s: ระบบคิวที่รองรับด้วยฐานข้อมูลในยุคแรกๆ ที่ธนาคารลงทุน ( Sybase )
• 1996-1999: France Telecom ใช้ Sybase Replication Server สำหรับเหตุการณ์การเรียกเก็บเงิน
• 2005: SQL Server เปิดตัวระบบคิว Service Broker
• 2005-2011: Skype สร้างระบบคิวที่ใช้ PostgreSQL พร้อมทีม DBA เฉพาะทาง
• 2016: PostgreSQL 9.5 เพิ่มฟีเจอร์ SKIP LOCKED ซึ่งทำให้ประสิทธิภาพพุ่งทะยาน

ความก้าวหน้าทางเทคนิคช่วยให้สามารถนำไปใช้ในวงกว้าง

สิ่งที่เปลี่ยนเกมคือการเปิดตัวฟีเจอร์ SKIP LOCKED ใน PostgreSQL 9.5 ประมาณปี 2016 การเพิ่มเติมที่ดูเหมือนเล็กน้อยนี้ปลดล็อกประสิทธิภาพที่จำเป็นเพื่อทำให้ระบบคิวที่รองรับด้วยฐานข้อมูลใช้งานได้จริงโดยไม่ต้องการทีมฐานข้อมูลเฉพาะทาง ฟีเจอร์นี้ช่วยให้ผู้ปฏิบัติงานหลายคนสามารถประมวลผลรายการคิวได้อย่างมีประสิทธิภาพโดยไม่มีข้อขัดแย้ง ซึ่งแก้ปัญหาคอขวดหลักที่ทำให้ระบบคิวฐานข้อมูลช้าและซับซ้อนในการจัดการ

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

โค้ดตัวอย่างนี้แสดงให้เห็นว่า durable queues สามารถนำไปใช้งานใน Python ได้อย่างไร โดยนำเสนอแนวทางแก้ไขทางเทคนิคที่กล่าวถึงในบทความ

การแลกเปลี่ยนประสิทธิภาพกำหนดการตัดสินใจในการใช้งาน

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

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

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

ข้อดีของ Durable Queue เทียบกับ Traditional Queues:

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

ภาพการจราจรติดขัดนี้เป็นสัญลักษณ์ของการแลกเปลี่ยนประสิทธิภาพในการจัดการ queues ซึ่งสะท้อนถึงความท้าทายที่กล่าวถึงในบทความ

บทสรุป

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

อ้างอิง: How I solved a distributed queue problem after 15 years