Přeskočit na obsah

Příjem dat

Dokument je kontrakt, který musí implementace splnit — hlavička to říká rovnou: klient feedu zatím neexistuje. Popisuje smyčku, sedm invariantů a aritmetiku denního limitu, ze které plyne, jak rychle vůbec může backfill doběhnout.

Stav
plánováno — položky 1.1 až 1.4 fáze 1 nejsou zahájené
Vlastnictví feedu
právě jeden poller, Redis lease s TTL
Checkpoint
posune se jen ve stejné transakci jako zápis akcí
Limity
kontrolované před síťovým voláním, konfigurovatelné jen přísněji
Cíl zpoždění
událost zpracovaná do 24 hodin

Smyčka

Sedm invariantů a proč na nich záleží

PravidloProč
Feed vlastní právě jeden pollersouběžné pollery duplikují práci a závodí o checkpoint
Zápis akcí a posun checkpointu v jedné transakcipád mezi tím buď znovu stáhne (bezpečné), nebo přeskočí (ztráta dat)
Zápisy jsou idempotentní podle id akceznovu stažená dávka musí být no-op, ne duplikát
Checkpoint necouvá bez zásahu operátoracouvnutí je operace z runbooku, ne vedlejší efekt
Limity se kontrolují před odesláním požadavkureagovat až na HTTP 429 je už porušení provozních podmínek
Chyba parsování nikdy neposune checkpointtiché přeskočení dávky je neviditelná ztráta dat
Akce se nikdy nemění ani nemažoureplika je zdroj pravdy; opravy patří na stranu projektoru

Backfill, živý provoz a jeden strop

Obojí obsluhuje stejná cesta kódem, liší se jen počáteční checkpoint. Živý provoz startuje na aktuální hladině a jede na cronu, backfill startuje na dolní hranici fáze (pro MVP 1. 1. 2018) a jede na denní rozpočet, dokud nedožene.

Aritmetika, kterou je nutné udělat před návrhem backfillu: 3000 požadavků denně při nabízené velikosti stránky je tvrdý strop rychlosti přehrání historie. Plán fázování v specifikaci existuje kvůli tomuhle číslu, ne navzdory jemu.

Backfill a živý provoz nesmí běžet současně proti témuž checkpointu. Buď doběhne backfill a živý provoz naváže, nebo mají oddělené checkpointy a lease — a to druhé si vyžádá ADR.

Přehrání a metriky

Přestavba projekce přehraje uložené akce od začátku. Nic nestahuje a nic znovu nevytěžuje, protože výsledky extrakce jsou v cache podle hashe dokumentu. Proto je přehrání běžná reakce na chybu v projektoru, ne krizová operace; postup je v runbooku.

Sledované metriky jsou zpoždění za rejstříkem, aktuální id checkpointu, průchodnost, důvody selhání ze zavřeného slovníku, stav breakeru a zbývající rozpočet požadavků. Žádný label nikdy nenese spisovou značku, jméno ani osobní údaj.

Kde to v repozitáři žije

Souvisí

Zpět na sekci Dokumentace