AlfaLinks
AlfaLinksZarejestruj się

Przepis

Sprawdzanie backlinków strony przez API i uczciwe buforowanie

Nasza indeksacja odbywa się raz w miesiącu, więc większość zapytań może być obsługiwana z pamięci. Przepis na bufory, które oszczędzają kredyty, nie pokazując użytkownikom przestarzałych danych.

Kamienny most z trzema słoikami kolorowego piasku reprezentujący świeżość zbuforowanych danych backlinków

Zasada

Buforuj do momentu odświeżenia indeksacji, a nie przez stałą liczbę godzin

Ponieważ dane zmieniają się mniej więcej raz w miesiącu, godzinowy TTL nie przynosi korzyści, a tylko koszty. Klucz objęty zakresem miesiąca daje tę samą odpowiedź przez cały miesiąc i unieważnia się jednym ruchem.

  • Klucz: akcja + domena + parametry + miesiąc indeksacji
  • TTL: do końca miesiąca, plus dzień karencji
  • Nigdy nie buforuj odpowiedzi błędu

Dlaczego krótki TTL to po prostu darowizna dla salda kredytów

Zespoły początkujące w danych linkowych kopiują nawyki z trackerów pozycji. Pierwsza nawyk: godzinowy cache, ponieważ pozycje się zmieniają. Grafy linków zmieniają się bardzo rzadko.

Wywołanie backlinks kosztujące 2 kredyty to $0.0002. Brzmi to niewiele, dopóki nie policzysz, że widok listy generuje 50 takich wywołań na załadowanie strony w 400 aktywnych przestrzeniach roboczych, powtarzanych co godzinę dla tych samych odpowiedzi.

Poniższe obliczenia to przykład, a nie pomiar ruchu kogokolwiek. Przyjmijmy 400 przestrzeni roboczych, 20 wyświetleń domeny dziennie, 2 kredyty na wyświetlenie i 1-godzinny cache, który trafiałby może w jedną piątą przypadków. Większość wyświetleń i tak trafi do API. Przy kluczu miesięcznym ten sam ruch trafiłby do API tylko raz na domenę i miesiąc, więc ta luka jest sednem przepisu.

Narzędzia do researchu słów kluczowych potrzebują świeższych danych, a w tym przypadku duże platformy pozostają lepszym wyborem. Dla kontekstu linkowego miesięczność jest produktem.

TTL według akcji

Sugerowane, nie obowiązkowe. Wszystkie akcje odczytują ten sam miesięczny indeks.
AkcjaKredytySugerowany TTLDlaczego
przegląd, statystyki0Do końca miesiącaDarmowe, ale Twój serwer nadal oszczędza na opóźnieniach
bulk_dr1Do końca miesiącaCała tabela klientów w jednym wywołaniu
refdomains, backlinks2Do końca miesiąca, według parametru stronyUwzględnij page, per, sort w kluczu
anchors, toppages2Do końca miesiącaStabilne między odświeżeniami
search, keyword37 dniRzadko powtarzane, taniej pominąć buforowanie

Przykład żądania: przygotowanie cache dla tabeli klientów

Wywołaj bulk_dr raz dla każdego klienta, a nie raz dla każdego wiersza. Do 2000 domen mieści się w jednym ciele POST i kosztuje jeden kredyt.

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

Zbuduj cache w pięciu krokach

Każdy krok ma jedno zadanie. Pominiesz jeden, a błąd pojawi się później, zwykle w postaci rachunku.

01

Wybierz klucz

Użyj akcji, domeny, parametrów paginacji i sortowania oraz miesiąca indeksacji. Pomiń wszystko, co użytkownik może zmienić bez zmiany odpowiedzi, np. kolor wyświetlania lub nazwę karty.

02

Zapisz sparsowaną odpowiedź

Przechowuj zdekodowany JSON z flagą ok i danymi, a nie surowe bajty. Późniejszy widok może wtedy odtworzyć całą tabelę z pamięci bez drugiego wywołania.

03

Unieważnij pod koniec miesiąca

Ustaw expiry na koniec miesiąca indeksacji, plus dzień karencji z powyższej zasady. Użyj tej samej zasady dla każdej akcji, aby logika żyła w jednej funkcji, a nie w pięciu miejscach.

04

Loguj saldo przy każdym wywołaniu

Odczytaj obiekt _credits z każdej uwierzytelnionej odpowiedzi i zapisz pozostałe saldo w swoim logu. Wolny spadek tej wartości to często pierwszy znak, że klucz cache jest błędny.

05

Śledź wskaźnik trafień

Śledź, jak często widok jest obsługiwany z cache. Niski wskaźnik oznacza, że klucz jest zbyt szczegółowy, lub że użytkownicy otwierają nową domenę przy każdej wizycie. Obie te informacje są przydatne przy planowaniu budżetu.

Jabłka na podstawkach korkowych pokazujące kontekst daty zbioru dla świeżości

Czy przestarzałe dane to wybór produktowy, czy błąd?

Liczba linków może mieć miesiąc i tak być poprawna dla indeksu, z którego pochodzi. Pytanie o to, czy Twój ekran to pokazuje, jest prawdziwym wyzwaniem. Większość zgłoszeń dotyczących starych liczb to problemy z etykietami. Etykiety zwykle je rozwiązują.

Nadaj każdej liczbie jej miesiąc indeksacji. Pokaż to użytkownikom. Gdy mogą zobaczyć datę, liczba przestaje wyglądać na uszkodzony strumień, a ta mała linia zrobi więcej niż krótszy TTL.

Jak stara jest zbyt stara liczba linków?

Nasza indeksacja odświeża się mniej więcej raz w miesiącu, więc liczba zbuforowana pierwszego dnia opisuje ten sam indeks co ta zbuforowana ostatniego dnia. Nic w odpowiedzi nie zmienia się wewnątrz miesiąca. Problemy zaczynają się, gdy użytkownik oczekuje linku z wczoraj, a wtedy rozwiązaniem jest jasna etykieta, jak omówiono w etykietach ocen.

Czy darmowe wywołania przeglądu potrzebują w ogóle cache?

Akcja overview nie kosztuje kredytów, więc cache tutaj chroni prędkość, a nie saldo. Twój sercer nadal płaci za każdą podróż w obie strony, a strona otwierana pięćdziesiąt razy na minutę to odczuje. Zbuforuj też darmowe odpowiedzi z tym samym kluczem miesięcznym, a strona pozostanie szybka, a Twój proxy ciche. Uwagi dotyczące wyszukiwania publicznego wyjaśniają ten sam pomysł dla odwiedzających.

Czy świeży link powinien kiedykolwiek omijać cache?

Zazwyczaj nie. Omijanie kosztuje kredyty za odpowiedź, która prawdopodobnie jest identyczna z tą zbuforowaną. Jeśli klient nalega, wyjaśnij miesiąc indeksacji i zaoferuj jedno ręczne odświeżenie na przestrzeń roboczą na miesiąc, zamiast otwartego przycisku, który każdy może wciskać w pętli.

Ochrona przed stampede i inne drobne rzeczy

  • Single-flight: jeśli dziesięciu użytkowników otworzy tę samą domenę, wykonaj jedno wywołanie upstream i udostępnij promise.
  • Przygotuj cache pierwszego dnia miesiąca zadaniem w tle, a nie o 9:00, gdy przychodzą użytkownicy.
  • Zapisz _credits.remaining odpowiedzi i alertuj poniżej wybranego progu.
  • Zbuforuj wynik negatywny 'domena nie znaleziona' na jeden dzień, nie na miesiąc.
  • Wyeksponuj wiek cache w UI, aby support mógł odpowiedzieć 'kiedy to pobrano?'.
Żelazny młot i kamienie rzeczne na warsztatowej ławce reprezentujące stabilne buforowanie

Dlaczego cache bije scraping przy sprawdzaniu linków

Zespoły, które muszą masowo sprawdzać backlinki stron, często zaczynają od skryptów pytających bezpośrednio wyszukiwarki. Te skrypty się zawieszają. Wyglądają tanio pierwszego dnia, dlatego zespoły trzymają je znacznie dłużej, niż powinny. Cache przed stabilnym API to zwykle tańsza architektura z mniejszą liczbą elementów do pilnowania.

Różnica objawia się w godzinach inżynierii bardziej niż w pierwszej fakturze. Trzymaj cache nudnym, a większość tych godzin się nie wydarzy.

Dlaczego domowe sprawdzarki linków ciągle się zawieszają?

Wyszukiwarki throttlingują zapytania zautomatyzowane, więc skrypt działający poprawnie dla pięćdziesięciu URL może się zawiesić przy pięćdziesięciu tysiącach. Retries, pulle proxy i losowe opóźnienia dodają koszty, które nie pojawiają się na linii kredytów, i łamią się bez ostrzeżenia, gdy target zmieni odpowiedzi.

Jak utrzymać długą listę zadań jako restartowalną?

Zapisuj każdą ukończoną domenę w cache w miarę postępu. Jeśli zadanie zatrzyma się w połowie, restart pominie każdą domenę, która już ma zapisaną odpowiedź, i wznowi tam, gdzie skończył. Nic nie jest ładowane dwukrotnie za ten sam miesiąc, ponieważ klucz już zawiera odpowiedź.

Uruchom zadanie w stałym tempie, a nie jednym burstem. Rozłożenie wywołań sprawia, że logi są czytelne, a każda zmiana w użyciu kredytów łatwa do wyjaśnienia.

Ile kosztuje lista 22 000 URL z cache?

Załóżmy, że musisz sprawdzić 22 000 linkujących URL dla jednego klienta. Wiele z nich dzieli domenę, więc najpierw zdeduplikuj do domen. Te 22 000 linków może sprowadzić się do kilku tysięcy unikalnych domen, a jedno wywołanie bulk_dr obsługuje do 2000 z nich za jeden kredyt. Zapisz każdy wynik według domeny i miesiąca, a lista przestaje być zadaniem per-URL. Trzymaj rachunki w krótkiej notatce obok zadania, aby następna osoba mogła je uruchomić z innym rozmiarem listy. Liczba z pokazanymi obliczeniami jest łatwiejsza do zaufania niż suma sama w sobie.

Gdzie to się łączy

Cache jest warstwą pośrednią w konfiguracji licznika. Gdy zadziała, koszt na użytkownika staje się przewidywalny i możesz wycenić plan wokół tego z porównaniem per-seat. Krótkie strony zasługują na jasne zakończenie. Ta je ma.

Pytania o cache, które widzimy w code review

Czy cache powinien żyć też w przeglądarce?

Krótki cache przeglądarki pomaga w nawigacji przyciskiem wstecz, ale prawdziwe oszczędności robi wspólny cache na serwerze. Trzymaj storage po stronie klienta na minuty, ponieważ użytkownicy na różnych maszynach widzieliby inaczej liczby dla tej samej domeny tego samego dnia.

Co jeśli klient powie, że brakuje nowego linku?

Sprawdź miesiąc indeksacji pokazany w Twoim UI. Jeśli link został dodany po ostatnim odświeżeniu, pojawi się po następnym. Zaoferuj notatkę, a nie refundację, ponieważ nic nie jest zepsute.

Czy mogę ominąć cache na żądanie?

Możesz, ale każde omijanie kosztuje kredyty za odpowiedź, która prawdopodobnie jest identyczna. Oferuj ją tylko adminom i ogranicz rate-limit per workspace, aby uniknąć przypadkowych pętli.

Paginacja i klucz cache

Paginacja uderza każdego raz. Uwzględnij ją w kluczu.

Akcje backlinks i refdomains zwracają do 1000 wierszy na wywołanie, z page i per między 10 a 5000, a głęboka paginacja jest ograniczona do 50 000 wierszy, więc klucz bez tych parametrów zwróci stronę jedną dla każdego żądania.

Sortowanie należy też do klucza. Użytkownik, który zmienia sortowanie od DR malejąco do alfabetycznego, oczekuje innej listy, a cache musi to obsłużyć bez nowego wywołania upstream, gdy pełny zestaw jest już przechowywany.

Szybki test łapie większość błędów klucza. Poproś o stronę drugą, zmień sortowanie, a następnie sprawdź, czy zbuforowana strona druga różni się od zbuforowanej strony pierwszej. Jeśli nie, kluczowi brakuje parametru. Złapane wcześnie, kosztuje minuty. Klient tego nie zobaczy. Uruchom test ponownie przed każdym releasem, ponieważ nowa opcja sortowania to zwykle powód, dla którego klucz się psuje. Zapisz ją na liście kontrolnej release'u.

Zaplanuj przycisk eksportu osobno: jedno zadanie w tle, jeden zapisany plik i jedno powiadomienie, gdy jest gotowy.