Всем привет!
Одной из самых больших проблем при решении задач веб-парсинга данных является риск блокировки аккаунта. В общем случае эта проблема возникает только по одной причине – это большое количество запросов к веб-порталу за единицу времени.
Существует несколько путей решения этой проблемы с целью сохранить аккаунт:
Использование большего количества аккаунтов.
Пример: 1000000 запросов в день с одного аккаунта. Если аккаунт блокируется, то целесообразно использовать большее количество аккаунтов чтобы соответственно уменьшить количество запросов к веб порталу с каждого аккаунта.Использование большего количества прокси серверов. Аналогично с пунктом №1, данный подход уменьшает количество запросов на веб портал во столько раз, сколько прокси используется в задаче.
На практике способы 1 и 2 разумно использовать вместе. Каждому аккаунту назначается отдельный прокси сервер. Не стоит допускать чтобы с одного прокси сервера были запросы различных аккаунтов так как это грозит возможной блокировкой всех "засвеченных" аккаунтов.Ограничение количества запросов к веб-порталу на единицу времени. Данный способ может применяться в тех случаях, когда невозможно разделить запросы к веб-порталу используя пункты 1 и 2 (пример: нет у вас большого количества аккаунтов). Для реализации данного способа настраивают некоторую задержку между выполнением запросов или отключение выполнения запросов при достижении определенного лимита на единицу времени (пример: при достижении 100000 запросов в сутки).
Кэширование данных веб-портала. В тех случаях, когда выполняется множество идентичных запросов, целесообразно сохранить первый запрос в хранилище данных и при обращении последующих идентичных запросов выдавать сохраненный ответ вместо того чтобы обратиться к веб-порталу.
Пример: несколько hr-менеджеров работают над одной задачей: поиском анкет соискателей на одном веб-портале. В процессе работы каждый менеджер открывает несколько раз одну и ту же анкету. Кеширование запросов всех менеджеров в одну базу данных сократит нагрузку на каждый аккаунт так, как будто каждую анкету соискателя открывали не более одного раза. Проблема количества запросов, например, очень актуальна для linkedin.com.
Первые три способа наиболее понятны и не требуют большого пояснения. В этой статье мы детально рассмотрим четвертый способ. Заранее скажу, не существует идеального способа решения сохранения аккаунта, который работает во всех случаях. Каждый веб-портал требует индивидуального подхода для получения высокого результата.
Первым делом следует определиться в каком месте будем кэшировать. А вариантов тут несколько.
Кэширование на рабочем компьютере. Основной недостаток этого способа: если компьютеров несколько, то на каждом компьютере будет своя версия кэша. Создание такого количества кэшей создаст кратную этому количеству нагрузку на аккаунт и на общий объем хранилища (сумма объемов каждого хранилища будет точно больше одного общего хранилища). В тех случаях, когда пользователи работают с одинаковыми данными, этот способ не является лучшим, так как один общий кэш занимает меньше места чем все отдельные кэши по отдельности. Жесткий диск пользователя обычно не быстрый (это минус), но кэш находится очень близко и с кэшем будет работать только один пользователь (это плюс).
Кэширование на сервере локальной сети. Основной плюс данного способа – это использование общего кэша для всех пользователей локальной сети. Это значит, что обращения новых пользователей не будут создавать нагрузку на аккаунт. Скорость работы будет зависеть главным образом от параметров системы хранения данных сервера (скорость чтения/записи, удаленность). Чтобы собирать пакеты данных пользователей необходимо это настроить на каждом компьютере пользователя. Общее решение выглядит следующим образом: установка прокси-сервера в локальной сети на любом компьютере (далее, «Сервер»), генерация сертификата для расшифровки HTTPS-трафика на сервере, установка серверного сертификата на компьютерах пользователей, настройка параметра прокси-сервера в операционной системе каждого пользователя.
Кэширование на интернет-шлюзе локальной сети. Существуют аппаратные и программные интернет-шлюзы. Их много и они разные. Читайте документацию для вашего шлюза. Основной плюс данного способа – данные пользователей уже идут через ваш интернет-шлюз и остается только включить расшифровку HTTPS-пакетов если еще это не включено (опять же с установкой сертификата каждому пользователю).
Кэшировать в облачное хранилище. Если ваших пользователей много и они находятся в разных сетях (например, в разных странах), а вам важно использование общего кэша, то подойдет способ с облачным хранилищем. Каждый пользователь будет записывать данные в облако, и все пользователи будут обращаться в облако для скачивания этих данных. Скорость работы будет зависеть от двух параметров: скорость работы облачного сервера, скорость и качество интернет-соединения пользователя.
При внедрении того и иного способа нужно понимать, что операции чтения и записи в хранилище кэша занимают некоторое время. Существует много сайтов, при одном обращении к которым из браузера происходит сто и более запросов (изображения, css-стили, js-скрипты). Легко может получиться ситуация, когда работа через кэш-сервер будет медленнее чем без нее. Все зависит от места расположения кэша, скорости работы с кэшем, правильности настроек базы данных.
Принцип работы кеширующего прокси-сервера:
При поступлении входящего запроса проверка наличия ресурса в хранилище. Если существует, то возврат данных из хранилища остановив выполнение запроса к веб-порталу.
При поступлении ответа от веб-портала и при соответствии запроса правилам кэширования записать его в хранилище.
Что за правила кэширования? На практике невозможно кэшировать все. Пользователи имеют разные уровни доступа на веб-портале, индивидуальные настройки отображения контента. С другой стороны, разработчики веб-порталов стараются помешать кэшировать все, так как хотят знать сколько пользователей сейчас работают с ресурсом. Для этого могут создать некоторый запрос, который будет работать по таймеру и в случае, если придут некорректные данные или данные совсем не придут, то сессия прекратится. Такие запросы нельзя кэшировать.
Для составления правил кэширования существуют общие правила – проверять в ответах веб-портала заголовки “cache-control” и “Expires” (это основные, но не все заголовки).
Пример: “cache-control: private, max-age=0, no-cache”
Параметр “private/public” определяет, предназначены ли эти данные определенному пользователю или это общий ресурс.
Параметр “max-age” задает время актуальности загруженного ресурса в секундах.
Параметр “no-cache” не запрещает сохранить данные в кэш, но требует проверять данные перед тем как их вернуть пользователю.
Параметр “no-store” запрещает сохранять данные в кэш во всех случаях.
Если в ответе сервера нет заголовка “cache-control”, то хранить эти данные нельзя.
Если вашей задачей по созданию кэш-сервера является кеширование одного веб-портала, а не весь Интернет, то использование только заголовка “cache-control” не даст максимальной отдачи от функции кэширования ведь стандартные кэш-сервера не кэшируют private-контент, no-store контент.
Рассмотрим составление собственных правил кэширования, которое занимает большее количество времени чем использование стандартных подходов. Стоит сказать, что использование собственных правил в обход стандарта HTTP опасно. При неправильном составлении правил или при возможном обновлении веб-портала есть риск показать неверно сохраненные данные.
Все веб-порталы уникальны (обычно), поэтому правила различные. Приведу примеры некоторых возможных собственных правил кэширования:
Если каждое изображение имеет свое уникальное имя файла, то их можно кэшировать. Пример: “T32EL_L.png”.
Обратный пример: “image.png”. Если по разным ссылкам скачивается файл с одним названием, то кэшировать нельзя.Если js, css файлы имеют номер версии в своем названии, то их можно кэшировать. Пример: “pdf-es5-v5.3.0.js”.
Обратный пример: “functions.js”. Есть вероятность, что на веб-портале обновится файл со скриптами и ваша кэш копия будет работать неправильно.Если GET-запрос имеет в url ссылку на запрашиваемые данные, то кэшировать можно. Пример: “/section/CAgSBMiFLDt/children?language=en”
Обратный пример: “/findsomething?language=en”. Указание данных для запроса здесь не передается в url, но может передаваться, например, через cookie или другие заголовки.Для кэширования POST-запроса нужно дополнительно кэшировать тело этого запроса вместе с ответом, так как url запроса может быть одинаковым, а строка передаваемых данных разной, а значит и ответ веб-портала будет разным.
