İki yönlü senkronizasyon için çakışma çözümü


24

Bir bağlantının her zaman mümkün olmadığı varsayılarak, 'ana' veritabanı sunucusu ile birçok 'ikincil' sunucu arasında, özellikle de uyuşmazlık çözümü arasında iki yönlü senkronizasyonu nasıl yönetirsiniz?

Örneğin, iOS'ta 'veritabanı' olarak CoreData kullanan ve kullanıcıların içeriği Internet bağlantısı olmadan düzenlemelerine izin vermek istiyorum. Aynı zamanda, bu bilgiler cihazların bağlanacağı bir web sitesinde bulunabilir. İki DB sunucusundaki veriler çakışıyorsa / ne yapmalıyım?
(CoreData'ya bir DB sunucusu olarak bakıyorum, bunun biraz farklı bir şey olduğunun farkındayım.)

Bu tür bir sorunla başa çıkmanın genel stratejileri var mı? Aklıma gelen seçenekler şunlardır:
1. Her zaman müşteri tarafı verilerini yüksek öncelikli olarak kullan
2. Sunucu tarafı için aynı
3. Her alanın düzenleme zaman damgasını işaretleyerek ve en son düzenlemeyi alarak çatışmaları çözmeye çalışın

Yine de 3. seçeneğin bazı yıkıcı veri bozulmalarına yer açacağından eminim.

CAP teoreminin bu konuyla ilgili olduğunun farkındayım, ama sadece nihai tutarlılığı istiyorum, bu yüzden tamamen dışlamaz.

İlgili soru: İki yönlü veri senkronizasyonu için en iyi uygulama modelleri . Bu sorunun ikinci cevabı muhtemelen yapılamadığını söylüyor.


Yanıtlar:


14

Hangi değişimin doğru olduğunu bilmek için bilinen çözüm bir vektör saatidir . Esasen, verileri tutan her bir depo için sayaçları takip etmekte ve belirli bir müşterinin başkalarının durumuyla ilgili görüşlerinin, bağlı olduğu akrandan farklı olması durumunda değişiklikleri reddetmektesiniz.

Cevaplamanız gereken en büyük soru, reddedilen tasarrufları nasıl çözeceğinizdir. Bu genellikle bir çeşit birleştirme işlemi anlamına gelir.

Vektör saatleri geldiğini hatırlatırız yok gerçek zamanlı damgalarını kullanın. Gerçek zamanlı saatleri senkronize etmedeki sorunlar en azından veri senkronizasyonu kadar zordur.


1
Güzel, aradığım şey buydu
K.Steff

10

Bu, çözülemeyen Bizans Generalleri sorunudur. Gelecekte bir zamanda senkronizasyonu tek seferde yapmak için yeterli güvenilir bant genişliğine sahip olacağınızı garanti edemezseniz, iki sunucuyu senkronize etmeyi asla garanti edemezsiniz .


Tamam, ama bu adamlar nasıl benzer bir etki yaratırlar
K.Steff

3
Onlar sadece gelecekte bir zamanlar yeterli bant genişliği ile güvenilir bir bağlantınız olacağını varsayıyorlar.
DeadMG

1

Sanırım bunu yapmanın standart bir yolu yok, her sistem uyuşmazlık çözümü için kendi politikalarını kullanıyor.

Google Dokümanlar'ın çakışmaları otomatik olarak nasıl ele aldığını kontrol etmek için iki cihaz, bilgisayar ve telefon ve Google E-Tablo kullanarak bazı simülasyonlar yaptım. İşte bazı durumlar:

Dava 1

  1. Bilgisayar ve telefon çevrimdışı
  2. Bilgisayar, 'bilgisayar' değerine sahip hücreyi düzenledikten sonra
  3. Bilgisayar çevrimiçi oldu
  4. Telefon çevrimiçi olur ve hem bilgisayar hem de telefon 'telefon' görüntüler.

Durum 2

  1. Bilgisayar ve telefon çevrimdışı
  2. Bilgisayar, 'bilgisayar' değerine sahip hücreyi düzenledikten sonra
  3. Telefon çevrimiçi oldu
  4. Bilgisayar çevrimiçi olur ve hem bilgisayar hem de telefon 'bilgisayar' görüntüler.

Bu nedenle, en azından Google Dokümanlar sunucusu, aldığı zamandan bağımsız olarak daha yüksek öncelikli olarak aldığı son verileri kullanır (müşterinin zaman damgası). Ayrıca arka planda eşitleme yapıp yapmadıklarını test ettim ve görünüşe göre yapmıyorlar, bu yüzden uyuşmazlık çözümünün sonucu kullanıcı için şeffaf.

Öte yandan, GIT, otomatik olarak çatışmaları işlemez, ancak bunun yerine, birleştirme işleminin nasıl yapılması gerektiğini depoya değiştirmeye çalışan son kullanıcıya delege gönderir.

Verileri görselleştiren kullanıcıyla yalnızca ön planda senkronizasyon yapılması uygunsa Google Dokümanlar yaklaşımına giderim. Aksi halde, bir kullanıcı telefonunu otomatik olarak bir WiFi'ye bağlarken, PC'sinde yeniden düzenlendikten sonra bir toplantıda senkronize olmayan bir değişiklik yapılmasının değişmesi şaşırtıcı olabilir.

Arka plan senkronizasyonuna ihtiyacınız varsa, müşteri zaman damgasına güvenebilir ve istenmeyen bir birleştirme maliyetinin kullanıcıdan istediği sürümü seçmesini isteme maliyetinden daha düşük olması durumunda, müşteri zaman damgası yaklaşımı için giderdim saklamak.

Aksi taktirde, GIT yaklaşımına gidecektim, bir sonraki istemcide ön plandaki bir açılır pencereyi göstererek, kullanıcının hangi sürümü tutacağını seçmesini ya da birleştirme işlemini geri alma şansı vermesini istemiştim.


1
Vaka bazında bir yaklaşımın buraya gitmek için uygun yol olduğuna katılıyorum. "En iyi" yol (git yaklaşımı) her zaman geçerli değildir, çünkü kullanıcılar değişiklikleri incelemek / birleştirmek istemeyebilir
K.Steff
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.