Пишем простейший сборщик, использующий Google API на PHP. (Классы)

В предыдущем посту я рассказывал как организовать многопоточный сбор поисковых результатов через Google API и обещал показать как происходит оптимизация и сделать нормальную структуру кода. Для этого я перевел все на классы и объекты. Разбил большие функции на более понятные. Также сделал так чтобы не было повторяющегося кода. В итоге получился тот же сборщик, только уже на объектах:

многопоточный сбор поисковых результатов на PHP (классы)

сбор поисковых результатов на PHP в 5 потоков (классы)

Структура папок  :

  • log — папка для записи логов мультипоточного лаунчера
  • src — папка с исходными данными для всех сборщиков
    • run_once.php — код запуска для одного сборщика
    • in/proxy.txt — файл проксей,  — будет поделен на равные части и каждая часть будет подключена к своему потоку
    • in/queries.txt — файл запросов, — будет поделен на равные части и передан каждому потоку для сбора
  • tools — папка с инструментами — объектами для организации сбора и мультипоточного запуска
    • file_tools.php — класс CFile для работы с файлами в файловой системе (статические функции)
    • folder_tools.php — класс CFolder для работы с папками в файловой системе (статические функции)
    • google_api_sr.php — класс CGoogleAPISearchResults для работы с Google API для поисковых результатов
    • in_data_file.php — класс CInDataFile для работы с файлами входных данных
    • log_tools.php — класс CLogEvent для логирования процессов
    • multi_thread_tools.php — класс CMultiThreadLauncher для органицации и запуска нескольких потоков сбора данных на PHP (организация многопточности)
    • proxy_tools.php — класс CProxyVendor для получения прокси
    • text_file.php — класс CTextFile для работы с текстовыми файлами (статические функции)
    • tools.php — файл обертка для подключения всех классов в один
  • threads — автосоздаваемая папка, в которой будут создано заданное число потоков с номерами 0,1,2 …

Выводы : 

Далее запускаем это все на сбор и имеем тот же результат что и в предыдущем посту, разве что слегка лучше залогированный.  Как видим все теперь стало наглядней, каждый объект отвечает за те действия, что от него требуются. Такой код гораздо быстрее модифицировать, гораздо проще отлаживать и понимать что и как происходит в нем так или не так. Особенно после длительной паузы, особенно другому человеку. Но самое главное в этом подходе это возможность написать следующий сборщик с минимальными усилиями. У нас уже есть классы и методы для решения текущей задачи. И любые следующие сборщики будут написаны  с минимальными усилиями с нашей стороны. В следующих постах я напишу сборщик подсказок гугла. И покажу что для этого требуется минимальная модификация данного кода. Таким образом мы получили зачаток целой системы для сбора данных.

Теперь по дальнейшей оптимизации сбора. Узкий момент в нашей текущей модели это прокси. Во первых прокси «умирают» со временем (перестают отвечать на запросы), во вторых из-за превышения частоты запросов к Google API через один и тот же прокси, Google его банит. Т.е число рабочих прокси уменьшается со временем, а если их станет мало то процесс бана очень сильно ускорится, что совсем нас не устраивает. Поэтому в следующем посту я напишу и отлажу код, который будет решать проблемы прокси.

сбор многопоточного PHP сборщика на объектах

лог сбора многопоточного PHP сборщика на классах

Материалы

Весь исходный код по этой статье можно скачать здесь. Руководство «Как запустить этот и другие PHP скрипты с этого сайта» всегда можно найти здесь. Где взять платные и бесплатные прокси сервера, можно найти здесь.

Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс
Опубликовано в PHP, Использование Web API, Обучение Метки: , , , , ,
Сентябрь 2021
Пн Вт Ср Чт Пт Сб Вс
« Фев    
 12345
6789101112
13141516171819
20212223242526
27282930