← กลับไปหน้าบทความDatabase
WAIHAUS / ARTICLE

Transaction​ ​และ​ ​ACID​ ​คือ​อะไร​ ​และ​สำคัญ​ต่อ​ระบบ​ธุรกิจ​อย่างไร

ธุรกรรมช่วยให้งานหลายคำสั่งสำเร็จหรือย้อนกลับร่วมกัน พร้อมอธิบาย Atomicity, Consistency, Isolation และ Durability

ACID TransactionDatabaseData Integrity
ภาพธุรกรรมตัดสต็อกและบันทึกคำสั่งซื้อที่ต้องสำเร็จร่วมกัน
ภาพธุรกรรมตัดสต็อกและบันทึกคำสั่งซื้อที่ต้องสำเร็จร่วมกัน

Transaction คือขอบเขตของงานฐานข้อมูลที่ต้องตัดสินผลร่วมกันว่า Commit หรือ Rollback ACID ย่อจาก Atomicity, Consistency, Isolation และ Durability ใช้อธิบายคุณสมบัติของธุรกรรมที่ช่วยรักษาความถูกต้องเมื่อมีข้อผิดพลาดหรือหลายผู้ใช้ทำงานพร้อมกัน

สี่คุณสมบัติในภาษางานธุรกิจ

Atomicity: งานในธุรกรรมสำเร็จร่วมกันหรือย้อนไปก่อนเริ่ม Consistency: ข้อบังคับข้อมูลที่กำหนดไว้ยังคงเป็นจริง Isolation: งานพร้อมกันไม่ควรเห็นหรือทำให้เกิดผลผิดตามระดับการแยกที่เลือก Durability: เมื่อ Commit สำเร็จ ข้อมูลควรคงอยู่ตามการรับประกันของระบบฐานข้อมูล รายละเอียดการ Isolation ขึ้นกับฐานข้อมูลและระดับที่ตั้งค่า ไม่ใช่คำว่า “แยกกัน” แบบสมบูรณ์ทุกกรณี

สองขั้นของคำสั่งซื้ออยู่ในขอบเขต Transaction

ภาพที่ 1: การบันทึกคำสั่งซื้อและตัดสต็อกต้องมีผลที่สอดคล้องกันเมื่ออยู่ในฐานข้อมูลเดียวกัน

ตัวอย่างสมมติ: ขายสินค้า

ระบบสร้างคำสั่งซื้อและลดสต็อก หากลดสต็อกไม่สำเร็จเพราะสินค้าหมด ระบบไม่ควรคงคำสั่งซื้อสถานะยืนยันโดยไม่มีสินค้ารองรับ ต้องออกแบบคำสั่งที่เกี่ยวข้องให้อยู่ใน Transaction ที่เหมาะสมและตรวจการแข่งกันของสองคำสั่งซื้อในเวลาเดียวกัน การมี Transaction อย่างเดียวไม่บอกว่ากฎ “สต็อกห้ามติดลบ” ถูกบังคับแล้ว ต้องมี Constraint หรือการตรวจที่ถูกจุดด้วย

ขอบเขตที่ Transaction ไม่ครอบคลุม

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

สำหรับรายงาน

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

อ่าน Database คืออะไร และ API Error Handling หรือดู บริการระบบหลังบ้าน

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ ลำดับ begin, insert, update stock, commit และกรณี rollback ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ