Die inkrementelle Synchronisierung sollte in der Lage sein, mitten in einer Seite anzuhalten und neu zu starten, ohne dass Beweise verloren gehen. Der schwierige Fall ist nicht der erste erfolgreiche Download. Es handelt sich um die Zeitüberschreitung nach der Speicherung, die doppelte Zustellung nach dem Neustart und den Bericht, der nach Ablauf des scheinbaren Berichtszeitraums eintrifft.
Definieren Sie die Identitätseinheit
Nutzen Sie die dokumentierte Berichtsidentität des Anbieters und behalten Sie dessen Mandanten- und Reporterkontext bei. Es sollte nicht davon ausgegangen werden, dass Berichts-IDs kunden- oder quellenübergreifend global eindeutig sind. Speichern Sie neben der Identität einen Fingerabdruck der Quellnutzlast. Eine identische Wiederholung kann als Duplikat behandelt werden; Dieselbe Identität mit unterschiedlichen Bytes sollte durch ein dokumentiertes Revisionsmodell untersucht oder gehandhabt werden.
RFC 9990 stellt die Struktur und Semantik von bereit aggregierte Berichte. Bewahren Sie die ursprünglichen Berichtsperioden und Empfangszeiten getrennt auf. Das inkrementelle Wasserzeichen eines Sammlers sollte einen historischen Bewertungszeitraum nicht stillschweigend als Ankunftszeitstempel uminterpretieren.
Übermitteln Sie Daten und machen Sie gemeinsam Fortschritte
Rufen Sie eine begrenzte Seite ab, validieren Sie Umfang und Schema, schreiben Sie die normalisierten Daten mit ihrer Herkunft und setzen Sie erst dann den Prüfpunkt fort. Bevorzugen Sie eine Transaktion, die die Daten festschreibt und atomar abläuft. Wenn dies nicht verfügbar ist, entwerfen Sie für die Wiedergabe mit einer stabilen Eindeutigkeitsbeschränkung. Ein Cursor, der gespeichert wird, bevor die Datensätze dauerhaft sind, erzeugt ein Verlustfenster.
Angenommen, ein Collector speichert Seite eins dauerhaft, stürzt jedoch ab, bevor er seinen Fortschrittsmarker vorrückt. Beim Neustart wird die Seite möglicherweise erneut abgerufen. Eine ordnungsgemäß begrenzte stabile Identitätseinschränkung sollte das Hinzufügen exakter Wiederholungen vermeiden und gleichzeitig das Festschreiben der nächsten Seite ermöglichen. Wenn die Fortschrittsmarkierung vorgerückt wäre, bevor die Datensätze dauerhaft waren, könnte der Neustart die Beweise vollständig überspringen. Hierbei handelt es sich um hypothetische Fehlerzustände, nicht um einen ausgeführten Datei- oder Datenbanktest.
Wenn eine wiederholte Identität mit unterschiedlichen Quellbytes eintrifft, bewahren Sie das Original und den Konflikt für eine dokumentierte Revisionsentscheidung auf. Ein geänderter Hash ist ein Signal zur Untersuchung und kein Beweis dafür, dass sich die Nachrichtenanzahl geändert hat: Formatierung oder Normalisierung können sich auch auf Bytes auswirken. Testen Sie die tatsächliche Speichertransaktion, die Wiederherstellung nach einem Absturz und den Quell-Byte-Vergleich unter der genehmigten Implementierung. Diese Anleitung übernimmt keine Haltbarkeitsgarantie.
Gehen Sie mit Verspätung um, ohne Gewissheit zu beanspruchen
Verwenden Sie ein begrenztes Überlappungsfenster, wenn die tatsächliche API die erneute Abfrage von Ankünften unterstützt, und deduplizieren Sie dann nach Identität. Wählen Sie die Überlappung anhand beobachteter Aufnahmeverzögerungen und betrieblicher Anforderungen. Eine endliche Überlappung kann die Entdeckung beliebig später Daten nicht garantieren. Fügen Sie einen regelmäßigen vollständigen Abgleich oder einen anderen dokumentierten Backfill-Mechanismus hinzu und erfassen Sie die verbleibende Deckungsbegrenzung.
Halten Sie Änderungen von exakten Duplikaten fern. Behalten Sie beide Hashes bei Konflikten bei und verhindern Sie, dass ein ungeklärter Ersatz einen bereits ausgestellten Kundenbericht stillschweigend ändert. Berechnen Sie betroffene Zusammenfassungen unter einer neuen Revision neu, wenn eine gültige Korrektur akzeptiert wird, mit einer Rückverfolgung zum vorherigen Ergebnis.
Wiederherstellung im Rahmen des echten Servicevertrags
Beachten Sie Ratenbeschränkungen, Retry-After und versionspezifische Paginierung. Best Practices für die API von GitHub Bieten Sie ein konkretes Beispiel für begrenztes, rücksichtsvolles Anfrageverhalten. Sie definieren nicht die Kontingente eines Authentifizierungsanbieters. Behandeln Sie einen 429-Fehler oder einen vorübergehenden Fehler als Grund für eine Pause und einen erneuten Versuch innerhalb der Richtlinie, nicht als Erlaubnis für unbegrenzte parallele Anfragen.
Überwachen Sie den letzten erfolgreichen Kontrollpunkt, den ältesten nicht verarbeiteten Eingang, die Erschöpfung der Wiederholungsversuche und Konflikte. Eine fehlerfreie API-Antwort mit einem hängengebliebenen Cursor ist immer noch eine fehlgeschlagene Synchronisierung. Überprüfen Sie bei einem mehrdeutigen Ergebnis die gespeicherten Identitäten und den Fortschritt, bevor Sie einen Schritt mit Nebenwirkung wiederholen. Behalten Sie Quellbytes und den vorherigen Prüfpunkt bei, damit die Wiederherstellung nachweislich erfolgt. Hier wird kein API-Aufruf, keine Wiederholungssimulation oder EmailAuth Synchronisierungsfunktion demonstriert. GitHubs Ratenlimit-Dokumentation stellt fest, dass für Ratenbegrenzungen möglicherweise sowohl 403 als auch 429 zurückgegeben werden; zwischen dokumentierten Grenzwertsignalen und permanenter Berechtigungsverweigerung unterscheiden, anstatt jedem Status eine Bedeutung zuzuordnen.