Guzzle Pool: передавайте проксі кожного завдання в requestAsync
Приєднуйте параметри проксі до кожної асинхронної операції, а не до повідомлення запиту PSR-7 чи блокуючої фабрики.
Розмістіть проксі кожного завдання Guzzle в асинхронній операції, яку запускає пул. У наявному налаштуванні клієнта використовуйте фабрики промісів:
$operations = function () use ($client, $jobs) {
foreach ($jobs as $id => $job) {
yield $id => function () use ($client, $job) {
return $client->requestAsync('GET', $job['url'], [
'proxy' => $job['proxy'],
'timeout' => 20,
]);
};
}
};
$pool = new GuzzleHttp\Pool($client, $operations(), [
'concurrency' => 4,
]);
$pool->promise()->wait();
Кожне перевірене завдання надає призначення та проксі. Для дозволеного публічного запиту HTTP-кандидат зі списку HTTP-проксі може надати URL проксі цього завдання без облікових даних; вибір відбувається до запуску його фабрики. Запит PSR-7 описує повідомлення HTTP, а ці параметри надсилання керують транспортом. Друк або збереження значення проксі поруч із повідомленням не може налаштувати операцію, яка надсилає його інакше.
Повертайте requestAsync() з фабрики. Виклик синхронного request() там може заблокувати, поки пул намагається почати паралельну роботу.
Додайте зворотні виклики для виконаних і відхилених результатів, використовуючи наявну обробку застосунку. Зберігайте ключ завдання, ідентифікатор вибраного проксі та номер спроби в обох результатах; порядок завершення відрізняється від порядку введення. Не вибирайте таємно іншу кінцеву точку у фабриці після того, як одну записано для завдання.
Значення паралельності обмежує роботу цього пулу. Кілька завдань, що вибирають один обмежений проксі або акаунт, усе ще можуть потребувати окремого бюджету для цієї кінцевої точки.
Тлумачте результати за етапами: відмова призначення, автентифікація проксі та тайм-аут з'єднання — це різні результати. Параметри надсилання, збережені із завданням, показують, який маршрут дав кожен результат.