Guzzle Pool: send proxyen til hver jobb til requestAsync
Knytt proxyvalg til hver asynkrone operasjon i stedet for til en PSR-7-forespørselsmelding eller en blokkerende fabrikk.
Sett proxyen til hver Guzzle-jobb på den asynkrone operasjonen som bassenget starter. Innenfor et eksisterende klientoppsett bruker du løftefabrikker:
$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();
Hver validert jobb gir en destinasjon og en proxy. For en tillatt offentlig forespørsel kan en HTTP-kandidat fra HTTP-proxy listen gi den jobbens proxy-URL uten påloggingsdetaljer; valget skjer før fabrikken kjører. En PSR-7-forespørsel beskriver HTTP-meldingen, mens disse sendevalgene styrer transporten. Å skrive ut eller lagre en proxyverdi ved siden av meldingen kan ikke konfigurere en operasjon som sender den på en annen måte.
Returner requestAsync() fra fabrikken. Å kalle synkron request() der kan blokkere mens bassenget prøver å starte samtidig arbeid.
Legg til callbacks for oppfylte og avviste resultater med applikasjonens eksisterende håndtering. Behold jobbnøkkelen, identifikatoren for valgt proxy og forsøksnummeret i begge utfall; fullføringsrekkefølgen er forskjellig fra inndatarekkefølgen. Ikke velg i hemmelighet et annet endepunkt i fabrikken etter at ett er registrert for jobben.
Verdien for samtidighet begrenser arbeidet til dette bassenget. Flere jobber som velger én begrenset proxy eller konto kan fortsatt trenge et eget budsjett for det endepunktet.
Tolk resultater etter fase: avvisning av destinasjon, proxyautentisering og tilkoblingstidsavbrudd er forskjellige utfall. Sendevalgene som beholdes med jobben viser hvilken rute som ga hvert resultat.