การซิงโครไนซ์ข้อมูลในแอปมือถือ - อุปกรณ์หลายเครื่องผู้ใช้หลายคน

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

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

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

1. ผู้ใช้กอยู่ในสถานะออฟไลน์และแก้ไขบันทึก # 100
2. ผู้ใช้ B ออฟไลน์และแก้ไขบันทึก # 100
3. ผู้ใช้ C ออฟไลน์และลบบันทึก # 100
4. ผู้ใช้ C เข้าสู่สถานะออนไลน์ (สมมุติว่า # 100 ควรลบข้อมูลบนเซิร์ฟเวอร์)
5. ผู้ใช้ A และ B ออนไลน์ แต่บันทึกที่พวกเขาแก้ไขไม่มีอยู่อีกต่อไป

สถานการณ์ทุกประเภทที่คล้ายกับด้านบนสามารถเกิดขึ้นได้

สิ่งนี้จัดการโดยทั่วไปอย่างไร? ฉันวางแผนที่จะใช้ MySQL แต่ฉันสงสัยว่ามันไม่เหมาะสมสำหรับปัญหาดังกล่าว

ขณะนี้ฉันกำลังทำงานกับแอพมือถือ / เดสก์ท็อป / แอพที่กระจายด้วยข้อกำหนดและปัญหาเดียวกันทั้งหมด

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

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

1. กลไกการควบคุม / ล็อครุ่นที่เหมาะสม
2. สิทธิที่เหมาะสม / การจัดการการเข้าถึง
3. กลยุทธ์การซิงโครไนซ์ / แคชที่เหมาะสม

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

(2) และ (3) เป็นปัญหาที่กว้างมากซึ่งต้องจัดการโดยอิสระจาก (1) คำแนะนำจากประสบการณ์ของฉัน:

• ใช้เทคโนโลยีไคลเอนต์ - เซิร์ฟเวอร์ที่สรุปประเด็นปัญหาส่วนใหญ่ให้คุณ ฉันขอแนะนำเทคโนโลยีเว็บบางอย่างเช่นCouchDbซึ่งจัดการ (1) ผ่าน Optimistic Offline Locking + MVCC (2) ผ่าน Web API และ (3) ผ่านแคช Http ได้ดีมาก

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

• ลองใช้เทคโนโลยีที่เป็นเนื้อเดียวกันถ้าเป็นไปได้ โดย "homogeneous" ฉันหมายถึงเทคโนโลยีที่สร้างขึ้นด้วยหลักการเดียวกันในใจเช่นสถานการณ์การใช้งานเว็บ 2.0 ตัวอย่าง: การใช้ CouchDb และ REST Client (Web API) ที่เหมาะสมกับกลยุทธ์การแคชในตัวเครื่องเป็นทางเลือกที่ดีกว่าการใช้ SQL สำหรับแอพมือถือ

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

โดยวิธีการที่ฉันได้ตัดสินให้ CouchDb กับลูกค้าในพื้นที่ที่กำหนดเองที่ทำงานกับ CouchDb APIs ซึ่งทำงานและปรับขนาดได้อย่างสวยงาม ฉันเปลี่ยนจากการใช้ MSQL + (N) Hibernate และจ่ายเงินในราคาสูงเพราะไม่ได้ทำการเลือกที่ถูกต้อง (หมายถึงการวิจัยไม่เพียงพอ) ในตอนแรก

ก่อนอื่นคุณพูดถึงทั้ง API และฐานข้อมูล (MySQL) ฉันขอแนะนำให้คุณใช้ API และอย่าพยายามสื่อสารโดยตรงระหว่างฐานข้อมูล เส้นทางหลังนั้นจะไม่ขยายออกไปเลย

หนึ่งในจุดเริ่มต้นที่ดีที่คุณควรพิจารณาคือการใช้Apache CouchDB มันเป็น schema-less ตาม HTTP และ JSON และมีกลไกการจำลองแบบที่ดีมาก เราใช้มันเพื่อแก้ปัญหาที่คล้ายกัน

กลไกการจำลองแบบของ CouchDB ใช้ HTTP API เดียวกับที่ลูกค้ารายอื่นใช้ ดังนั้นโดยพื้นฐานแล้วมันให้การจำลองแบบผ่าน API

สำหรับ iOS ผมขอแนะนำให้ใช้โครงการ Couchbase Lite มันทำงานได้ดีมากสำหรับการซิงค์ข้อมูล สำหรับ Android, บริษัท เดียวกันที่ทำให้ดังกล่าวโครงการ Couchbase Lite จะทำงานเกี่ยวกับการเสนอขายที่คล้ายกัน - Couchbase Lite สำหรับ Android มันยังไม่สมบูรณ์เท่ากับเวอร์ชั่น iOS และมีงานเหลือให้ทำ

มีบางสิ่งที่ต้องพิจารณาด้วย CouchDB อย่างไรก็ตาม

1. คุณจะต้องให้การแก้ไขความขัดแย้งของคุณเอง โชคดีถ้าความขัดแย้งเกิดขึ้น CouchDB เก็บเวอร์ชันที่ขัดแย้งกันและการเลือกและโดยพลการ แต่ความขัดแย้งที่กำหนดขึ้นเพื่อให้เป็นเวอร์ชันหลัก ดังนั้นคุณสามารถพิจารณาการชะลอการแก้ไขข้อขัดแย้งสำหรับเวอร์ชันเริ่มต้นของคุณ
2. กลไกการจำลองแบบถูกสร้างขึ้นสำหรับการจำลองฐานข้อมูลไม่ใช่การซิงโครไนซ์ต่อ se ดังนั้นหากคุณมีเอกสารที่ถูกลบจำนวนมากการจำลองแบบของคุณจากเซิร์ฟเวอร์ไปยังไคลเอนต์จะใช้เวลานานขึ้นและนานขึ้น มีวิธีการหลีกเลี่ยงปัญหานี้โดยใช้ "การหมุนฐานข้อมูล" สิ่งนี้จะเป็นการลบการลบเก่า ๆ
3. คุณไม่สามารถควบคุมลำดับการจำลองแบบได้ อย่างไรก็ตามคุณสามารถสร้างโซลูชันที่ชาญฉลาดเพื่อปรับปรุงประสิทธิภาพการจำลองแบบเช่นการใช้การจำลองแบบที่กรองแล้วเพื่อรับเอกสารบางอย่างก่อนหรือแม้กระทั่งเข้าถึงเซิร์ฟเวอร์ตามความต้องการโดยตรง
4. การจำลองแบบจะไม่เกิดขึ้นในพื้นหลังบน iOS คุณสามารถใช้ iOS SDK เพื่อให้การจำลองแบบพื้นหลังบางกรณี

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