Synchronizacja przyrostowa powinna umożliwiać zatrzymanie się w połowie strony i ponowne uruchomienie bez utraty dowodów. Trudny przypadek nie jest pierwszym udanym pobraniem. Jest to limit czasu po przechowywaniu, zduplikowane dostarczenie po ponownym uruchomieniu i raport otrzymany po zakończeniu widocznego okresu raportowania.
Zdefiniuj jednostkę tożsamości
Użyj udokumentowanej tożsamości raportu dostawcy i zachowaj kontekst dzierżawy i osoby zgłaszającej. Nie należy zakładać, że identyfikatory raportów są globalnie unikalne dla różnych klientów lub źródeł. Przechowuj odcisk palca ładunku źródłowego obok tożsamości. Identyczne powtórzenie można potraktować jako duplikat; tę samą tożsamość z różnymi bajtami należy zbadać lub rozwiązać za pomocą udokumentowanego modelu wersji.
RFC 9990 zapewnia strukturę i semantykę raporty zbiorcze. Zachowaj oddzielnie oryginalne okresy raportowania i czasy odbioru. Przyrostowy znak wodny kolekcjonera nie powinien po cichu reinterpretować historycznego okresu oceny jako znacznika czasu przybycia.
Wspólnie przekazuj dane i postępuj
Pobierz ograniczoną stronę, sprawdź zakres i schemat, zapisz znormalizowane dane z ich pochodzeniem i dopiero wtedy przejdź do punktu kontrolnego. Preferuj transakcję, która zatwierdza dane i postępuje atomowo. Jeśli jest to niedostępne, zaprojektuj pod kątem powtórki ze stabilnym ograniczeniem niepowtarzalności. Kursor zapisany przed utrwaleniem rekordów tworzy okno straty.
Załóżmy, że kolekcjoner trwale przechowuje pierwszą stronę, ale ulega awarii przed przesunięciem znacznika postępu. Po ponownym uruchomieniu może ponownie pobrać stronę. Stabilne ograniczenie tożsamości o odpowiednim zakresie powinno unikać dodawania dokładnych powtórzeń, jednocześnie umożliwiając zatwierdzenie następnej strony. Jeśli znacznik postępu przesunął się, zanim zapisy były trwałe, ponowne uruchomienie mogłoby całkowicie pominąć dowody. Są to hipotetyczne stany awarii, a nie wykonany test pliku lub bazy danych.
Jeśli pojawi się powtarzająca się tożsamość z różnymi bajtami źródłowymi, zachowaj oryginał i konflikt na potrzeby udokumentowanej decyzji o rewizji. Zmieniony skrót jest sygnałem do zbadania, a nie dowodem na zmianę liczby wiadomości: formatowanie lub normalizacja może również wpływać na bajty. Przetestuj rzeczywistą transakcję przechowywania, odzyskiwanie po awarii i porównanie bajtów źródłowych w ramach zatwierdzonej implementacji; niniejszy przewodnik nie zapewnia żadnej gwarancji trwałości.
Radź sobie ze spóźnieniami, nie żądając pewności
Użyj ograniczonego okna nakładania się, gdy rzeczywisty interfejs API obsługuje ponowne wysyłanie zapytań o przychodzące dane, a następnie wykonaj deduplikację według tożsamości. Wybierz nakładanie się, korzystając z zaobserwowanych opóźnień w przetwarzaniu i potrzeb operacyjnych. Skończone nakładanie się nie może zagwarantować wykrycia arbitralnie spóźnionych danych. Dodaj okresowe pełne rozliczenie lub inny udokumentowany mechanizm uzupełniania i zapisz pozostałe ograniczenie pokrycia.
Należy odróżniać poprawki od dokładnych duplikatów. Zachowaj oba skróty w przypadku konfliktu i zapobiegnij niewyjaśnionej wymianie, która spowoduje cichą zmianę już wydanego raportu klienta. Przelicz ponownie podsumowania, których to dotyczy, w ramach nowej wersji, gdy zostanie zaakceptowana ważna poprawka, z odniesieniem do poprzedniego wyniku.
Odzyskaj w ramach prawdziwej umowy serwisowej
Przestrzegaj limitów szybkości, ponów próbę i paginację specyficzną dla wersji. Najlepsze praktyki API GitHuba podać konkretny przykład ograniczonego, rozważnego zachowania w zakresie żądań; nie definiują limitów dostawcy uwierzytelniania. Traktuj błąd 429 lub przejściowy błąd jako powód do wstrzymania i ponowienia próby w ramach zasad, a nie jako pozwolenie na nieograniczoną liczbę równoległych żądań.
Monitoruj ostatni pomyślny punkt kontrolny, najstarsze nieprzetworzone przybycie, wyczerpanie ponownych prób i konflikty. Prawidłowa odpowiedź interfejsu API z zablokowanym kursorem nadal oznacza nieudaną synchronizację. W przypadku niejednoznacznego wyniku sprawdź przechowywane tożsamości i postęp przed ponowną próbą wykonania kroku ubocznego. Zachowaj bajty źródłowe i poprzedni punkt kontrolny, aby odzyskiwanie opierało się na dowodach. Nie pokazano tutaj żadnego wywołania API, symulacji ponownej próby ani możliwości synchronizacji EmailAuth . Dokumentacja dotycząca limitów szybkości GitHuba zauważa, że może zwrócić 403 i 429 w przypadku limitów stawek; odróżniaj udokumentowane sygnały graniczne od trwałej odmowy autoryzacji, zamiast przypisywać każdemu statusowi jedno znaczenie.