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() там может заблокировать, пока пул пытается начать параллельную работу.
Добавьте обратные вызовы для выполненных и отклонённых результатов, используя существующую обработку приложения. Сохраняйте ключ задачи, идентификатор выбранного прокси и номер попытки в обоих исходах; порядок завершения отличается от порядка ввода. Не выбирайте тайно другую конечную точку в фабрике после того, как одна записана для задачи.
Значение параллелизма ограничивает работу этого пула. Несколько задач, выбирающих один ограниченный прокси или аккаунт, всё равно могут требовать отдельного бюджета для этой конечной точки.
Толкуйте результаты по этапам: отказ назначения, аутентификация прокси и истечение времени соединения — разные исходы. Параметры отправки, сохранённые с задачей, показывают, какой маршрут дал каждый результат.