Verificarea backlinkurilor unei pagini prin API și cache-ul onest
Indexul nostru se actualizează o dată pe lună, astfel încât majoritatea interogărilor pot fi servite din memorie. O rețetă pentru cache-uri care economisește credite fără a afișa utilizatorilor minciuni învechite.
Echipa editorială AlfaLinks ·
Regula
Cache până la următoarea reîmprospătare a indexului, nu pentru o oră fixă
Deoarece datele se schimbă aproximativ lunar, un TTL orar nu îți aduce niciun beneficiu, ci doar costuri. O cheie scoped pe lună oferă același răspuns toată luna și se invalidează printr-o singură mișcare.
Cheie: acțiune + domeniu + parametri + luna indexului
TTL: până la sfârșitul lunii, plus o zi de grație
Nu cache-uia niciodată un răspuns de eroare
De ce un TTL scurt este doar o donație pentru soldul tău de credite
Echipele noi în datele de linkuri copiază obiceiurile de la trackerele de poziții. Obiceiul unu: un cache orar, deoarece pozițiile se schimbă. Graficele de linkuri se schimbă foarte rar.
O apelare backlinks de 2 credite costă $0.0002. Sună a nimic până când o vizualizare listă declanșează 50 de astfel de apeluri pe fiecare încărcare de pagină, pentru 400 de spații de lucru active, repetând la fiecare oră pentru aceleași răspunsuri.
Numerele calculate mai jos sunt un exemplu, nu o măsurătoare a traficului cuiva. Presupune 400 de spații de lucru, 20 de vizualizări de domeniu fiecare pe zi, 2 credite pe vizualizare și un cache de 1 oră care are succes poate o dată din cinci. Majoritatea vizualizilor ating încă API-ul. Cu o cheie pe lună, același trafic ar atinge API-ul doar o dată pe domeniu și lună, astfel încât diferența este punctul central al rețetei.
Uneltele de cercetare a cuvintelor cheie au nevoie de date mai proaspete, iar pentru acestea, suitele mari rămân alegerea mai bună. Pentru contextul linkurilor, lunar este produsul.
TTL per acțiune
Sugerat, nu impus. Toate acțiunile citesc același index lunar.
Acțiune
Credite
TTL sugerat
De ce
prezentare generală, statistici
0
Până la sfârșitul lunii
Gratuit, dar serverul tău economisește totuși latență
bulk_dr
1
Până la sfârșitul lunii
Întreaga tabelă a clienților într-un singur apel
refdomains, backlinks
2
Până la sfârșitul lunii, per parametrul de pagină
Include pagina, per, sort în cheie
anchors, toppages
2
Până la sfârșitul lunii
Stabil între reîmprospătări
search, keyword
3
7 zile
Rar repetat, ieftin să sari peste cache
Exemplu de cerere: încălzirea cache-ului pentru o tabelă de clienți
Apelă bulk_dr o dată per client, nu o dată pe rând. Până la 2.000 de domenii încap într-un singur corp POST și costă un credit.
bash
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count
Construiește cache-ul în cinci pași
Fiecare pas are o singură sarcină. Sari peste unul și eroarea va apărea mai târziu, de obicei sub forma unei facturi.
01
Alege cheia
Folosește acțiunea, domeniul, parametrii de paginare și sortare, și luna indexului. Exclude orice lucru pe care un utilizator îl poate schimba fără a modifica răspunsul, cum ar fi o culoare de afișare sau un nume de tab.
02
Stoarcă răspunsul analizat
Păstrează JSON-ul decodat cu flag-ul ok și datele, nu bytes-urile brute. O vizualizare ulterioară poate reconstrui apoi întreaga tabelă din memorie fără un al doilea apel.
03
Expiră la sfârșitul lunii
Setează expirarea la sfârșitul lunii indexului, plus ziua de grație din regula de mai sus. Folosește aceeași regulă pentru fiecare acțiune, astfel încât logica să existe într-o singură funcție și nu în cinci locuri.
04
Loghează soldul la fiecare apel
Citește obiectul _credits de pe fiecare răspuns autentificat și scrie soldul rămas în propriul tău log. O scădere lentă a acelei linii este adesea primul semn că o cheie de cache este greșită.
05
Urmărește rata de hit
Urmărește de câte ori o vizualizare este servită din cache. O rată scăzută înseamnă că cheia este prea specifică, sau că utilizatorii deschid un domeniu nou la fiecare vizită. Orice dintre aceste descoperiri este utilă când îți planifici bugetul.
Sunt datele învechite o alegere de produs sau un bug?
Un număr de linkuri poate avea o lună și totuși să fie corect pentru indexul din care provine. Întrebarea reală este dacă ecranul tău o spune. Majoritatea tichetelor de suport despre numere vechi sunt probleme de etichetare. Etichetele le rezolvă de obicei.
Dă fiecărui număr luna indexului său. Afișează-l utilizatorilor. Odată ce pot vedea data, numărul încetează să pară un feed stricat, iar acea mică linie face mai mult decât ar putea vreun TTL mai scurt.
Cât de vechi este prea vechi pentru un număr de linkuri?
Indexul nostru se reîmprospătează aproximativ o dată pe lună, astfel încât un număr cache-uit în prima zi descrie același index ca unul cache-uit în ultima zi. Nimic din răspuns nu se schimbă în interiorul lunii. Problemele încep când un utilizator se așteaptă la un link de ieri, iar apoi remedierea este o etichetă clară, așa cum am acoperit în etichete de scor.
Apelurile gratuite de prezentare generală au nevoie de cache?
Acțiunea de prezentare generală nu costă credite, astfel încât cache-ul aici protejează viteza, nu soldul. Serverul tău plătește totuși pentru fiecare mers-întors, iar o pagină care se deschide de cincizeci de ori pe minut va simți acest lucru. Stochează și răspunsurile gratuite, cu aceeași cheie lunară, iar pagina rămâne rapidă în timp ce proxy-ul tău rămâne liniștit. Notele despre interogarea publică explică aceeași idee pentru vizitatori.
Ar trebui ca un link proaspăt să ocolească cache-ul?
De obicei nu. Un bypass costă credite pentru un răspuns care este probabil identic cu cel cache-uit. Dacă un client insistă, explică luna indexului și oferă o reîmprospătare manuală pe spațiu de lucru pe lună, în loc de un buton deschis pe care oricine îl poate apăsa în buclă.
Protecție împotriva stampedei și alte lucruri mici
Single-flight: dacă zece utilizatori deschid același domeniu, fă un singur apel upstream și împărtășește promisiunea.
Încălzește la prima zi a lunii cu un job în fundal, nu la 9 dimineața când ajung utilizatorii.
Stoarcă _credits.remaining din răspuns și alertează sub un prag ales de tine.
Cache-uiește rezultatul negativ 'domeniu negăsit' pentru o zi, nu pentru o lună.
Expune vârsta cache-ului în UI astfel încât suportul să poată răspunde 'când a fost preluat acest lucru?'.
De ce un cache bate scraping-ul pentru verificarea linkurilor
Echipele care trebuie să verifice backlinkurile paginilor la scară mare încep adesea cu scripturi care interoghează motoarele de căutare direct. Acele scripturi se blochează. Arată ieftine în prima zi, motiv pentru care echipele le păstrează mult mai mult decât ar trebui. Un cache în fața unui API stabil este de obicei design-ul mai ieftin, cu mai puține părți în mișcare de îngrijit.
Diferența apare în orele de inginerie mai mult decât în prima factură. Ține cache-ul plictisitor și majoritatea acelor ore nu se întâmplă niciodată.
De ce verificatorii de linkuri făcute în casă se blochează mereu?
Motoarele de căutare limitează interogările automate, astfel încât un script care rulează curat pentru cincizeci de URL-uri se poate bloca la cincizeci de mii. Retries, pool-uri de proxy și întârzieri aleatorii adaugă toate costuri care nu apar niciodată pe o linie de credite, și se strică fără avertizare când ținta își schimbă răspunsurile.
Cum păstrezi un job de listă lungă restartabil?
Scrie fiecare domeniu finalizat în cache pe măsură ce avansezi. Dacă jobul se oprește la jumătate, un restart sari peste fiecare domeniu care are deja un răspuns stocat și preia de unde a lăsat. Nimic nu este taxat de două ori pentru aceeași lună, deoarece cheia deține deja răspunsul.
Rulează jobul la un ritm constant, nu într-un singur burst. Spațierea apelurilor menține logurile lizibile și face ca orice modificare în utilizarea creditelor să fie ușor de explicat.
Cât costă o listă de 22.000 de URL-uri cu un cache?
Să presupunem că trebuie să verifici 22.000 de URL-uri care linkuiesc către un singur client. Multe dintre ele împărtășesc un domeniu, astfel că dedupează mai întâi la domenii. Acele 22.000 de linkuri s-ar putea să se reducă la câteva mii de domenii unice, iar un singur apel bulk_dr preia până la 2.000 dintre ele pentru un singur credit. Stoarcă fiecare rezultat pe domeniu și lună, iar lista încetează să mai fie un job per-URL. Ține aritmetica într-o notă scurtă lângă job, astfel încât următoarea persoană să îl poată relua cu o dimensiune de listă diferită. Un număr cu calculul său afișat este mai ușor de crezut decât un total singuratic.
Unde se leagă acest lucru
Cache-ul este stratul intermediar din configurarea contorului. Odată ce funcționează, costul pe loc de muncă devine predictibil și poți prețifica un plan în jurul lui cu comparația per loc de muncă. Paginile scurte merită un final clar. Aceasta îl are.
Întrebări despre cache pe care le vedem în code review
Ar trebui ca cache-ul să existe și în browser?
Un cache scurt în browser ajută la navigarea cu butonul înapoi, dar cache-ul partajat de pe serverul tău face economiile reale. Ține stocarea client-side la minute, deoarece utilizatorii de pe mașini diferite ar vedea altfel numere diferite pentru același domeniu în aceeași zi.
Ce se întâmplă dacă un client spune că lipsește un link nou?
Verifică luna indexului afișată în UI-ul tău. Dacă linkul a fost adăugat după ultima reîmprospătare, va apărea după următoarea. Oferă o notă, nu o rambursare, deoarece nu este nimic stricat.
Pot să ocolesc cache-ul la cerere?
Poți, dar fiecare bypass costă credite pentru un răspuns care este probabil identic. Oferă-l doar administratorilor și limitează-l la ritm per spațiu de lucru pentru a evita buclele accidentale.
Paginarea și cheia de cache
Paginarea mușcă pe toată lumea o dată. Include-o în cheie.
Acțiunile backlinks și refdomains returnează până la 1.000 de rânduri pe apel, cu page și per între 10 și 5000, iar paginarea profundă este limitată la 50.000 de rânduri, astfel încât o cheie fără acei parametri va servi pagina unu pentru fiecare cerere.
Sortarea aparține și ea cheii. Un utilizator care comută de la DR descrescător la alfabetic se așteaptă la o listă diferită, iar cache-ul trebuie să se conformeze fără un nou apel upstream când setul complet este deja stocat.
Un test rapid prinde majoritatea greșelilor de cheie. Cere pagina doi, schimbă sortarea, apoi verifică că pagina doi cache-uită diferă de pagina uno cache-uită. Dacă nu, cheii îi lipsește un parametru. Găsită devreme, costă minute. Un client nu o vede niciodată. Rulează din nou testul înainte de fiecare lansare, deoarece o nouă opțiune de sortare este motivul uzual pentru care se strică cheia. Scrie-o în lista ta de verificare a lansării.
Planifică butonul de export separat: un singur job în fundal, un singur fișier stocat și o singură notificare când este gata.
