ป้ายกำกับ: Race Condition

ในสถาปัตยกรรมระบบสมัยใหม่ที่ต้องรองรับการทำงานแบบ Multi-server Node หรือ High Concurrency การจัดการข้อมูลพร้อมกัน (Concurrent Operations) ถือเป็นความท้าทายหลักอย่างยิ่ง ปัญหาที่พบบ่อยที่สุดคือ Race Condition ซึ่งเกิดขึ้นเมื่อหลายคำขอ (Requests) เข้าถึงและแก้ไขข้อมูลเดียวกันในเวลาใกล้เคียงกัน ทำให้ผลลัพธ์สุดท้ายผิดพลาดหรือไม่ถูกต้อง

Distributed Lock คือกลไกสำคัญที่ช่วยให้แน่ใจว่ามีเพียงกระบวนการ (Process) เดียวเท่านั้นที่สามารถเข้าถึงส่วนวิกฤตของโค้ด (Critical Section) ได้ในแต่ละช่วงเวลา บทความนี้จะพาคุณไปดูวิธีการจัดการ Distributed Lock โดยเน้นการใช้คุณสมบัติระดับสูงของ PostgreSQL ซึ่งเป็นทางเลือกที่แข็งแกร่งและเป็น Native Feature ในการจัดการความสอดคล้องของข้อมูล (Data Consistency) ได้อย่างยอดเยี่ยม

🔑 หลักการทำงานของ Distributed Lock ใน PostgreSQL

แม้ว่า Redis จะเป็นที่นิยมสำหรับการทำ Distributed Lock แต่ PostgreSQL ก็มีกลไกที่ทรงพลังและเป็น Native คือ Advisory Locks (การล็อกแบบที่ปรึกษา) ซึ่งช่วยให้เราสามารถกำหนดล็อกให้กับทรัพยากรเฉพาะ (เช่น Product ID หรือ Job ID) ได้โดยไม่ต้องสร้างตารางล็อกแยกต่างหาก การใช้ Advisory Locks จะต้องทำภายใน Transaction เพื่อให้มั่นใจว่าการล็อกและการแก้ไขข้อมูลเป็น Atomic (ทำเสร็จสมบูรณ์ทั้งหมด หรือไม่ทำเลย)

💡 ตัวอย่างการใช้ Advisory Lock ใน PostgreSQL

สมมติว่าเรามีระบบที่ต้องลดจำนวนสินค้าคงคลัง (Inventory) เมื่อมีการสั่งซื้อ ซึ่งเป็น Critical Section ที่ต้องป้องกันการขายเกินจริง (Overselling) เราจะใช้ Advisory Lock เพื่อล็อก Product ID ก่อนดำเนินการ:

SQL

-- กำหนด Resource ID ที่ต้องการล็อก (เช่น Product ID 123) และใช้ฟังก์ชัน pg_try_advisory_lock() เพื่อตรวจสอบว่าล็อกว่างหรือไม่

BEGIN;

-- 1. พยายามเข้าถึงล็อก (Lock Key: 123)
SELECT pg_try_advisory_lock(123);

-- 2. ตรวจสอบว่าได้ล็อกสำเร็จหรือไม่ (ในโค้ดแอปพลิเคชันจะต้องมีการตรวจสอบค่าที่ส่งกลับ)
-- ถ้าล็อกสำเร็จ (Lock Acquired):

-- 3. ส่วนวิกฤต (Critical Section): ทำการอัปเดตข้อมูล
UPDATE inventory
SET stock_count = stock_count - 1
WHERE product_id = '1,2,3' AND stock_count > 0;

-- 4. ปล่อยล็อกเสมอ ไม่ว่าจะเกิดข้อผิดพลาดหรือไม่ (Commit/Rollback)
SELECT pg_advisory_unlock(123);

COMMIT;

คำอธิบาย: การใช้ `pg_try_advisory_lock(key)` จะคืนค่าเป็น Boolean หรือ Integer ที่บ่งบอกว่าล็อกถูกจับจองหรือไม่ หากได้ล็อกแล้ว เราจึงค่อยดำเนินการในส่วนวิกฤต (Critical Section) และที่สำคัญคือต้องใช้ `pg_advisory_unlock()` เพื่อปล่อยล็อกเมื่อเสร็จสิ้นการทำงานเสมอ

✨ การประยุกต์ใช้ในโลกจริง

การใช้ Distributed Lock ด้วย PostgreSQL Advisory Lock มีประโยชน์อย่างยิ่งใน:

• ระบบ E-commerce (Inventory): ป้องกันการขายเกินจริง (Overselling) เมื่อมีลูกค้าหลายคนกดสั่งซื้อสินค้าชิ้นสุดท้ายพร้อมกัน
• Job Queue Processing: เมื่อมี Worker หลายตัวต้องประมวลผลงานที่ต้องอาศัยการอัปเดตสถานะข้อมูลที่สอดคล้องกัน (เช่น การคำนวณคะแนนรวม)
• Financial Transactions: การโอนเงินหรือการตัดยอดบัญชีที่ต้องมั่นใจว่าไม่มีการคำนวณที่ซ้ำซ้อนหรือขัดแย้งกัน

🚀 บทสรุป (Conclusion)

การจัดการ Race Condition ในสภาพแวดล้อม Multi-server Node เป็นหัวใจสำคัญของการสร้างระบบที่เชื่อถือได้ การทำความเข้าใจและนำกลไก Distributed Lock มาใช้อย่างถูกต้อง ไม่ว่าจะเป็นการใช้ Redis หรือการใช้ PostgreSQL Advisory Locks จะช่วยให้มั่นใจได้ว่าข้อมูลของคุณจะมีความสอดคล้อง (Consistency) และความถูกต้อง (Integrity) เสมอ การทำความเข้าใจ Transaction Management และการล็อกจึงเป็นทักษะที่ Senior Architect ทุกคนไม่ควรมองข้าม