Проверка обратных ссылок на странице через API и честное кэширование
Наш индекс обновляется раз в месяц, поэтому большинство запросов можно обслуживать из памяти. Рецепт кэша, который экономит кредиты и не показывает пользователям устаревшие данные.
Редакция AlfaLinks ·
Правило
Кэшировать до следующего обновления индекса, а не на фиксированный час
Поскольку данные меняются примерно раз в месяц, почасовой TTL не даёт никаких преимуществ, только лишние расходы. Ключ с привязкой к месяцу даёт одинаковый ответ весь месяц и инвалидируется одним действием.
Ключ: действие + домен + параметры + месяц индекса
TTL: до конца месяца плюс день запаса
Никогда не кэшировать ответ об ошибке
Почему короткий TTL — это просто пожертвование в ваш баланс кредитов
Команды, впервые работающие с данными о ссылках, копируют привычки из трекеров позиций. Привычка первая: почасовой кэш, потому что позиции меняются. Графы ссылок меняются редко.
Вызов backlinks стоит 2 кредита и обходится в $0.0002. Это кажется ничем, пока список не запустит 50 таких вызовов при загрузке страницы для 400 активных рабочих пространств, повторяя их каждый час для одинаковых ответов.
Расчёты ниже — это пример, а не измерение чьего-либо трафика. Предположим 400 рабочих пространств, 20 просмотров домена каждое в день, 2 кредита за просмотр и 1-часовой кэш, который срабатывает, возможно, в пятую часть случаев. Большинство просмотров всё равно обращаются к API. При использовании ключа по месяцу тот же трафик обращался бы к API только один раз для домена и месяца, поэтому разница — это суть рецепта.
Инструментам поиска ключевых слов нужны более свежие данные, и для них большие платформы остаются лучшим выбором. Для контекста ссылок достаточно месяца.
TTL по действию
Рекомендуемые, а не обязательные значения. Все действия читают один и тот же ежемесячный индекс.
Действие
Кредиты
Рекомендуемый TTL
Почему
обзор, статистика
0
До конца месяца
Бесплатно, но ваш сервер всё равно экономит задержку
bulk_dr
1
До конца месяца
Вся таблица клиентов в одном вызове
refdomains, backlinks
2
До конца месяца, с учётом параметра page
Включите page, per, sort в ключ
anchors, toppages
2
До конца месяца
Стабильно между обновлениями
search, keyword
3
7 дней
Редко повторяется, дешевле пропустить кэширование
Пример запроса: заполнение кэша для таблицы клиентов
Вызывайте bulk_dr один раз для каждого клиента, а не для каждой строки. До 2,000 доменов помещаются в одно тело POST-запроса и стоят один кредит.
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
Построение кэша за пять шагов
Каждый шаг имеет одну задачу. Пропустите один — и ошибка проявится позже, обычно в виде счёта.
01
Выберите ключ
Используйте действие, домен, параметры пагинации и сортировки, а также месяц индекса. Исключите всё, что пользователь может изменить без изменения ответа, например цвет отображения или имя вкладки.
02
Сохраните распарсенный ответ
Храните декодированный JSON с флагом ok и данными, а не сырые байты. Позже можно будет восстановить всю таблицу из памяти без второго вызова.
03
Истечение срока в конце месяца
Установите срок истечения на конец месяца индекса плюс день запаса из правила выше. Используйте одно и то же правило для всех действий, чтобы логика жила в одной функции, а не в пяти местах.
04
Логгируйте баланс при каждом вызове
Читайте объект _credits в каждом аутентифицированном ответе и записывайте оставшийся баланс в свой лог. Медленное падение этой строки часто является первым признаком того, что ключ кэша неверен.
05
Следите за частотой попаданий в кэш
Отслеживайте, как часто просмотр обслуживается из кэша. Низкая частота означает, что ключ слишком специфичен или что пользователи открывают новый домен при каждом посещении. Оба вывода полезны при планировании бюджета.
Являются ли устаревшие данные выбором продукта или ошибкой?
Число ссылок может быть месячной давности и всё ещё быть верным для индекса, из которого оно получено. Реальный вопрос в том, говорит ли об этом ваш интерфейс. Большинство тикетов поддержки о старых числах — это проблемы с метками. Метки обычно их решают.
Присвойте каждому числу месяц индекса. Покажите его пользователям. Как только они увидят дату, число перестанет выглядеть как сломанный поток, и эта маленькая строка сделает больше, чем любой короткий TTL.
Насколько старым может быть число ссылок?
Наш индекс обновляется примерно раз в месяц, поэтому число, закэшированное в первый день, описывает тот же индекс, что и число, закэшированное в последний день. Ничего в ответе не меняется внутри месяца. Проблемы начинаются, когда пользователь ожидает ссылку за вчерашний день, и тогда решение — чёткая метка, как описано в метках рейтинга.
Нужно ли кэшировать бесплатные вызовы обзора?
Действие обзора не стоит кредитов, поэтому кэш здесь защищает скорость, а не баланс. Ваш сервер всё равно платит за каждый запрос, и страница, открывающаяся пятьдесят раз в минуту, это почувствует. Храните и бесплатные ответы с тем же ключом месяца, и страница останется быстрой, а прокси — тихим. В заметках о публичном поиске объясняется та же идея для посетителей.
Должна ли свежая ссылка обходить кэш?
Обычно нет. Обход стоит кредитов за ответ, который, вероятно, идентичен закэшированному. Если клиент настаивает, объясните месяц индекса и предложите одно ручное обновление на рабочее пространство в месяц, а не кнопку, которую можно нажимать в цикле.
Защита от шторма и другие мелочи
Одиночный полёт: если десять пользователей открывают один и тот же домен, сделайте один запрос к бэкенду и поделитесь обещанием.
Заполняйте кэш в первый день месяца фоновой задачей, а не в 9 утра, когда приходят пользователи.
Сохраняйте ответ _credits.remaining и подавайте предупреждение ниже выбранного вами порога.
Кэшируйте отрицательный результат «домен не найден» на день, а не на месяц.
Показывайте возраст кэша в интерфейсе, чтобы поддержка могла ответить на вопрос «когда это было получено?».
Почему кэш лучше скрейпинга для проверки ссылок
Команды, которым нужно массово проверять обратные ссылки на страницах, часто начинают со скриптов, которые напрямую опрашивают поисковые системы. Эти скрипты зависают. Они кажутся дешёвыми в первый день, поэтому команды держат их гораздо дольше, чем следует. Кэш перед стабильным API обычно является более дешёвым решением с меньшим количеством компонентов, требующих обслуживания.
Разница проявляется в инженерных часах больше, чем в первом счёте. Держите кэш простым, и большинство этих часов не будут потрачены.
Почему самописные проверщики ссылок постоянно зависают?
Поисковые системы ограничивают автоматические запросы, поэтому скрипт, который чисто работает для пятидесяти URL, может зависнуть на пятидесяти тысячах. Повторные попытки, пулы прокси и случайные задержки добавляют расходы, которые не отображаются в строке кредитов, и они ломаются без предупреждения, когда цель меняет ответы.
Как сделать долгоживущую задачу перезапускаемой?
Записывайте каждый завершённый домен в кэш по мере выполнения. Если задача прервётся посередине, перезапуск пропустит все домены, у которых уже есть сохранённый ответ, и продолжит с того места, где остановился. Ничего не будет заряжено дважды за тот же месяц, потому что ключ уже содержит ответ.
Запускайте задачу с постоянной скоростью, а не одним всплеском. Разнесение вызовов делает логи читаемыми и упрощает объяснение любых изменений в использовании кредитов.
Сколько стоит список из 22,000 URL с кэшем?
Допустим, вам нужно проверить 22,000 ссылающихся URL для одного клиента. Многие из них имеют общий домен, поэтому сначала дедублицируйте до доменов. Эти 22,000 ссылок могут сократиться до нескольких тысяч уникальных доменов, и один вызов bulk_dr принимает до 2,000 из них за один кредит. Сохраняйте каждый результат по домену и месяцу, и список перестаёт быть задачей по каждому URL. Ведите арифметику в короткой заметке рядом с задачей, чтобы следующий человек мог запустить её с другим размером списка. Число с показанным расчётом вызывает больше доверия, чем общая сумма сама по себе.
Где это связано
Кэш — это промежуточный слой в настройке счётчика. Как только он заработает, стоимость за пользователя станет предсказуемой, и вы сможете установить цену плана вокруг неё с помощью сравнения по пользователям. Короткие страницы заслуживают ясного конца. Эта его имеет.
Вопросы о кэше, которые мы видим при ревью кода
Должен ли кэш жить в браузере?
Короткий кэш браузера помогает навигации кнопкой «Назад», но реальную экономию обеспечивает общий кэш на вашем сервере. Храните данные на клиенте не более нескольких минут, иначе пользователи на разных машинах увидят разные числа для одного и того же домена в один и тот же день.
Что делать, если клиент говорит, что новая ссылка отсутствует?
Проверьте месяц индекса, показанный в вашем интерфейсе. Если ссылка была добавлена после последнего обновления, она появится после следующего. Предложите заметку, а не возврат средств, потому что ничего не сломано.
Могу ли я обойти кэш по запросу?
Можете, но каждый обход стоит кредитов за ответ, который, вероятно, идентичен. Предложите его только администраторам и ограничьте частоту на рабочее пространство, чтобы избежать случайных циклов.
Пагинация и ключ кэша
Пагинация бьёт всех однажды. Включите её в ключ.
Действия backlinks и refdomains возвращают до 1,000 строк за вызов, с page и per от 10 до 5000, а глубокое пагинирование ограничено 50,000 строками, поэтому ключ без этих параметров будет отдавать первую страницу для каждого запроса.
Сортировка также должна быть в ключе. Пользователь, который переключается с убывания DR на алфавитный порядок, ожидает другой список, и кэш должен это учесть без нового запроса к бэкенду, когда полный набор уже сохранён.
Быстрый тест ловит большинство ошибок ключа. Запросите вторую страницу, измените сортировку, затем проверьте, что закэшированная вторая страница отличается от закэшированной первой. Если нет, в ключе отсутствует параметр. Обнаруженное рано, это стоит минуты. Клиент этого не увидит. Запускайте тест снова перед каждым релизом, потому что новая опция сортировки — обычная причина поломки ключа. Внесите это в чек-лист релиза.
Планируйте кнопку экспорта отдельно: одна фоновая задача, один сохранённый файл и одно уведомление, когда он готов.
