H. Garcia-Molina และ K. Salem 2530. โศกนาฏกรรม . ในรายงานการประชุมนานาชาติ ACM SIGMOD ปี 1987 ว่าด้วยการจัดการข้อมูล (SIGMOD '87) Association for Computing Machinery, New York, NY, USA, 249–259

คำสำคัญ:กระบวนการที่ใช้เวลานาน, Sagas, ธุรกรรม, การชดเชย, การบรรเทาความล้มเหลว, ความทนทานต่อความล้มเหลว, ความโปร่งใสของความล้มเหลว

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

การแนะนำ

ใน กระดาษSagas ของพวกเขา Hector Garcia-Molina และ Kenneth Salem แนะนำแนวคิดของ Sagas เพื่อดำเนินการ "ระยะยาว"

Molina และ Salem อ้างถึงกระบวนการที่ประกอบด้วยขั้นตอนเดียวว่าเป็นกระบวนการ "ทำงานระยะสั้น" หรือ "อายุสั้น" และกระบวนการที่ประกอบด้วยหลายขั้นตอนเป็น "การทำงานระยะยาว" หรือ "อายุยืน" ดังนั้น การวิ่งระยะสั้นหรือการวิ่งระยะยาวจึงไม่ใช่คำสั่งเกี่ยวกับเวลาทางกายภาพ แต่เป็นคำสั่งเกี่ยวกับเวลาเชิงตรรกะโดยแต่ละขั้นตอนเป็นสัญญาณนาฬิกา (รูปที่ 1)

ปัญหา

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

กระดาษกำหนดกระบวนการ P เป็นลำดับของขั้นตอน a, b, ฯลฯ โดยที่แต่ละขั้นตอนเป็นธุรกรรมฐานข้อมูล หากต้องการใช้คำศัพท์ที่คุ้นเคยมากขึ้น คุณสามารถคิดว่ากระบวนการเป็นฟังก์ชันและลำดับของขั้นตอนเป็นลำดับของการเรียก API ไปยังฐานข้อมูล

เราอ้างถึงลำดับของขั้นตอน a, b ฯลฯ เป็นการติดตาม:

trace(P) = a • b • …

กล่าวอีกนัยหนึ่ง: ลำดับของธุรกรรมสองรายการไม่ใช่ธุรกรรม!

เล็กน้อย หากกระบวนการประกอบด้วยธุรกรรมเดียว กระบวนการจะแสดงการรับประกันปรมาณูของธุรกรรม (รูปที่ 3)

อย่างไรก็ตาม หากกระบวนการประกอบด้วยธุรกรรมหลายรายการ กระบวนการนั้นจะไม่แสดงการรับประกันปรมาณูของธุรกรรม: กระบวนการอาจดำเนินการเพียงบางส่วน (รูปที่ 4)

อย่างไรก็ตาม ไม่เหมือนกับธุรกรรมอื่นๆ ธุรกรรมของกระบวนการมีความเกี่ยวข้องกันและควรดำเนินการเป็นหน่วย การดำเนินการบางส่วนของกระบวนการเป็นสิ่งที่ไม่พึงปรารถนา

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

การแก้ไขปัญหา

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

เพื่อลดการดำเนินการบางส่วน กระบวนการอาจใช้การกู้คืนไปข้างหน้าหรือย้อนกลับ [2]:

ส่งต่อการกู้คืน

การกู้คืนความล้มเหลวไปข้างหน้าหมายถึงกลยุทธ์การลดความล้มเหลวที่เปลี่ยนระบบจากสถานะตัวกลางไปเป็นสถานะที่เทียบเท่ากับสถานะสุดท้าย (การย้ายกระบวนการไปข้างหน้า)

การกู้คืนย้อนหลัง

การกู้คืนความล้มเหลวย้อนหลังหมายถึงกลยุทธ์การลดความล้มเหลวที่เปลี่ยนระบบจากสถานะตัวกลางไปเป็นสถานะที่เทียบเท่ากับสถานะเริ่มต้น (การย้ายกระบวนการย้อนกลับ)

การกู้คืนและการชดเชยย้อนหลัง

ในการเปิดใช้งานการกู้คืนย้อนหลัง แต่ละกระบวนการควรลงทะเบียนขั้นตอนการชดเชยสำหรับแต่ละขั้นตอน (รูปที่ 6)

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

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

การดำเนินการ

ดังนั้นในกรณีที่ไม่มีความล้มเหลว กระบวนการPจะสร้างการติดตามที่ต้องการ

trace(P) = s₁ • s₂ • … sₙ • ✔️

trace(P) = s₁ • s₂ • … sᵢ • × • cᵢ … • c₂ • c₁ • ✔️

เมื่อความล้มเหลวขัดขวาง Saga Saga จะต้องสามารถกู้คืนสถานะปัจจุบันได้และดำเนินการกู้คืนไปข้างหน้าหรือย้อนกลับ ดังนั้น Saga จะต้องสามารถบันทึกจุดเริ่มต้นของ Saga ตอนจบของ Saga และบันทึกจุดตรวจและค่าตอบแทนได้

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

การอภิปราย

แม้ว่าบทความนี้จะเขียนขึ้นเมื่อกว่า 35 ปีที่แล้ว แต่ปัญหาและ Sagas เป็นวิธีแก้ปัญหาที่เสนอยังคงมีความเกี่ยวข้องในปัจจุบัน อย่างไรก็ตาม ความสนใจได้เปลี่ยนจากการเขียนธุรกรรมฐานข้อมูลเป็นการเขียนคำขอบริการ

โปรดทราบว่าบริการไม่แสดงคุณสมบัติทางธุรกรรม: บริการอาจไม่ใช่ปรมาณูหลังจากเรียกใช้บริการ และหากบริการขัดข้อง คุณอาจไม่ทราบว่าบริการมีผลหรือไม่

ดังนั้นคุณควรลงทะเบียนการดำเนินการชดเชยก่อนที่จะเรียกใช้บริการและออกแบบตรรกะการชดเชยให้ถูกต้องไม่ว่าบริการจะมีผลหรือไม่

บทสรุป

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

อ้างอิง

• [1] ความหมายการติดตามสำหรับการทำธุรกรรมระยะยาว, M. Butler, CAR Hoare & C. Ferreira, 2005
• [2] การจัดการความล้มเหลวจากหลักการแรก , Dominik Tornow, 2022