วิธีการทำ Distributed Locking (2016)

 (martin.kleppmann.com)
4 คะแนน โดย GN⁺ 2024-10-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การทำ Distributed Lock

  • ผู้เขียนค้นพบอัลกอริทึม Redlock บนเว็บไซต์ Redis ซึ่งอ้างว่าสามารถทำ distributed lock ที่ทนทานต่อความขัดข้องบน Redis ได้
  • มี implementation อิสระของ Redlock อยู่แล้วหลายตัว และอาจมีคนที่พึ่งพาอัลกอริทึมนี้อยู่ จึงตัดสินใจแบ่งปันบันทึกของผู้เขียน
  • Redis มีประโยชน์เมื่อใช้แชร์ข้อมูลชั่วคราวและเปลี่ยนแปลงอย่างรวดเร็วระหว่างเซิร์ฟเวอร์ แต่การขยายไปสู่ขอบเขตการจัดการข้อมูลที่ต้องการความสอดคล้องเข้มงวดและความทนทานน่าเป็นกังวล

จุดประสงค์ของการล็อก

  • การล็อกมีหน้าที่รับประกันว่าในหลายโหนดจะมีเพียงโหนดเดียวเท่านั้นที่ทำงานบางอย่าง
  • หากใช้การล็อกเพื่อประสิทธิภาพ การใช้ Redis instance เดียวอาจดีกว่า
  • หากใช้การล็อกเพื่อความถูกต้อง Redlock ไม่เหมาะสม

การปกป้องทรัพยากรด้วยการล็อก

  • การล็อกในระบบกระจายแตกต่างจาก mutex ในแอปพลิเคชันแบบมัลติเธรด
  • ช่วยป้องกันไม่ให้ไคลเอนต์อื่นทำงานแบบเดียวกันกับไคลเอนต์หนึ่ง ระหว่างที่ไคลเอนต์นั้นกำลังอ่านไฟล์ แก้ไข แล้วเขียนกลับ

การทำ Safe Lock ด้วย Fencing

  • สามารถทำ safe lock ได้โดยใช้ fencing token และใส่มันไปกับคำขอเขียน
  • Redlock ไม่มีความสามารถในการสร้าง fencing token จึงไม่ปลอดภัย

การใช้เวลาเพื่อฉันทามติ

  • Redlock ตั้งสมมติฐานเกี่ยวกับเวลาไว้มาก ต่างจากอัลกอริทึมในโมเดล asynchronous
  • หากนาฬิการะบบทำงานผิดปกติ การหมดอายุของคีย์อาจเร็วหรือช้ากว่าที่คาด

การทำลายสมมติฐานเรื่องเวลาของ Redlock

  • Redlock ตั้งอยู่บนสมมติฐานของโมเดลระบบแบบ synchronous และทำงานถูกต้องได้ก็ต่อเมื่อความหน่วงเครือข่าย การหยุดชั่วคราวของโปรเซส และความผิดพลาดของนาฬิกาอยู่ในขอบเขตจำกัด
  • กรณีอย่างเหตุการณ์ packet delay 90 วินาทีบน GitHub สามารถคุกคามความปลอดภัยของ Redlock ได้

บทสรุป

  • Redlock หนักเกินความจำเป็นสำหรับการล็อกเพื่อเพิ่มประสิทธิภาพ และยังไม่ปลอดภัยเพียงพอสำหรับสถานการณ์ที่ต้องการความถูกต้อง
  • หากต้องการการล็อกเพื่อความถูกต้อง ควรใช้ระบบฉันทามติที่เหมาะสม เช่น ZooKeeper

สรุปของ GN⁺

  • อัลกอริทึม Redlock มอบประเด็นถกเถียงสำคัญเกี่ยวกับการทำ locking ในระบบกระจาย
  • บทความนี้เน้นปัญหาเรื่องสมมติฐานเวลาและความปลอดภัยในระบบกระจาย พร้อมอธิบายความสำคัญของการทำ locking ให้ถูกต้อง
  • แนะนำระบบทางเลือกอย่าง ZooKeeper และช่วยให้เข้าใจความซับซ้อนของระบบกระจายได้ดีขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-21
ความคิดเห็นจาก Hacker News
  • เคยมีประสบการณ์ใช้งาน Temporal เพื่อทำ distributed lock และจนถึงตอนนี้ก็ยังทำงานได้ดี โดยอาศัยความสามารถของ Temporal ทำให้การติดตั้งใช้งาน distributed lock ทำได้ง่าย
  • ได้แสดงความคิดเห็นไว้ในคอมเมนต์ของบล็อกว่าบทความพลาดประเด็นสำคัญของอัลกอริทึมไป และชี้ให้เห็นว่าการปฏิเสธอัลกอริทึมนั้นตั้งอยู่บนพื้นฐานของจุดอ่อน
  • เมื่อใช้คอมพิวเตอร์สมัยใหม่และ API ก็สามารถรอเวลาแบบคร่าว ๆ ได้ การหยุดชั่วคราวจาก GC มีขอบเขตจำกัด และนาฬิกา monotonic ก็ทำงานได้ ซึ่งเป็นสมมติฐานที่ยอมรับได้
  • การวิจารณ์กลไกการปลดล็อกอัตโนมัติกับการวิจารณ์เป้าหมายของอัลกอริทึมและแบบจำลองของระบบนั้นเป็นคนละประเด็นกัน
  • Redlock ถูกใช้งานสำเร็จในหลายกรณีการใช้งาน และถ้าตั้งค่า timeout อย่างเหมาะสมก็ยากที่จะทำให้เกิด race condition การตั้ง timeout ที่สั้นเกินไปถือเป็นข้อผิดพลาดด้านการออกแบบ
  • กำลังอัปเดตความรู้ด้าน low-level และอัลกอริทึมอยู่ และอยากสร้างอะไรบางอย่างเพื่อความสนุก แต่แหล่งข้อมูลส่วนใหญ่มีระดับแค่ของเล่นหรือไม่ก็ซับซ้อนมาก
  • ใช้ PostgreSQL เพื่อทำ distributed lock โดยเริ่ม transaction แล้วขอ advisory lock เพื่อคงสถานะล็อกไว้จนกว่า transaction จะถูกปล่อย
  • เพิ่งตระหนักว่าไม่ได้ตรวจสอบสถานะการเชื่อมต่อฐานข้อมูล และหากไม่ใช่งานที่เกี่ยวข้องกับฐานข้อมูล ก็อาจทำให้สูญเสียล็อกไปได้
  • เคยทำ distributed lock โดยใช้ Deno และ Deno KV ซึ่งมีพื้นฐานมาจาก FoundationDB
  • เคยพิจารณา Redis แต่แก้ปัญหาเรื่องความถูกต้องด้วยการใช้ PostgreSQL และแปลงคำขอให้เป็นงานแบบ SET
  • วิศวกรจำนวนมากไม่ได้ให้ความสำคัญกับปัญหาความถูกต้อง และยังมีกรณีขอบเขตที่ข้อความอาจสูญหายหรือเรียงลำดับผิดได้
  • การตั้ง timeout ให้กับ lock เป็นความคิดที่ดี และถ้าไคลเอนต์ล่ม ระบบปฏิบัติการหรือ supervisor จะเป็นผู้ปลดล็อก
  • หากไม่จำเป็นต้องใช้ lock ก็สามารถใช้ version token เพื่อรักษาความถูกต้องของข้อมูลได้ โดยอาจใช้ค่าที่ไม่ซ้ำกันอย่าง UUID