Jakie są typowe pułapki synchronizacji opartej na znacznikach czasu?

Implementuję mój pierwszy kod synchronizacji. W moim przypadku będę miał 2 typy klientów iOS na użytkownika, który zsynchronizuje rekordy z serwerem za pomocą lastSyncTimestamp, 64-bitowa liczba całkowita reprezentująca epokę Uniksa w milisekundach ostatniej synchronizacji. Rekordy mogą być tworzone na serwerze lub klientach w dowolnym momencie, A rekordy są wymieniane jako JSON przez HTTP.

Nie martwię się konfliktami, ponieważ jest kilka aktualizacji i zawsze od tego samego użytkownika. Zastanawiam się jednak, czy istnieją powszechne rzeczy, które muszę być tego świadomy, mogą pójść nie tak z podejściem opartym na znaczniku czasu, takim jak synchronizacja w czasie letnim, synchronizacja sprzeczna z innym lub innymi gotchas.

Wiem, że git i jakiś inny system kontroli wersji unikają synchronizacji ze znacznikami czasu w celu synchronizacji negocjacji opartych na zawartości. Mogę sobie wyobrazić takie podejście również dla moich aplikacji, gdzie używając uuid lub hash obiektów, obaj rówieśnicy ogłaszają, które obiekty są ich właścicielami, a następnie wymieniają je do czasu, aż obie pary mają te same zestawy.

Jeśli ktoś zna jakieś zalety lub wady synchronizacji opartej na treści w porównaniu z synchronizacją opartą na znacznikach czasu, byłoby to również pomocne.

Edytuj - Oto niektóre z zalet / wad, które wymyśliłem dla znacznika czasu i synchronizacji opartej na treści. Proszę zakwestionować / popraw.

Uwaga - definiuję synchronizację opartą na zawartości jako prostą negocjację 2 zestawów obiektów, takich jak 2 dzieci wymień karty, jeśli dałeś im każdą część pomieszanego stosu 2 identycznych zestawów kart baseballowych i powiedział im, że gdy przeglądają je, aby ogłosić i przekazać duplikaty, które znaleźli drugiej, dopóki obie nie mają identycznych zestawów.

  • Johnny - " mam tę kartkę."
  • Davey - " mam tę kupę kartek. Daj mi tę kartkę."
  • Johnny - " Oto Twoja wizytówka. Daj mi te kartki."
  • Davey - " Oto Twoja Banda karty."
  • ....
  • oba - "we are done"

Zalety synchronizacji opartej na znaczniku czasu

  • łatwy do wdrożenia
  • pojedyncza właściwość używana do synchronizacji.

Wady synchronizacji opartej na znacznikach czasu

  • Czas jest pojęciem względnym wobec obserwatora i różne zegary maszyny mogą być zsynchronizowane. Jest kilka sposobów na rozwiązanie tego problemu. Generowanie znacznika czasu na jednej maszynie, która nie skaluje się dobrze i reprezentuje jeden punkt awarii. Lub użyć zegarów logicznych, takich jak zegary wektorowe. Dla przeciętnego dewelopera budującego własny system, Zegary wektorowe mogą być zbyt skomplikowane do wdrożenia.
  • synchronizacja oparta na znacznikach czasu działa dla synchronizacji Master od klienta do mistrza, ale nie działa tak dobrze dla synchronizacji peer to peer lub gdzie synchronizacja może wystąpić z 2 Master.
  • pojedynczy punkt awarii, niezależnie od tego, który wygeneruje znacznik czasu.
  • Czas nie jest tak naprawdę związany z treścią tego, co jest synchronizacja.

Zalety synchronizacji opartej na treści

  • żaden znacznik czasu peer nie musi być utrzymywany. 2 rówieśnicy mogą rozpocząć sesję synchronizacji i rozpocząć synchronizację na podstawie zawartości.
  • dobrze zdefiniowany punkt końcowy do synchronizacji-gdy obie strony mają identyczne zestawy.
  • pozwala architekturze peer to peer, gdzie każdy peer może działać jako klient lub serwer, pod warunkiem, że może hostować serwer HTTP.
  • Sync działa z zawartością zestawów, a nie z abstrakcyjny czas pojęć.
  • ponieważ synchronizacja jest zbudowana wokół zawartości, synchronizacja może być używana do weryfikacji zawartości w razie potrzeby. Na przykład hash SHA-1 może być obliczany na zawartości i używany jako uuid. Można go porównać z tym, co jest wysyłane podczas synchronizacji.
  • co więcej, skróty SHA-1 mogą być oparte na poprzednich hashach, aby zachować spójną historię treści.

Wady synchronizacji opartej na treści

  • Dodatkowe właściwości na Twoich obiektach mogą być potrzebne do wdrożenia.
  • więcej logiki po obu stronach w porównaniu do synchronizacji opartej na znacznikach czasu.
  • nieco bardziej gadatliwy protokół (może być dostrojony przez synchronizację treści w klastrach).
Author: John Wright, 2010-11-15

3 answers

Nie wiem czy to ma zastosowanie w Twoim środowisku, ale może zastanów się czyj czas jest "właściwy", klient czy serwer (lub czy to w ogóle ma znaczenie)? Jeśli wszystkie klienty i wszystkie serwery nie są zsynchronizowane z tym samym źródłem czasu, może istnieć możliwość, jakkolwiek niewielka, uzyskania przez Klienta nieoczekiwanego wyniku podczas synchronizacji z (lub z) serwerem za pomocą czasu "teraz" klienta.

Nasza organizacja rozwoju rzeczywiście napotkał pewne problemy z tym kilka lat temu. Programista maszyny nie były zsynchronizowane z tym samym źródłem czasu, co serwer, na którym znajdował się SCM (i nie mogły być zsynchronizowane z żadnym źródłem czasu, więc czas maszyny programistycznej mógł dryfować). Maszyna programisty może być kilka minut off po kilku miesiącach. Nie przypominam sobie wszystkich problemów, ale wygląda na to, że proces budowania próbował zmodyfikować wszystkie pliki od pewnego czasu (ostatnia kompilacja). Pliki mogły być sprawdzane, od ostatniej kompilacji, które miały czasy modyfikacji (od klienta), które miały miejsce przed ostatnią kompilacją.

Możliwe, że nasze procedury SCM nie były zbyt dobre, lub że nasz system SCM lub proces budowania były nadmiernie podatne na ten problem. Nawet dzisiaj wszystkie nasze maszyny programistyczne mają synchronizować czas z serwerem, na którym znajduje się nasz system SCM.

Ponownie, to było kilka lat temu i nie pamiętam szczegółów, ale chciałem wspomnieć o tym, że jest to istotne w Twoim przypadku.

 2
Author: wageoghe,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-11-15 17:24:34

Problem polega na tym, że czas nie jest pojęciem absolutnym. To, czy coś dzieje się przed czy po czymś innym, jest kwestią perspektywy, a nie zgodności z zegarem ściennym.

Przeczytaj trochę o względności symultaniczności , aby zrozumieć, dlaczego ludzie przestali używać czasu ściennego do rozgryzania tych rzeczy i przenieśli się do konstrukcji, które reprezentują rzeczywistą przyczynowość za pomocą zegarów wektorowych (lub przynajmniej zegarów Lamport ).

Jeśli chcesz użyć zegara do synchronizacji, zegar logiczny prawdopodobnie najbardziej Ci odpowiada. Unikniesz wszystkich problemów z synchronizacją zegara i innych rzeczy.

 7
Author: Dustin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-11-15 17:31:43

Możesz spojrzeć na unison . Jest oparty na plikach, ale niektóre pomysły mogą Cię zainteresować.

 0
Author: Karl,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-11-20 00:17:33