Pierwszą rzeczą, którą musisz zdecydować, jest ogólna polityka dotycząca tego, która strona jest uważana za „autorytatywną” w przypadku sprzecznych zmian.
To znaczy: załóżmy, że rekord # 125 jest zmieniany na serwerze 5 stycznia o godzinie 22:00, a ten sam rekord jest zmieniany na jednym z telefonów (nazwijmy go Klientem A) 5 stycznia o godzinie 23:00. Ostatnia synchronizacja miała miejsce 3 stycznia. Następnie użytkownik łączy się ponownie, powiedzmy 8 stycznia.
Zidentyfikowanie tego, co należy zmienić, jest „łatwe” w tym sensie, że zarówno klient, jak i serwer znają datę ostatniej synchronizacji, więc wszystko, co zostało utworzone lub zaktualizowane (więcej informacji na ten temat poniżej) od ostatniej synchronizacji, musi zostać uzgodnione.
Załóżmy więc, że jedyny zmieniony rekord to # 125. Możesz zdecydować, że jedna z dwóch automatycznie „wygrywa” i nadpisuje drugą, albo musisz obsługiwać fazę uzgadniania, w której użytkownik może zdecydować, która wersja (serwer lub klient) jest właściwa, nadpisując drugą.
Ta decyzja jest niezwykle ważna i trzeba wyważyć „rolę” klientów. Zwłaszcza jeśli istnieje potencjalny konflikt nie tylko między klientem a serwerem, ale w przypadku, gdy różni klienci mogą zmienić te same rekordy.
[Zakładając, że numer 125 może zostać zmodyfikowany przez drugiego klienta (klienta B), istnieje szansa, że klient B, który nie został jeszcze zsynchronizowany, dostarczy kolejną wersję tego samego rekordu, co spowoduje, że poprzednie rozwiązanie konfliktu będzie dyskusyjne]
Odnośnie do punktu „ utworzonego lub zaktualizowanego ” powyżej ... jak można prawidłowo zidentyfikować rekord, jeśli został on utworzony na jednym z klientów (zakładając, że ma to sens w domenie, w której występuje problem)? Załóżmy, że Twoja aplikacja zarządza listą kontaktów biznesowych. Jeśli Klient A mówi, że musisz dodać nowo utworzonego Johna Smitha, a serwer ma John Smith utworzony wczoraj przez Klienta D… czy tworzysz dwa rekordy, ponieważ nie możesz być pewien, że nie są to różne osoby? Czy poprosisz użytkownika również o pogodzenie tego konfliktu?
Czy klienci mają „własność” podzbioru danych? To znaczy, jeśli Klient B jest ustawiony jako „organ” w zakresie danych dla Obszaru 5, czy Klient A może modyfikować / tworzyć rekordy dla Obszaru 5, czy nie? (Ułatwiłoby to niektóre konflikty, ale może okazać się niewykonalne w twojej sytuacji).
Podsumowując, główne problemy to:
- Jak zdefiniować „tożsamość”, biorąc pod uwagę, że odłączeni klienci mogli nie uzyskać dostępu do serwera przed utworzeniem nowego rekordu.
- Poprzednia sytuacja, bez względu na to, jak skomplikowane jest rozwiązanie, może skutkować duplikacją danych, więc musisz przewidzieć, jak okresowo je rozwiązywać i jak informować klientów, że to, co uważali za „Rekord nr 675”, zostało faktycznie połączone z / zastąpione przez Rekord # 543
- Zdecyduj, czy konflikty zostaną rozwiązane przez fiat (np. „Wersja serwera zawsze ma pierwszeństwo przed wersją klienta, jeśli poprzednia została zaktualizowana od czasu ostatniej synchronizacji”) lub przez interwencję ręczną
- W przypadku fiat , zwłaszcza jeśli uznasz, że klient ma pierwszeństwo, musisz również zadbać o to, jak radzić sobie z innymi, jeszcze niezsynchronizowanymi klientami, którzy mogą mieć więcej zmian.
- Poprzednie pozycje nie uwzględniają szczegółowości danych (w celu ułatwienia opisu). Wystarczy powiedzieć, że zamiast rozumowania na poziomie „rekordu”, jak w moim przykładzie, bardziej odpowiednie może być zapisanie zmian na poziomie pola. Lub pracować na zbiorze rekordów (np. Rekord osoby + rekord adresu + rekord kontaktów) w tym samym czasie, traktując ich agregat jako rodzaj „meta rekordu”.
Bibliografia:
Więcej na ten temat oczywiście w Wikipedii .
Prosty algorytm synchronizacji autorstwa autora Vdirsyncer
Artykuł OBJC dotyczący synchronizacji danych
SyncML®: synchronizacja i zarządzanie danymi mobilnymi ( zarezerwuj na O'Reilly Safari)
Wolne od kon iktów replikowane typy danych
Optymistyczna replikacja YASUSHI SAITO (HP Laboratories) i MARC SHAPIRO (Microsoft Research Ltd.) - ACM Computing Surveys, Vol. V, nr N, 3 2005.
Alexander Traud, Juergen Nagler-Ihlein, Frank Kargl i Michael Weber. 2008. Cykliczna synchronizacja danych poprzez ponowne użycie SyncML. W obradach dziewiątej międzynarodowej konferencji nt. Mobilnego zarządzania danymi (MDM '08). IEEE Computer Society, Washington, DC, USA, 165-172. DOI = 10.1109 / MDM.2008.10 http://dx.doi.org/10.1109/MDM.2008.10
Lam, F., Lam, N. i Wong, R. 2002. Efektywna synchronizacja mobilnych danych XML. W materiałach z jedenastej międzynarodowej konferencji nt. Informacji i zarządzania wiedzą (McLean, Virginia, USA, 04 - 09 listopada 2002). CIKM '02. ACM, Nowy Jork, NY, 153–160. DOI = http://doi.acm.org/10.1145/584792.584820
Cunha, PR i Maibaum, TS 1981. Resource & equil; abstrakcyjny typ danych + synchronizacja - Metodologia programowania zorientowanego na komunikaty -. W materiałach z V Międzynarodowej Konferencji Inżynierii Oprogramowania (San Diego, Kalifornia, Stany Zjednoczone, 9-12 marca 1981). Międzynarodowa konferencja nt. Inżynierii oprogramowania. IEEE Press, Piscataway, NJ, 263-272.
(Ostatnie trzy pochodzą z biblioteki cyfrowej ACM, nie mam pojęcia, czy jesteś jej członkiem lub czy możesz je zdobyć za pośrednictwem innych kanałów).
Z witryny Dr.Dobbs :
- Tworzenie aplikacji za pomocą SQL Server CE i SQL RDA - Bill Wagner 19 maja 2004 (Najlepsze praktyki projektowania aplikacji na komputer stacjonarny i komputer przenośny - Windows / .NET)
Z arxiv.org:
- A Conflict-Free Replicated JSON Datatype - artykuł opisuje implementację JSON CRDT (bezkonfliktowe replikowane typy danych - CRDT - to rodzina struktur danych, które obsługują równoczesną modyfikację i gwarantują konwergencję takich równoległych aktualizacji).