Каков общий способ управления URL-адресами при сканировании?

Question

Я пытаюсь запрограммировать веб-сканер, но теперь мне интересно: каков наилучший способ хранения всех URL-адресов, чтобы сканеры могли работать вместе, но не мешали?

Пример:

• Crawler 1 находит страницу с 100 URL
• Crawler 2 находит страницу без URL
• Crawler 1 и 2 должны поделиться 100 URL-адресов, найденных Crawler 1

Мои идеи (два разных подхода)

1. Позвольте Crawler сканировать страницу на наличие новых URL
   • сохранить все найденные URL-адреса в Queue (PriorityQueue), совместно используемом всеми экземплярами Crawler
   • Аутсорсинг URL-адресов в базу данных, как только Queue становится слишком большим (например, 80% от максимального размера)
2. Позвольте Crawler сохранять HTML и Analyzer искать URL позже
   • сохранение новых URL-адресов в горизонтально масштабируемой базе данных
   • всегда запрашивать в этой базе данных следующий URL

Проблемы

1. Является ли общий Queue горлышком бутылки?
2. Как я могу запретить нескольким сканерам получать один и тот же URL-адрес дважды, если база данных в конечном итоге согласована?

Другие решения?

Есть ли другое решение? Каково стандартное решение для веб-сканеров?

Answer 1

[Хотя это старый вопрос, я добавляю этот ответ для поисковиков, приземляющихся здесь]

Вам нужен Фильтр Блума .

Хотя большинство фильтров Блума с открытым исходным кодом, которые вы найдете, представляют собой библиотеки, предназначенные для локального доступа, на самом деле довольно просто превратить их в веб-службу и, следовательно, в общий ресурс для нескольких узлов.

Вот очень простой пример использования php-bloom-filter со статической библиотекой кэша:

<?php

// assumes $_POST contains a JSON-encoded  array of URLs to check ($links)
// and a unique crawl identifier ($crawl_id)
extract($_POST);

if (!$b = unserialize(Cache::read('filter_'.$crawl_id))) {
    $b = new BloomFilter(100000, 0.001);
}

$return = array();
foreach (json_decode($links, true) as $link) {
    if (!$b->has($crawl_id.'_'.$link)) {
        $return[] = $link;
        $b->add($crawl_id.'_'.$link);
    }
}

// put the filter back into our cache
Cache::write('filter_'.$crawl_id, serialize($b));

echo json_encode($return);

Любые URL-адреса, которые выходят из проверки фильтра Блума, будут затем помещаться вВаша очередь сканирования для захвата узлами сканирования.

Этот вид реализации, очевидно, не предназначен для сканирований в масштабах сети, но будет подходящим для сканирования отдельных сайтов объемом до 100 000 страниц или более (в зависимости от доступныхресурсы сервера).Конечно, если вам действительно нужен ваш фильтр Блума для горизонтального масштабирования, вы можете использовать несколько узлов Блума за прокси-сервером, используя распределенный кэш некоторого описания (redis / memcache / ehcache и т. Д.).Вам понадобится умный осколок для объектов кеша, чтобы поддерживать скорость поиска, но я уверен, что вы справитесь с этим, когда возникнет такая необходимость.

Единственное предостережение по поводу вышесказанного - иногда вы получаете ложноеотрицательный результат и в конечном итоге сканирует один и тот же URL более одного раза - это факт большинства сканеров веб-страниц, так что это просто тот случай, когда вы должны изящно обработать код разбора сканирования.

Answer 2

У вас есть более одного вопроса, но как насчет этого для одного общего подхода.

См. Это SO обсуждение относительно определения, эквивалентны ли два URL.

Тогда у вас действительно есть много вариантов. Моим личным фаворитом было бы написать 3 вещи.

1) Приложение базы данных, которое обрабатывает только список URL-адресов, ожидающих посещения.
2) Приложение базы данных, которое хранит важные результаты посещенных сайтов. Все, что вы хотите сохранить.
3) Приложение, которое может запрашивать и публиковать в (1), а затем публиковать в (2)

Почему так?
Вы можете разместить (1) и (2) на одной машине. (3) может работать из любого места, что позволяет запускать несколько экземпляров с нескольких IP-адресов. Это поможет вам ориентироваться в поставщиках услуг и других людях сети, которые могут быть обеспокоены вашими частыми и частыми запросами http.