Bot skeneru tokenů Solany se nestává spolehlivým pouze proto, že přijímá živé aktualizace. Spojení končí, požadavky selhávají, zpracování naráží na neznámé záznamy a procesy se restartují mezi přijetím pozorování a jeho uložením. Obnova určuje, zda se tato přerušení stanou viditelnými mezerami, nebo tiše zmizí za zdravě vypadajícím ukazatelem stavu.
Užitečnou otázkou není „připojil se bot znovu?“. Je jí „která pozorování jsou prokazatelně uložena, který rozsah může být neúplný a jaké podklady podporují návrat k běžnému provozu?“. Spojení může být zdravé, zatímco historický záznam zůstává neúplný. Naopak obnovený záznam může být dostatečně úplný pro výzkum ještě před návratem každé pohodlné funkce.
Tento průvodce sleduje pomyslný skener sbírající události související s tokeny pro definovaný soubor. Principy návrhu jsou původní provozní příklady, nikoli tvrzení, že jedna metoda RPC dodává každou událost potřebnou pro úplnou historii tokenu Solany. Každá metoda sběru potřebuje vlastní rozsah a omezení.
Obnova bota skeneru tokenů Solany začíná před selháním
Obnova závisí na záznamech vytvářených během zdravého provozu. Ukládejte identitu pozorování, kontext zdroje, relevantní pozici události, čas přijetí do systému, stav interpretace a kontrolní bod spojený s postupem. Bez těchto informací může restart obnovit provoz, ale nedokáže vysvětlit, co se stalo kolem přerušení.
Oddělujte přijetí od trvalého uložení. Událost krátce držená v paměti může při zastavení procesu zmizet. Kontrolní bod by měl odrážet postup, který systém dokáže po restartu rekonstruovat, nikoli pouze nejnovější zprávu viděnou na spojení. Tento rozdíl často odděluje obnovitelné přerušení od tiché ztráty.
Starší průvodce provozem API Solany popisuje schémata, kvóty a odpovědnosti obnovy. Skener uplatňuje tyto odpovědnosti na pozorování místo pokynů. Potřebuje záznam dokazující, co bylo sesbíráno, a pravidlo postupu, když je tento důkaz neúplný.
Pojmenujte rozsah každého sběrače
Sběrač může pozorovat transakce zahrnující určené adresy, změny účtů pod podporovaným programem nebo události z definovaného seznamu trhů. To jsou různé soubory. Zdravý sběrač by měl vykazovat své pokrytí, aby jeho proces obnovy nenaznačoval širší úplnost, než může jeho odběr nebo dotaz prokázat.
Například historie transakcí souvisejících s adresou není automaticky vyčerpávajícím seznamem všech tokenů vytvořených v síti. Skener tokenů může spojovat několik sběračů, ale každý si zachovává vlastní identitu a pokrytí. Pokud jeden selže, bot by měl určit, která část souboru je dotčena.
Průvodce skenerem nových tokenů Solany vysvětluje, proč časové osy událostí závisí na pozorovaném milníku. Obnova musí tento rozdíl zachovat. Obnovené pozorování poolu nemůže nahradit chybějící podklady o vytvoření mintu pouze proto, že obojí zmiňuje stejné aktivum.
Kurzor bota skeneru tokenů Solany má pravidla zdroje
Kurzor je značka pozice, které rozumí konkrétní zdroj nebo metoda sběru. Není univerzální časovou značkou a neměl by se opakovaně používat napříč nesouvisejícími dotazy. Ukládejte s kurzorem kontext dotazu, včetně sítě, adresy nebo filtru, pravidla potvrzování a verze metody potřebné k jeho interpretaci.
Zdokumentovaná metoda historie podpisů adresy Solany vrací odpovídající podpisy transakcí od novějších ke starším a zpřístupňuje stránkovací pole včetně before a until. To je jeden konkrétní příklad rozhraní historie založeného na kurzoru. Jeho zdokumentovaným rozsahem jsou transakce obsahující dodanou adresu v klíčích účtů. Oficiální dokumentace metody Solany.
Trvalý kontrolní bod skeneru by měl přidávat vlastní význam: které vrácené záznamy byly úspěšně uloženy a zpracovány. Přijetí stránky nedokazuje získání nebo interpretaci každého detailu transakce. Kurzor může posouvat sběr, zatímco samostatné záznamy sledují neúplné obohacování, pokud navazující příjemci tomuto rozdílu rozumějí.
Uložte podklady před posunutím kontrolního bodu
Představte si stránku obsahující deset identifikátorů pozorování. Pokud bot posune kontrolní bod a potom spadne před uložením těchto identifikátorů, příští běh je může přeskočit. Bezpečnější návrh činí trvalá pozorování a aktualizaci kontrolního bodu součástí jedné obnovitelné operace nebo jinak zachovává mezi nimi předání umožňující opětovné přehrání.
Přesná technika ukládání závisí na implementaci. Principem je, že kontrolní bod nesmí vykazovat větší pokrok, než jaký dokládají podklady, které systém dokáže obnovit. Pokud není dostupné atomické uložení, malý deník může zaznamenat zamýšlenou stránku a stav jejího dokončení před posunem hlavního kontrolního bodu.
Tento princip platí také pro interpretaci. Surová pozorování mohou být bezpečně uložena i při selhání zpracování. Kontrolní bod sběru pak může odrážet přijetí, zatímco samostatný kontrolní bod interpretace odráží použitelné záznamy. Směšování obou nutí volit mezi opakovaným stahováním známých dat a předstíráním pochopení nepodporovaného záznamu.
Na hranici očekávejte opětovné přehrání
Konzervativní restart často znovu načítá malý překryv kolem posledního kontrolního bodu. Překryv chrání před nejistotou přesné hranice, ale zaručuje opakovaná pozorování. Bot musí rozpoznávat duplicity bez zahazování skutečně odlišných událostí, které se náhodou týkají stejného tokenu.
Používejte identitu události odpovídající zdroji. Podpis transakce může identifikovat transakci, zatímco více relevantních instrukcí nebo změn účtů uvnitř ní může potřebovat konkrétnější pozice. Schéma identity by mělo vysvětlovat, zda skener ukládá jeden transakční záznam nebo několik odvozených záznamů událostí.
Opakovaná pozorování by měla tam, kde je to vhodné, aktualizovat podklady bez vytváření duplicitních objevení nebo upozornění. Starší průvodce trvalou automatizací na Solaně uvádí související myšlenku o záměrech a opakovaných pokusech. Zde stejný princip chrání sběr: opětovné přehrání pozorování nevytváří novou podkladovou událost.
Uchovávejte neúspěšné interpretace v samostatné frontě
Neznámý záznam by neměl tiše zmizet. Uložte odkaz na surové podklady, verzi zpracování, důvod selhání a další stav posouzení. Některé záznamy lze zkusit znovu po přechodném selhání závislosti. Jiné vyžadují podporu nového formátu nebo ruční šetření nekonzistentních dat.
Neopakujte stále deterministické selhání zpracování, jako by šlo o dočasný síťový problém. Pokud stejné bajty selhávají při stejném zpracování, okamžité opakování pravděpodobně nepomůže. Přesuňte záznam do omezené hodnoticí fronty a dovolte živému sběrači pokračovat, pokud to jeho rozsah umožňuje.
Tato fronta by měla zůstat viditelná ve zprávách o úplnosti. Skener mohl sesbírat každou očekávanou stránku a přesto postrádat použitelné interpretace části historie. Popisujte tento stav jako sesbíráno, ale nevyřešeno. Je informativnější než jediný příznak zdravého stavu skrývající rozdíl mezi uložením a pochopením.
Používejte omezené opakované pokusy skeneru
Pravidlo opakování by mělo určovat, která selhání lze opakovat, kolik pokusů je dovoleno, jak roste prodleva a kdy se bot zastaví nebo problém předá dál. Dočasná selhání přenosu se liší od neplatných požadavků, nepodporovaných odpovědí a vyčerpané dostupnosti historie. Stejné zacházení se všemi plýtvá prostředky a zastírá skutečný problém.
Přidejte proměnlivost do časování opakovaných pokusů, když může mnoho pracovníků selhat společně, aby se všichni neobnovili ve stejném rytmu. Respektujte zdokumentované limity zdroje a případné výslovné pokyny k opakování, které vrací. Nepublikujte univerzální interval opakování, jako by byl správný pro každou metodu, poskytovatele a pracovní zátěž.
Konečný stav selhání potřebuje trvalý záznam. „Opakované pokusy vyčerpány“ by mělo určovat dotčený rozsah dotazu a poslední známý správný bod. Tento záznam umožňuje botu pokračovat v nedotčené práci při zachování nevyřešené mezery. Neomezené pokusy mohou proměnit jeden nedostupný rozsah v trvalé zablokování celého skeneru.
Oddělujte živou práci od doplňování historie
Obnovující se skener může potřebovat zpracovávat živá pozorování při získávání chybějícího intervalu. Tyto proudy mají různou naléhavost a nároky na prostředky. Bez oddělení může velká úloha doplňování zpozdit současný sběr a vytvořit další mezeru během opravy první.
Přidělte každému proudu výslovnou kapacitu a uchovávejte jejich odlišné značky postupu. Systém může po uložení sloučit záznamy podle identity událostí, ale neměl by zaměňovat současný příchod za historický výskyt. Obnovené pozorování ze včerejška není nově vytvořeným tokenem dnes.
Průvodce upozorněními na nové tokeny Solany je na této hranici relevantní. Navazující pravidla oznámení potřebují vědět, zda jsou podklady živé, pozdní nebo zpětně doplněné. Proces obnovy vydávající každou historickou událost jako čerstvé upozornění může čtenáře zahltit a zkreslovat časování objevení.
Označte mezeru před pokusem ji vyplnit
Jakmile bot detekuje přerušení, vytvořte záznam mezery se známou hranicí a dotčeným rozsahem. Přesný koncový bod může být zpočátku nejistý. Tato nejistota by měla být výslovná, nikoli odložená do úspěšné obnovy. Příjemci pak mohou rozhodnout, zda pozastaví interpretace závislé na nepřerušené historii.
Záznam mezery se může zužovat s příchodem podkladů. Může být zcela vyřešený, částečně vyřešený nebo nevyřešený kvůli nedostupnosti požadované historie. To jsou legitimní výsledky. Cílem není nutit každou mezeru do stavu úspěchu, ale udržovat přesný záznam známého.
U hypotetického sběrače může odpojení mezi kontrolními body C120 a C145 zpočátku určovat podezřelý interval. Opětovné přehrání a párování uložených pozorování může prokázat kontinuitu do C138 při ponechání nevyřešeného zbytku. Panel by měl ukazovat tento částečný postup, místo aby po opětovném připojení nahradil celý interval zeleným stavem.
Neodvozujte úplnost z prázdné stránky
Prázdná odpověď může znamenat dosažení zamýšlené hranice dotazu, neexistenci odpovídajících záznamů podle filtru, chybějící požadovanou historii zdroje nebo nesprávný kontext požadavku. Interpretace závisí na zdokumentovaném chování metody a podkladech kolem odpovědi.
Bot by měl ověřit kontext dotazu před prohlášením mezery za vyřešenou. Zkontrolujte, že síť, adresa, úroveň potvrzení a směr stránkování odpovídají uloženému plánu obnovy. Překlep nebo změněný filtr mohou vytvořit technicky úspěšný požadavek, který neříká nic o chybějícím intervalu.
Kde úplnost nelze prokázat, uveďte omezení. Skener může stále poskytovat užitečná částečná pozorování, ale navazující výzkum musí vědět, že historie kandidáta je neúplná. Považovat prázdnou stránku za univerzální důkaz nepřítomnosti vytváří falešnou jistotu právě tam, kde má obnova záznam zlepšovat.
Zpracovávejte nedostupné podrobnosti transakcí
Dotaz na historii může identifikovat transakci, jejíž úplné podrobnosti nejsou ve vybraném kontextu požadavku okamžitě získatelné. Uchovávejte identifikátor a stav získávání podrobností odděleně. Chybějící odpověď s podrobnostmi by se neměla automaticky stát neúspěšnou transakcí nebo neexistující událostí.
Metody transakcí a stavů podpisů Solany zpřístupňují různé formy podkladů. Vyhledání stavu má také zdokumentovaný rozdíl mezi svou nedávnou mezipamětí a volitelným hledáním v historii. Skener by měl používat metodu odpovídající své otázce a uchovávat omezení odpovědi. Dokumentace stavů podpisů Solany.
Pro výzkum může záznam s nevyřešenými podrobnostmi zůstat mimo klasifikaci a přitom stále přispívat k pokrytí sběru. To brání tiché ztrátě nepohodlných pozorování. Pozdější obohacení může dokončit interpretaci v datované revizi bez předstírání, že úplné podklady byly dostupné v původním čase přijetí.
Zachovávejte pořadí bez důvěry v pořadí příchodu
Historické stránky mohou být vraceny v obráceném chronologickém pořadí, zatímco živé zprávy přicházejí s probíhající aktivitou. Skener by měl normalizovat pořadí pomocí relevantních pozic zdroje a zachovávat pořadí příchodu pro provozní analýzu. Ani jedno by nemělo přepisovat druhé.
Když dvě pozorování sdílejí hrubou časovou značku, k jejich rozlišení může být potřebná další identita události. Nevymýšlejte jemně odstupňovanou chronologickou posloupnost pouze proto, že zobrazení potřebuje seřazený seznam. Pokud dostupné podklady prokazují pouze částečné pořadí, zachovejte toto omezení v interpretaci.
To je důležité pro změny pravomocí, vytváření poolů a první pozorované obchody. Průvodce upozorněními na nové mince Solany zvažuje fronty oznámení a platnost; sběrač by měl dodat dostatečný časový kontext, aby tato upozornění neměnila pozdní doručení v nesprávný popis okamžiku podkladových událostí.
Během obnovy prověřte a slaďte předběžná pozorování
Skener přijímající předběžná pozorování před výpadkem se k nim může potřebovat vrátit po opětovném připojení. Některá mohla postoupit do požadovaného stavu jistoty; jiná již nemusí být podpořena. Plán obnovy by měl zahrnovat tuto kontrolu, místo aby předpokládal věčnou platnost všech dříve přijatých zpráv.
Propojujte původní pozorování s jeho pozdějším stavem. Pokud odvozené objevení nebo upozornění záviselo na měnících se podkladech, zaznamenejte opravu a určete dotčené příjemce. Smazání původní události bez vysvětlení ztěžuje provozní hodnocení a může navazujícím systémům ponechat nepodložené závěry.
Vybrané pravidlo potvrzování patří do kontextu kontrolního bodu. Změna tohoto pravidla během obnovy mění význam porovnávaných záznamů. Takové přepnutí může být odůvodněné, ale mělo by vytvořit výslovný přechod v záznamu obnovy, nikoli neviditelné zlepšení zdánlivé jistoty.
Rozpočtujte práci na obnově
Doplňování vyžaduje požadavky, úložiště, interpretaci a čas posuzování. Odhadněte pracovní zátěž předtím, než staré mezeře dovolíte spotřebovat veškerou dostupnou kapacitu. Omezený plán obnovy může určit rozsah, rozpočet požadavků, prioritu a podmínky zastavení a potom vykázat, co bylo v těchto limitech dokončeno.
Uvažujme smyšlený nedodělek 6 000 identifikátorů. Pokud každá hodnoticí dávka obsahuje 200 identifikátorů, práce před obohacením tvoří třicet dávek. Tento výpočet neříká nic o uplynulém čase, protože zpoždění požadavků, limity zdroje a chybějící podrobnosti se mohou lišit. Vykazujte postup v dokončených jednotkách podkladů, místo abyste slibovali univerzální rychlost obnovy.
Pokud nedodělek roste rychleji, než jej bot dokáže zpracovat, reakce může vyžadovat zúžení rozsahu nebo zlepšení kapacity sběru. Opakované restartování stejné doplňovací úlohy nesoulad neřeší. Metriky obnovy by měly odhalovat, zda proces směřuje k úplnosti nebo pouze cyklí mezi pokusy.
Otestujte pád mezi každým důležitým krokem
Smysluplné cvičení obnovy přeruší bota po přijetí, po trvalém uložení, během interpretace a před posunutím kontrolního bodu. U každého přerušení ověřte, které záznamy se po restartu znovu objeví a zda zacházení s duplicitami zachovává jednu logickou událost. Test by měl zkoumat výsledky, nikoli pouze potvrdit opětovné spuštění procesu.
Zahrňte chybný záznam, dočasné selhání zdroje, prázdnou odpověď při nesprávném kontextu dotazu a mezeru, kterou nelze plně obnovit. Žádoucí chování se v každém případě liší. Některé by měly vést k opakování, jiné k izolaci a další by měly ponechat výslovný nevyřešený interval.
Starší průvodce pokrytím skeneru kryptoměnového trhu poskytuje užitečný výzkumný pohled: neúplné pokrytí mění význam užšího seznamu. Testy obnovy tento význam chrání. Skener rychle obnovující provoz, ale tiše ztrácející kandidáty může vypadat provozně úspěšně a přitom podkopávat podporovaný výzkum.
Učiňte kritéria obnovení provozu pozorovatelnými
Návrat k běžnému provozu by měl vyžadovat podklady, nikoli pouze uplynulý čas. Živý sběrač by měl být zdravý podle svých definovaných kontrol, trvalé úložiště aktuální, požadované mezery vyřešené nebo výslovně přijaté a navazující příjemci by měli znát zbývající omezení.
Omezené obnovení může být vhodné. Například současné snímky účtů mohou podporovat pohled na přítomný stav, zatímco starší mezera transakcí stále brání úplné historické analýze. Označujte schopnosti samostatně. Bot by neměl nutit každou funkci sdílet jeden globální zdravotní stav, když se jejich požadavky na podklady liší.
Zaznamenávejte, kdo nebo co přijal nevyřešená omezení a které funkce zůstávají omezené. Jde o provozní rozhodnutí o významu dostupných podkladů. Jeho výslovné uvedení pomáhá dalšímu hodnotiteli pochopit důvod obnovení skeneru a brání pozdějším zprávám předpokládat tehdejší úplnost celé historie.
Proměňte incident v lepší pravidla sběru
Po obnově posuďte nejdříve zjistitelný příznak, hranice mezery, úspěšnou cestu opětovného přehrání a záznamy, které zůstaly nevyřešené. Určete, zda problém vznikl z dostupnosti zdroje, návrhu kontrolního bodu, podpory interpretace nebo nedostatečné kapacity. Každá příčina naznačuje jiné zlepšení.
Výsledná změna by měla být konkrétní. Může přidat trvalý deník stránek, oddělit kontrolní body sběru a interpretace, zlepšit identitu duplicit nebo zpřístupnit stav mezery upozorněním. Vyhněte se vágnímu pokynu sledovat pečlivěji. Příští přerušení by mělo vytvořit lepší podklady, protože se pracovní postup změnil.
Obnova bota skeneru tokenů Solany je dokončená, když systém dokáže vysvětlit svůj záznam včetně zbývajících omezení. Opětovné připojení je jedním krokem tohoto procesu. Trvalá pozorování, kurzory konkrétních zdrojů, omezené opakované pokusy a poctivé stavy mezer umožňují skeneru obnovit provoz bez předstírání, že přerušení nikdy nenastalo.