Mobil uygulamalarda Veri Senkronizasyonu - birden fazla cihaz, birden fazla kullanıcı

İlk mobil uygulamamı oluşturmaya çalışıyorum. Uygulamanın temel özelliklerinden biri, birden fazla cihazın / kullanıcının aynı verilere erişebileceği ve hepsinin CRUD haklarına sahip olmasıdır.

Mimarinin, tüm verilerin depolandığı merkezi bir sunucu içermesi gerektiğine inanıyorum. Aygıtlar, veri işlemlerini gerçekleştirmek için sunucuyla etkileşimde bulunmak için bir API kullanır (örneğin, bir kayıt eklemek, bir kaydı düzenlemek, bir kaydı silmek).

Verileri senkronize etmenin problem olacağı bir senaryo hayal ediyorum. Uygulamanın İnternete bağlı olmadığı zaman çalışması gerektiğini ve bu nedenle bu merkezi sunucu ile iletişim kuramadığını varsayalım. Yani:

1. Kullanıcı A çevrimdışı ve kayıt # 100'ü düzenler
2. B kullanıcısı çevrimdışı ve kayıt # 100'ü düzenliyor
3. Kullanıcı C çevrimdışı ve kayıt # 100'ü siler
4. C kullanıcısı çevrimiçine gider (büyük olasılıkla, 100 numaralı kayıt sunucuda silinmeli)
5. A ve B kullanıcıları çevrimiçi olur, ancak düzenledikleri kayıtlar artık mevcut değildir

Yukarıdakilere benzer her türlü senaryo ortaya çıkabilir.

Bu genel olarak nasıl ele alınır? MySQL kullanmayı planlıyorum, ancak böyle bir sorun için uygun olup olmadığını merak ediyorum.

Şu anda aynı gereksinimleri ve sorunları olan bir mobil / masaüstü / dağıtık uygulama üzerinde çalışıyorum.

Her şeyden önce, bu gereksinimler kendi başına mobil uygulamalara özgü değildir, ancak bağlantısı kesilmiş / dağıtılmış istemci-sunucu işlemlerine özgüdür (paralel programlama, çoklu okuma, siz anlayın). Elbette bunlar mobil uygulamalarda ele alınacak tipik konular.

Genel olarak, tüm bunların kaynaştığı şey, aynı anda düzenleyebilecek n müşterilere dağıtılan potansiyel bir veri kaydınızın olmasıdır. İhtiyacın olan şey

1. uygun bir versiyon kontrol / kilitleme mekanizması,
2. uygun bir hak / erişim yönetimi,
3. uygun bir senkronizasyon / önbellek stratejisi

(1) için bazı desenler uygulayabilirsiniz: Sık kullanılan iki kilitleme stratejisi vardır: İyimser Çevrimdışı Kilitleme ve Kötümser Çevrimdışı Kilitleme . Bunlardan bazıları, her değiştirilen kayıt için güncellenen her veri kaydı için bir sayaç kullanan (çok basit bir "zaman damgası" gibi) MultiVersion Eşzamanlılık Kontrolü (MVCC) gibi farklı sürüm kontrol "kalıpları" nda uygulanır. .

(2) ve (3), (1) den bağımsız olarak ele alınması gereken çok geniş konulardır. Tecrübelerime dair bir tavsiye:

• Sizin için sorunların çoğunu ortadan kaldıran bir istemci-sunucu teknolojisi kullanın. İyimser Çevrimdışı Kilitleme + MVCC, (2) Web API aracılığıyla (1) ve (3) Http önbelleğe alma yoluyla çok iyi çalışan CouchDb gibi bazı web teknolojilerini tavsiye ederim .

• Kanıtlanmış teknolojilere ve yaklaşımlara güveniyorsanız, kendiniz bir şey icat etmemeye çalışın. Mevcut teknolojileri / kalıpları araştırmak ve karşılaştırmak için harcanan herhangi bir saatin kendi sistemlerinizi uygulamaya çalışmaktan çok daha iyi harcandığına inanıyorum.

• Mümkünse homojen teknolojiler kullanmaya çalışın. "Homojen" derken, aynı ilkeleri göz önünde bulundurarak oluşturulan teknolojileri, örneğin web 2.0 kullanım senaryolarını kastediyorum. Örnek: Yerel önbelleğe alma stratejisiyle uygun bir CouchDb ve REST İstemcisi (Web API) kullanmak, mobil uygulamalar için SQL kullanmaktan daha iyi bir seçimdir.

• Bu tür kullanım senaryoları için açıkça yaratılmayan bir teknoloji olduğu için MySQL'in kullanılmasını şiddetle tavsiye ediyorum. Çalışıyor, ancak zaten web iletişimini ve eşzamanlılık stilini (örneğin, NoSQL Veritabanları gibi) içeren bir veritabanı sistemiyle daha iyi bir şekilde çalışıyorsunuz.

Bu arada, CouchDb için, harika çalışan ve ölçekleyen CouchDb API'lerine karşı çalışan özel bir yerel müşteriyle karar kıldım. MSQL + (N) Hazırda Bekletme özelliğini kullanmaya başladım ve ilk önce doğru seçimi yapmamak (yeterli araştırma yapmamak demek) için yüksek bir bedel ödedim.

İlk önce, hem bir API hem de bir veritabanından (MySQL) bahsettiniz. Bir API kullanmanızı ve doğrudan veritabanları arasında iletişim kurmayı denememenizi tavsiye ederim. Bu son rota hiç iyi ölçeklenmeyecek.

Göz önünde bulundurmanız gereken iyi bir başlangıç ​​noktası Apache CouchDB kullanmak . HTTP ve JSON'a dayanan bir şema içermez ve çok iyi bir çoğaltma mekanizmasına sahiptir. Benzer bir sorunu çözmek için kullanıyoruz.

CouchDB'nin çoğaltma mekanizması, diğer istemcilerin kullandığı aynı HTTP API'sini kullanır. Yani özünde, bir API üzerinden çoğaltma sağlar.

İOS için Couchbase Lite projesini kullanmanızı öneririm . Veri senkronizasyonu için çok iyi çalışıyor. Android için, yukarıda belirtilen Couchbase Lite projesini yapan aynı şirket benzer bir teklif üzerinde çalışıyor - Android için Couchbase Lite . İOS sürümü kadar eksiksiz değildir ve gerçekleştirilmesi gereken bazı işler vardır.

Ancak CouchDB'de göz önünde bulundurulması gereken birkaç şey var.

1. Kendi uyuşmazlık çözümünüzü sağlamanız gerekecektir. Neyse ki, çatışmalar ortaya çıkarsa, CouchDB çakışan versiyonlarını ve seçtiklerini tutar ve keyfi olarak seçer, fakat ana versiyon olarak belirleyici çatışmaya neden olur. Böylece ilk sürümünüz için çakışma çözümünü geciktirmeyi düşünebilirsiniz.
2. Çoğaltma mekanizması, per-se senkronizasyonu değil, veritabanlarını çoğaltmak için yapılır. Bu nedenle, çok sayıda silinmiş belge varsa, sunucudan istemciye çoğaltmanız daha uzun sürer. Bunu "veritabanı döndürme" kullanarak engellemenin bir yolu var. Bu, esasen eski silmeleri siler.
3. Çoğaltma sırasını kontrol edemezsiniz. Bununla birlikte, bazı belgeleri ilk almak için filtrelenmiş çoğaltma kullanmak veya hatta doğrudan isteğe bağlı olarak sunucuya erişmek gibi çoğaltma performansını artırmak için bazı akıllı çözümler yapabilirsiniz.
4. Çoğaltma iOS'ta arka planda gerçekleşmeyecek. Bazı arka plan çoğaltması durumlarını sağlamak için iOS SDK'yı kullanabilirsiniz.

Son olarak, CouchDB kullanmak istemiyorsanız, en azından bir HTTP API kullanarak nasıl senkronizasyon algoritması yapabileceğinizi iyi bir referans olarak kullanabilirsiniz. Benim önerim, CouchDB ile başlamak ve daha sonra, özel bir şeye ihtiyacınız olursa, kendi tarzınızı kullanmayı düşünmek olacaktır.