วิธีป้องกันสภาวะการแข่งขันในเว็บแอปพลิเคชัน

พิจารณาเว็บไซต์อีคอมเมิร์ซที่ทั้ง Alice และ Bob กำลังแก้ไขรายการผลิตภัณฑ์ อลิซกำลังปรับปรุงคำอธิบายขณะที่ Bob กำลังอัพเดทราคา พวกเขาเริ่มแก้ไข Acme Wonder Widget ในเวลาเดียวกัน บ๊อบเสร็จสิ้นก่อนและบันทึกผลิตภัณฑ์ด้วยราคาใหม่ อลิซใช้เวลาในการอัปเดตคำอธิบายนานขึ้นและเมื่อเธอทำเสร็จเธอจะบันทึกผลิตภัณฑ์ด้วยคำอธิบายใหม่ของเธอ น่าเสียดายที่เธอเขียนทับราคาด้วยราคาเดิมซึ่งไม่ได้มีเจตนา

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

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

เราจะป้องกันสภาพการแข่งขันดังกล่าวได้อย่างไร? โดยเฉพาะอย่างยิ่งฉันต้องการทราบ:

• เทคนิคใดบ้างที่สามารถใช้ได้ เช่นการติดตามเวลาของการเปลี่ยนแปลงครั้งล่าสุด อะไรคือข้อดีข้อเสียของแต่ละคน
• ประสบการณ์การใช้งานที่เป็นประโยชน์คืออะไร?
• กรอบการป้องกันนี้มีอะไรในตัว?

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

ฉันได้เห็น 2 วิธีหลัก:

1. เพิ่มการประทับเวลาของการอัปเดตล่าสุดของหน้าที่ใช้แก้ไขในอินพุตที่ซ่อนอยู่ เมื่อส่งมอบการประทับเวลาจะถูกตรวจสอบกับปัจจุบันและหากพวกเขาไม่ตรงกับมันได้รับการปรับปรุงโดยคนอื่นและกลับข้อผิดพลาด

   • pro: ผู้ใช้หลายคนสามารถแก้ไขส่วนต่าง ๆ ของหน้า หน้าข้อผิดพลาดสามารถนำไปสู่หน้าต่างที่ผู้ใช้คนที่สองสามารถรวมการเปลี่ยนแปลงของเขาในหน้าใหม่

   • คอนดิชั่น: บางครั้งความพยายามส่วนใหญ่ได้สูญเปล่าระหว่างการแก้ไขพร้อมกันขนาดใหญ่

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

   • pro: ความพยายามแก้ไขไม่สูญเปล่า

   • คอนดิชั่น: ผู้ใช้ที่ไร้ยางอายสามารถล็อคเพจได้อย่างไม่มีกำหนด หน้าเว็บที่มีการล็อคที่หมดอายุอาจยังสามารถกระทำได้เว้นแต่จะได้รับการจัดการ (โดยใช้เทคนิค 1)

ใช้มองโลกในแง่ควบคุมภาวะพร้อมกัน

เพิ่มคอลัมน์ versionNumber หรือ versionTimestamp ให้กับตารางในคำถาม (จำนวนเต็มปลอดภัยที่สุด)

ผู้ใช้ 1 อ่านบันทึก:

{id:1, status:unimportant, version:5}

ผู้ใช้ 2 อ่านบันทึก:

{id:1, status:unimportant, version:5}

ผู้ใช้ 1 บันทึกการบันทึกการเพิ่มรุ่นนี้:

save {id:1, status:important, version:5}
new value {id:1, status:important, version:6}

ผู้ใช้ 2 พยายามบันทึกบันทึกที่อ่าน:

save {id:1, status:unimportant, version:5}
ERROR

Hibernate / JPA สามารถทำสิ่งนี้โดยอัตโนมัติด้วย@Versionคำอธิบายประกอบ

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

ระบบ Object Relational Mapping (ORM) บางระบบจะตรวจจับว่าฟิลด์ใดของวัตถุที่ถูกเปลี่ยนแปลงนับตั้งแต่ถูกโหลดจากฐานข้อมูลและจะสร้างคำสั่ง SQL update เพื่อตั้งค่าเหล่านั้นเท่านั้น ActiveRecord สำหรับ Ruby on Rails เป็นหนึ่ง ORM เช่นนั้น

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

ขึ้นอยู่กับภาษาการเขียนโปรแกรมที่คุณใช้งานวิจัย ORM ใดที่พร้อมใช้งานและดูว่ามีรายการใดบ้างที่จะอัปเดตคอลัมน์ในฐานข้อมูลที่ระบุว่า "สกปรก" ในแอปพลิเคชันของคุณ