ในช่วงแรกๆ ของการคำนวณ ไม่จำเป็นต้องมีการทำธุรกรรมแบบกระจาย เมื่อจำนวนแอปพลิเคชันเพิ่มขึ้น การซิงโครไนซ์ข้อมูลจึงกลายเป็นปัญหาสำคัญ บริษัทจ่ายเงินจำนวนมากเพื่อรักษาระบบซิงโครไนซ์ในแง่ของกระแสข้อมูล ด้วยเหตุนี้ โปรโตคอลการคอมมิตแบบ 2 เฟสที่เรียกว่า XA(eXtended Architecture) จึงเกิดขึ้น โปรโตคอลนี้มีคุณสมบัติเหมือน ACID สำหรับการประมวลผลธุรกรรมทั่วโลก ตลอดบทความนี้ ฉันจะพยายามอธิบายรายละเอียดของธุรกรรม XA และการใช้ธุรกรรม XA ในกรอบงาน Spring

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

ดูที่นี่สำหรับแหล่งข้อมูลเกี่ยวกับ Java + .NET Interoperability ผ่าน 2PC

ธุรกรรม XA ต้องการรหัสธุรกรรมทั่วโลกและรหัสธุรกรรมภายใน (xid) สำหรับทรัพยากร XA แต่ละรายการ ทรัพยากร XA แต่ละรายการถูกเกณฑ์ไปยัง XA Manager โดยวิธี start(xid) วิธีนี้บอกว่าทรัพยากร XA มีส่วนเกี่ยวข้องในการทำธุรกรรม (เตรียมพร้อมสำหรับการดำเนินการ) หลังจากนั้น เฟสแรกของโปรโตคอล 2PC จะถูกรับรู้โดยการเรียกเมธอด prepare(xid) เมธอดนี้ร้องขอการโหวตตกลงหรือยกเลิกจากทรัพยากร XA หลังจากได้รับการโหวตจากแต่ละทรัพยากร XA แล้ว XA Manager ตัดสินใจที่จะดำเนินการกระทำ (xid) หากทรัพยากร XA ทั้งหมดส่งตกลงหรือตัดสินใจที่จะดำเนินการย้อนกลับ (xid) หากทรัพยากร XA ส่ง ABORT สุดท้าย จะมีการเรียกเมธอด end(xid) สำหรับทรัพยากร XA แต่ละรายการเพื่อแจ้งว่าธุรกรรมเสร็จสมบูรณ์ ดูรูปจะเข้าใจมากขึ้น เมื่อเราสร้างพื้นหลังในการใช้งานธุรกรรม XA เราจะเจาะลึกลงไปอีก และดูการพิมพ์คำสั่งนี้ คำสั่งนี้ คำสั่งของความล้มเหลวและวิธีแก้ปัญหาที่เป็นไปได้


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

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

กรอบงาน Spring ให้สภาพแวดล้อมที่กว้างขวางในการพัฒนาเว็บและแอปพลิเคชันแบบสแตนด์อโลน เช่นเดียวกับยูทิลิตี้อื่น ๆ ที่มีให้ ธุรกรรม XA ได้รับการสนับสนุนโดย Spring ด้วย อย่างไรก็ตาม การสนับสนุนนี้ไม่ใช่การใช้งานแบบเนทีฟ และต้องใช้ไฮเบอร์เนต เว็บคอนเทนเนอร์ หรือเฟรมเวิร์กที่มีการจัดการธุรกรรม XA Spring มี JtaTransactionManager ที่จัดเตรียมยูทิลิตีการจัดการธุรกรรมและซ่อนรายละเอียด ด้วยวิธีนี้ เราสามารถมีการจัดการธุรกรรมสำหรับแหล่งข้อมูลหลายแหล่งซึ่งได้รับการอัปเดตพร้อมกัน เมื่อพูดถึงการใช้ XA Transaction Management การรองรับไฮเบอร์เนตและเว็บคอนเทนเนอร์สำหรับธุรกรรม XA นั้นได้รับการบันทึกไว้เป็นอย่างดี ไม่จำเป็นต้องกล่าวถึง อย่างไรก็ตาม การทำงานกับกรอบงานที่จัดเตรียมธุรกรรม XA อาจทำให้สับสนได้ ดังนั้นฉันจะโพสต์นี้ต่อโดยแนะนำตัวจัดการธุรกรรม Bitronix

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

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

โดยสรุป เราได้พยายามอธิบายว่าธุรกรรม XA คืออะไร โปรโตคอลพื้นฐาน และการรวมการจัดการธุรกรรม Bitronix กับ Spring ในแอปพลิเคชันแบบสแตนด์อโลน เพื่อขยาย XA Transactions ให้การแก้ไขแหล่งข้อมูลต่างๆ ในเวลาเดียวกัน นอกจากนี้ ธุรกรรม XA ยังได้รับการสนับสนุนโดยเว็บคอนเทนเนอร์หรือไฮเบอร์เนตเช่นเฟรมเวิร์ก อย่างไรก็ตาม เราอาจจำเป็นต้องรวมการจัดการธุรกรรมเข้ากับแอปพลิเคชันแบบสแตนด์อโลน ซึ่งเราต้องกำหนดค่าตัวจัดการธุรกรรม ด้วยเหตุนี้ ธุรกรรม XA จึงมีการดำเนินการที่สอดคล้องกันในแหล่งข้อมูลหลายแห่งและบริษัทต่างๆ ใช้ประโยชน์จากแหล่งข้อมูลเหล่านี้
เราหวังว่าบทความนี้จะช่วยคุณในการทำธุรกรรม XA (2 Phase Commit): A Simple Guide หากคุณมีคำถามอื่นๆ เรายินดีที่จะตอบคำถามของคุณ โปรดติดต่อเราในส่วนด้านล่าง อย่าลืมแชร์ signalfix.net กับครอบครัวและเพื่อนของคุณ!