ธุรกรรมแบบกระจาย: เจาะลึก Two-Phase Commit (2PC)

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

ธุรกรรมแบบกระจายคืออะไร

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

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

ขอแนะนำโปรโตคอล Two-Phase Commit (2PC)

โปรโตคอล Two-Phase Commit (2PC) เป็นอัลกอริทึมแบบกระจายที่ช่วยให้มั่นใจได้ถึงความเป็นอะตอมในผู้จัดการทรัพยากรหลายราย (เช่น ฐานข้อมูล) มันเกี่ยวข้องกับตัวประสานงานส่วนกลางและผู้เข้าร่วมหลายราย โดยแต่ละรายรับผิดชอบในการจัดการทรัพยากรเฉพาะ โปรโตคอลทำงานในสองขั้นตอนที่แตกต่างกัน:

ขั้นตอนที่ 1: เตรียมพร้อม

ในขั้นตอนนี้ ตัวประสานงานจะเริ่มธุรกรรมและขอให้ผู้เข้าร่วมแต่ละรายเตรียมพร้อมสำหรับการ commit หรือ rollback ธุรกรรม ขั้นตอนต่างๆ มีดังนี้:

ตัวประสานงานส่งคำขอเตรียมพร้อม: ตัวประสานงานส่งข้อความ "เตรียมพร้อม" ไปยังผู้เข้าร่วมทั้งหมด ข้อความนี้ส่งสัญญาณว่าตัวประสานงานพร้อมที่จะ commit ธุรกรรมและขอให้ผู้เข้าร่วมแต่ละรายเตรียมพร้อมที่จะทำเช่นนั้น
ผู้เข้าร่วมเตรียมพร้อมและตอบสนอง: ผู้เข้าร่วมแต่ละรายได้รับคำขอเตรียมพร้อมและดำเนินการดังต่อไปนี้:
- ดำเนินการตามขั้นตอนที่จำเป็นเพื่อให้แน่ใจว่าสามารถ commit หรือ rollback ธุรกรรมได้ (เช่น การเขียนบันทึก redo/undo)
- ส่ง "การโหวต" กลับไปยังตัวประสานงาน โดยระบุว่า "เตรียมพร้อมที่จะ commit" (การโหวต "ใช่") หรือ "ไม่สามารถ commit ได้" (การโหวต "ไม่") การโหวต "ไม่" อาจเป็นเพราะข้อจำกัดด้านทรัพยากร ความล้มเหลวในการตรวจสอบความถูกต้องของข้อมูล หรือข้อผิดพลาดอื่นๆ

สิ่งสำคัญสำหรับผู้เข้าร่วมคือต้องรับประกันว่าพวกเขาสามารถ commit หรือ rollback การเปลี่ยนแปลงได้เมื่อพวกเขาโหวต "ใช่" โดยปกติแล้ว สิ่งนี้เกี่ยวข้องกับการรักษาการเปลี่ยนแปลงในพื้นที่เก็บข้อมูลที่เสถียร (เช่น ดิสก์)

ขั้นตอนที่ 2: Commit หรือ Rollback

ขั้นตอนนี้เริ่มต้นโดยตัวประสานงานตามคะแนนเสียงที่ได้รับจากผู้เข้าร่วมในขั้นตอนการเตรียมพร้อม มีสองผลลัพธ์ที่เป็นไปได้:

ผลลัพธ์ที่ 1: Commit

หากตัวประสานงานได้รับคะแนนเสียง "ใช่" จากผู้เข้าร่วมทั้งหมด จะดำเนินการ commit ธุรกรรม

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

ผลลัพธ์ที่ 2: Rollback

หากตัวประสานงานได้รับคะแนนเสียง "ไม่" เพียงครั้งเดียวจากผู้เข้าร่วมรายใดรายหนึ่ง หรือหากหมดเวลาในการรอการตอบสนองจากผู้เข้าร่วม จะตัดสินใจ rollback ธุรกรรม

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

ตัวอย่างประกอบ: การประมวลผลคำสั่งซื้ออีคอมเมิร์ซ

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

ขั้นตอนเตรียมพร้อม:
- ระบบอีคอมเมิร์ซ (ตัวประสานงาน) ส่งคำขอเตรียมพร้อมไปยังฐานข้อมูลสินค้าคงคลังและเกตเวย์การชำระเงิน
- ฐานข้อมูลสินค้าคงคลังตรวจสอบว่าสินค้าที่ร้องขอมีในสต็อกหรือไม่และจองไว้ จากนั้นจะโหวต "ใช่" หากสำเร็จ หรือ "ไม่" หากสินค้าหมดสต็อก
- เกตเวย์การชำระเงินอนุมัติการชำระเงินล่วงหน้า จากนั้นจะโหวต "ใช่" หากสำเร็จ หรือ "ไม่" หากการอนุมัติล้มเหลว (เช่น มีเงินไม่เพียงพอ)
ขั้นตอน Commit/Rollback:
- สถานการณ์ Commit: หากทั้งฐานข้อมูลสินค้าคงคลังและเกตเวย์การชำระเงินโหวต "ใช่" ตัวประสานงานจะส่งคำขอ commit ไปยังทั้งสองอย่าง ฐานข้อมูลสินค้าคงคลังจะลดจำนวนสินค้าคงคลังอย่างถาวร และเกตเวย์การชำระเงินจะจับการชำระเงิน
- สถานการณ์ Rollback: หากฐานข้อมูลสินค้าคงคลังหรือเกตเวย์การชำระเงินโหวต "ไม่" ตัวประสานงานจะส่งคำขอ rollback ไปยังทั้งสองอย่าง ฐานข้อมูลสินค้าคงคลังจะปล่อยสินค้าที่จองไว้ และเกตเวย์การชำระเงินจะโมฆะการอนุมัติล่วงหน้า

ข้อดีของ Two-Phase Commit

ความเป็นอะตอม: 2PC รับประกันความเป็นอะตอม ทำให้มั่นใจได้ว่าระบบที่เข้าร่วมทั้งหมดจะ commit หรือ rollback ธุรกรรมร่วมกัน รักษาความสอดคล้องของข้อมูล
ความเรียบง่าย: โปรโตคอล 2PC นั้นค่อนข้างง่ายต่อการทำความเข้าใจและนำไปใช้
การนำไปใช้อย่างกว้างขวาง: ระบบฐานข้อมูลและระบบประมวลผลธุรกรรมจำนวนมากรองรับ 2PC

ข้อเสียของ Two-Phase Commit

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

ทางเลือกอื่นสำหรับ Two-Phase Commit

เนื่องจากข้อจำกัดของ 2PC แนวทางอื่น ๆ หลายอย่างจึงเกิดขึ้นสำหรับการจัดการธุรกรรมแบบกระจาย ซึ่งรวมถึง:

Three-Phase Commit (3PC): ส่วนขยายของ 2PC ที่พยายามแก้ไขปัญหาการบล็อกโดยการแนะนำเฟสเพิ่มเติมเพื่อเตรียมพร้อมสำหรับการตัดสินใจ commit อย่างไรก็ตาม 3PC ยังคงเสี่ยงต่อการบล็อกและซับซ้อนกว่า 2PC
รูปแบบ Saga: รูปแบบธุรกรรมระยะยาวที่แบ่งธุรกรรมแบบกระจายออกเป็นชุดของธุรกรรมในพื้นที่แต่ละรายการ ธุรกรรมในพื้นที่แต่ละรายการจะอัปเดตบริการเดียว หากธุรกรรมหนึ่งล้มเหลว ธุรกรรมชดเชยจะถูกดำเนินการเพื่อยกเลิกผลกระทบของธุรกรรมก่อนหน้า รูปแบบนี้เหมาะสำหรับสถานการณ์ความสอดคล้องในที่สุด
Two-Phase Commit with Compensating Transactions: รวม 2PC สำหรับการดำเนินการที่สำคัญกับธุรกรรมชดเชยสำหรับการดำเนินการที่ไม่สำคัญ วิธีการนี้ช่วยให้เกิดความสมดุลระหว่างความสอดคล้องที่แข็งแกร่งและประสิทธิภาพ
Eventual Consistency: แบบจำลองความสอดคล้องที่อนุญาตให้มีความไม่สอดคล้องกันชั่วคราวระหว่างระบบ ข้อมูลจะสอดคล้องกันในที่สุด แต่อาจมีความล่าช้า วิธีการนี้เหมาะสำหรับแอปพลิเคชันที่สามารถทนต่อความไม่สอดคล้องกันในระดับหนึ่ง
BASE (Basically Available, Soft state, Eventually consistent): ชุดของหลักการที่ให้ความสำคัญกับความพร้อมใช้งานและประสิทธิภาพเหนือความสอดคล้องที่แข็งแกร่ง ระบบที่ออกแบบตามหลักการ BASE มีความยืดหยุ่นต่อความล้มเหลวมากขึ้นและสามารถปรับขนาดได้ง่ายขึ้น

การประยุกต์ใช้ Two-Phase Commit ในทางปฏิบัติ

แม้จะมีข้อจำกัด 2PC ก็ยังคงถูกนำมาใช้ในสถานการณ์ต่างๆ ที่ความสอดคล้องที่แข็งแกร่งเป็นข้อกำหนดที่สำคัญ ตัวอย่างบางส่วน ได้แก่:

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

การนำ Two-Phase Commit ไปใช้

การนำ 2PC ไปใช้ต้องพิจารณาปัจจัยต่างๆ อย่างรอบคอบ รวมถึง:

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

ข้อควรพิจารณาในระดับโลกสำหรับธุรกรรมแบบกระจาย

เมื่อออกแบบและนำธุรกรรมแบบกระจายไปใช้ในสภาพแวดล้อมระดับโลก ปัจจัยเพิ่มเติมหลายประการจำเป็นต้องได้รับการพิจารณา:

ความหน่วงแฝงของเครือข่าย: ความหน่วงแฝงของเครือข่ายสามารถส่งผลกระทบอย่างมากต่อประสิทธิภาพของ 2PC โดยเฉพาะอย่างยิ่งในระบบที่กระจายทางภูมิศาสตร์ การปรับปรุงการเชื่อมต่อเครือข่ายและการใช้เทคนิคต่างๆ เช่น การแคชข้อมูล สามารถช่วยลดผลกระทบของความหน่วงแฝงได้
ความแตกต่างของเขตเวลา: ความแตกต่างของเขตเวลาสามารถทำให้การประมวลผลธุรกรรมซับซ้อน โดยเฉพาะอย่างยิ่งเมื่อจัดการกับประทับเวลาและกิจกรรมตามกำหนดเวลา ขอแนะนำให้ใช้เขตเวลาที่สอดคล้องกัน (เช่น UTC)
การแปลข้อมูล: ข้อกำหนดการแปลข้อมูลอาจทำให้ต้องจัดเก็บข้อมูลในภูมิภาคต่างๆ สิ่งนี้สามารถทำให้การจัดการธุรกรรมแบบกระจายมีความซับซ้อนมากขึ้นและต้องมีการวางแผนอย่างรอบคอบเพื่อให้มั่นใจว่าสอดคล้องกับกฎระเบียบความเป็นส่วนตัวของข้อมูล
การแปลงสกุลเงิน: เมื่อจัดการกับธุรกรรมทางการเงินที่เกี่ยวข้องกับหลายสกุลเงิน การแปลงสกุลเงินจะต้องได้รับการจัดการอย่างระมัดระวังเพื่อให้มั่นใจในความถูกต้องและการปฏิบัติตามกฎระเบียบ
การปฏิบัติตามกฎระเบียบ: ประเทศต่างๆ มีกฎระเบียบที่แตกต่างกันเกี่ยวกับการคุ้มครองข้อมูล ความปลอดภัย และธุรกรรมทางการเงิน การทำให้มั่นใจว่าสอดคล้องกับกฎระเบียบเหล่านี้เป็นสิ่งสำคัญเมื่อออกแบบและนำธุรกรรมแบบกระจายไปใช้

บทสรุป

ธุรกรรมแบบกระจายและโปรโตคอล Two-Phase Commit (2PC) เป็นแนวคิดสำคัญสำหรับการสร้างระบบแบบกระจายที่มีประสิทธิภาพและสอดคล้องกัน ในขณะที่ 2PC มอบโซลูชันที่เรียบง่ายและนำไปใช้อย่างแพร่หลายสำหรับการทำให้เป็นอะตอม ข้อจำกัดต่างๆ โดยเฉพาะอย่างยิ่งเกี่ยวกับการบล็อกและจุดเดียวที่ล้มเหลว ทำให้ต้องพิจารณาแนวทางอื่น ๆ อย่างรอบคอบ เช่น Sagas และความสอดคล้องกันในที่สุด การทำความเข้าใจข้อแลกเปลี่ยนระหว่างความสอดคล้องที่แข็งแกร่ง ความพร้อมใช้งาน และประสิทธิภาพเป็นสิ่งสำคัญในการเลือกแนวทางที่เหมาะสมกับความต้องการเฉพาะของแอปพลิเคชันของคุณ นอกจากนี้ เมื่อทำงานในสภาพแวดล้อมระดับโลก จะต้องพิจารณาเพิ่มเติมเกี่ยวกับความหน่วงแฝงของเครือข่าย เขตเวลา การแปลข้อมูล และการปฏิบัติตามกฎระเบียบเพื่อให้มั่นใจถึงความสำเร็จของธุรกรรมแบบกระจาย