การแก้ปัญหาข้อขัดแย้งสำหรับการซิงค์สองทาง


24

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

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

มีกลยุทธ์ทั่วไปในการจัดการกับปัญหาประเภทนี้หรือไม่? นี่คือตัวเลือกที่ฉันคิดได้:
1. ใช้ข้อมูลฝั่งไคลเอ็นต์เป็นลำดับความสำคัญที่สูงขึ้น
2. เหมือนกันกับฝั่งเซิร์ฟเวอร์
3. พยายามแก้ไขข้อขัดแย้งด้วยการทำเครื่องหมายการประทับเวลาการแก้ไขของแต่ละฟิลด์และทำการแก้ไขล่าสุด

แม้ว่าฉันจะแน่ใจว่าตัวเลือกที่ 3 จะเปิดห้องสำหรับการทำลายข้อมูลที่รุนแรง

ฉันรู้ว่าทฤษฎีบท CAP เกี่ยวข้องกับเรื่องนี้ แต่ฉันต้องการความมั่นคงในที่สุดเท่านั้นดังนั้นมันจึงไม่ได้ออกกฎสมบูรณ์ใช่ไหม?

คำถามที่เกี่ยวข้อง: ที่ดีที่สุดรูปแบบการปฏิบัติสำหรับการประสานข้อมูลแบบสองทาง คำตอบที่สองสำหรับคำถามนี้บอกว่าคงไม่สามารถทำได้


คำตอบ:


14

วิธีการแก้ปัญหาตามปกติสำหรับการรู้ "ซึ่งการเปลี่ยนแปลงเป็นสิ่งที่ถูกต้อง" เป็นนาฬิกาเวกเตอร์ คุณต้องติดตามเคาน์เตอร์สำหรับพื้นที่เก็บข้อมูลแต่ละแห่งที่เก็บข้อมูลและปฏิเสธการเปลี่ยนแปลงหากมุมมองของลูกค้าที่เฉพาะเจาะจงเกี่ยวกับสถานะของคนอื่น ๆ นั้นแตกต่างจากของเพื่อนที่กำลังเชื่อมต่ออยู่

คำถามใหญ่ที่คุณต้องตอบคือวิธีที่คุณจะแก้ไขการบันทึกที่ถูกปฏิเสธ ซึ่งโดยทั่วไปหมายถึงการดำเนินการผสานบางอย่าง

โปรดทราบว่านาฬิกาเวกเตอร์ไม่ได้ใช้การประทับเวลาตามเวลาจริง ปัญหาที่เกี่ยวข้องกับการซิงโครไนซ์นาฬิกาแบบเรียลไทม์อย่างน้อยก็ยากเท่ากับการซิงโครไนซ์ข้อมูล


1
ดีนี่คือสิ่งที่ฉันกำลังมองหา
K.Steff

10

นี่คือปัญหาByzantine Generalsซึ่งไม่สามารถแก้ไขได้ คุณไม่สามารถรับประกันว่าจะซิงโครไนซ์เซิร์ฟเวอร์ทั้งสองถ้าคุณไม่สามารถรับประกันได้ว่าในอนาคตในบางครั้งคุณจะมีแบนด์วิดท์ที่น่าเชื่อถือเพียงพอที่จะทำการซิงโครไนซ์ทั้งหมดในครั้งเดียว


ตกลง แต่คนเหล่านี้จะได้รับผลที่คล้ายกันอย่างไร
Syncpoint

3
พวกเขาเพียงแค่สมมติว่าคุณจะมีการเชื่อมต่อที่เชื่อถือได้ของแบนด์วิดท์ที่เพียงพอในอนาคต
DeadMG

1

ฉันเดาว่าไม่มีวิธีมาตรฐานในการทำเช่นนี้แต่ละระบบใช้นโยบายของตนเองสำหรับการแก้ไขข้อขัดแย้ง

ฉันสร้างแบบจำลองโดยใช้อุปกรณ์สองเครื่องคอมพิวเตอร์และโทรศัพท์และ Google Spreadsheet เพื่อตรวจสอบว่า Google เอกสารจัดการข้อขัดแย้งโดยอัตโนมัติอย่างไร ที่นี่บางกรณี:

กรณีที่ 1

  1. คอมพิวเตอร์และโทรศัพท์ออฟไลน์
  2. คอมพิวเตอร์แก้ไขเซลล์ด้วยค่า 'คอมพิวเตอร์' และหลังโทรศัพท์แก้ไขเซลล์ด้วยค่า 'โทรศัพท์'
  3. คอมพิวเตอร์กลายเป็นออนไลน์
  4. โทรศัพท์ออนไลน์และทั้งคอมพิวเตอร์และโทรศัพท์จะแสดง 'โทรศัพท์'

กรณีที่ 2

  1. คอมพิวเตอร์และโทรศัพท์ออฟไลน์
  2. คอมพิวเตอร์แก้ไขเซลล์ด้วยค่า 'คอมพิวเตอร์' และหลังโทรศัพท์แก้ไขเซลล์ด้วยค่า 'โทรศัพท์'
  3. โทรศัพท์กลายเป็นออนไลน์
  4. คอมพิวเตอร์กลายเป็นออนไลน์และทั้งคอมพิวเตอร์และโทรศัพท์จะแสดง 'คอมพิวเตอร์'

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

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

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

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

ฉันจะใช้วิธี GIT เป็นอย่างอื่นโดยแสดงป๊อปอัพในไคลเอนต์ถัดไปในเบื้องหน้าขอให้ผู้ใช้เลือกเวอร์ชันที่จะเก็บหรือให้โอกาสในการคืนค่าการผสาน


1
ฉันยอมรับว่าวิธีการเป็นกรณี ๆ ไปเป็นวิธีที่เหมาะสมในการไปที่นี่ วิธีที่ "ดีที่สุด" (วิธี git) นั้นไม่สามารถใช้งานได้เสมอเนื่องจากผู้ใช้อาจไม่ต้องการตรวจสอบ / รวมการเปลี่ยนแปลง
K.Steff
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.