การซิงโครไนซ์กับระบบออฟไลน์


9

ฉันออกแบบระบบที่ฉันจะซิงโครไนซ์ข้อมูลธุรกิจจากอุปกรณ์มือถือ (ที่มีแอพพลิเคชั่นแบบฝัง) ที่สร้างข้อมูลและส่งกลับไปที่เซิร์ฟเวอร์ แต่ละบรรทัดที่ซิงโครไนซ์จะสร้างบันทึกธุรกิจเฉพาะในฐานข้อมูล

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

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

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

ปริมาณของข้อมูลที่ซิงโครไนซ์ไม่คาดว่าจะมีขนาดใหญ่ทั้งกระบวนการซิงโครไนซ์

ดังนั้นฉันจึงลงเอยด้วยการแยกซึ่งกันและกันในวิธีการซิงโครไนซ์ของฉันแม่นยำมากขึ้นฉันใช้ Java และฉันใส่ซิงโครไนซ์กับวิธีการเขียนไม่ใช่กระบวนการซิงโครไนซ์ทั้งหมดเพื่อไม่บล็อกการซิงค์แบบอ่านอย่างเดียว

ผมอยากจะรู้ว่า :

  1. หากวิธีนี้เหมาะสม ตราบใดที่ปริมาณและเวลาของกระบวนการซิงโครไนซ์ยังคงยอมรับได้
  2. โดยทั่วไปแล้วฉันควรจะดูแนวคิดอะไร โบนัส: หากมีการนำแนวคิดเหล่านี้ไปใช้ในโมดูล Spring

สาเหตุใดที่ทำให้ออฟไลน์ ฉันหมายถึงเมื่ออุปกรณ์ออฟไลน์หมายความว่าไม่มีการเข้าถึงเซิร์ฟเวอร์หรือไม่ได้เชื่อมต่อกับอินเทอร์เน็ต
Laiv

มันไม่สามารถเข้าถึงอินเทอร์เน็ตได้ หรือไม่บ่อย
Walfrat

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

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

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

คำตอบ:


1

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

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

ดังนั้นแทนที่จะให้ลูกค้าส่งข้อมูลทั้งหมดพร้อมวันที่ไปยังเซิร์ฟเวอร์ลูกค้าจะส่งกิจกรรมพร้อมกับหมายเลขการแก้ไขที่สอดคล้องกับครั้งล่าสุดที่ลูกค้าคิดว่าข้อมูลได้รับการปรับปรุง บางสิ่งเช่นนี้

Server.send("MODIFY FOO", 3);

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

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

ระยะของคุณอาจแตกต่างกันไป แต่ฉันหวังว่าจะช่วยได้

แก้ไข: ชื่ออื่นสำหรับวิธีการนี้หรือรูปแบบอื่นเรียกว่าการจัดคิวข้อความตามที่กล่าวถึงในคำถามที่เกี่ยวข้องนี้


ระบบสามารถออฟไลน์ (ไม่สามารถเข้าถึงเซิร์ฟเวอร์) ได้ในบางวันและต้องลงทะเบียนวันที่เมื่อเกิดเหตุการณ์ไม่ใช่เมื่อซิงโครไนซ์เหตุการณ์กับเซิร์ฟเวอร์ นั่นเป็นเหตุผลที่ฉันต้องใช้วันที่ ฉันมีหมายเลขการแก้ไขสำหรับ optimisticLocking ด้วย แต่ด้วยเหตุผลเดียวกัน 2 อุปกรณ์สามารถดาวน์โหลดรุ่น X ของ POJO และเมื่อพวกเขาซิงค์ในภายหลังแต่ละเหตุการณ์การส่งที่ต้องสร้างรุ่น X + 1 และ X + 2 และอุปกรณ์ไม่สามารถสื่อสารซึ่งกันและกัน
Walfrat

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

0

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

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

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

  3. คำถามนี้เป็นคำถามเกี่ยวกับการใช้ล็อคในแง่ดีในฤดูใบไม้ผลิ บางทีคุณอาจพบแรงบันดาลใจในนั้น


ฉันต้องบันทึกวันที่ที่มีการดำเนินการเช่นฉันกำลังติดกับวันที่ของมือถือ วันที่ที่มือถือมีการซิงค์กับระบบบ่อยครั้ง เฉพาะผู้ที่ลงทะเบียนแล้วเท่านั้นที่สามารถซิงค์กับเซิร์ฟเวอร์ สำหรับเรื่องความปลอดภัยเป็นเรื่องที่น่ากังวลสำหรับตอนนี้ (การตรวจสอบอุปกรณ์ X509, ... )
Walfrat

สามารถบันทึกวันที่เป็นฟิลด์ข้อมูลอื่นได้โดยไม่ต้องถือเป็นโทเค็นการซิงโครไนซ์
Basilevs
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.