Uten proxy-IP vil arbeid med crawlere være vanskelig, så mange crawler-ingeniører må kjøpe effektiv og stabil proxy-IP. Med en høykvalitets proxy-IP, kan du lene deg tilbake og slappe av? Ting er ikke så enkle, og det er også nødvendig å optimalisere ordningen, rasjonelt fordele ressurser, forbedre arbeidseffektiviteten og utføre crawler-arbeid mer effektivt, raskere og mer stabilt.
Alternativ 1: Hver prosess velger tilfeldig en liste med IP-adresser fra grensesnittets API (for eksempel å hente ut 100 IP-er samtidig) for å sykle gjennom dem, og kaller deretter API-et for å hente dem hvis det feiler, og den generelle logikken er som følger:
1. Hver prosess (eller tråd) henter tilfeldig en batch med IP-adresser fra grensesnittet, og prøver å hente data fra IP-listen i en løkke.
2. Hvis tilgangen lykkes, fortsett å ta den neste.
3. Hvis det feiler (som timeout, verifiseringskode osv.), ta en batch med IP-adresser fra grensesnittet og fortsett å prøve.
Ulemper med løsningen: Hver IP har en utløpsdato; hvis 100 ekstraheres, kan de fleste av disse være ugyldige når den tiende brukes. Hvis du setter opp en HTTP-forespørsel med en tilkoblingstidsavbrudd på 3 sekunder og en lesetidsavbrudd på 5 sekunder, kan du kaste bort 3-8 sekunder, og kanskje disse 3-8 sekundene kan hentes dusinvis av ganger.
Alternativ 2: Hver prosess tar en tilfeldig IP fra grensesnitt-API-et for å bruke, og kaller deretter API-et for å hente en IP hvis den feiler, den generelle logikken er som følger:
1. Hver prosess (eller tråd) henter tilfeldig en IP fra grensesnittet og bruker denne IP-en til å få tilgang til ressurser.
2. Hvis tilgangen lykkes, fortsett å ta den neste.
3. Hvis det feiler (for eksempel timeout, verifiseringskode osv.), velg tilfeldig en IP fra grensesnittet og fortsett forsøket.
Ulemper: Å kalle API-er for å hente IP-adresser er svært hyppig, noe som vil legge stort press på proxyserveren, påvirke stabiliteten til API-grensesnittet, og kan bli begrenset fra å pakke ut. Denne ordningen er heller ikke egnet og kan ikke drives på en bærekraftig og stabil måte.
Alternativ 3: Først, trekk ut et stort antall IP-adresser og importer dem til den lokale databasen, og ta deretter IP-adressen fra databasen, den generelle logikken er som følger:
1. Lag en tabell i databasen, skriv et importskript, be om API-et per minutt (konsulter proxy-IP-leverandørens forslag), og importer IP-listen til databasen.
2. Registrere importtid, IP, port, utløpstid, IP-tilgjengelighetsstatus og andre felt i databasen;
3. Skriv et grab-skript, crab-skriptet leser den tilgjengelige IP-en fra databasen, og hver prosess henter en IP fra databasen for bruk.
4. Utfør crawling, vurder resultatene, behandle informasjonskapsler osv., så lenge det finnes en verifiseringskode eller feil, gi opp denne IP-en og bytt til en ny IP.
Denne løsningen unngår effektivt forbruk av proxy-serverressurser, fordeler bruken av proxy-IP, er mer effektiv og stabil, og sikrer holdbarheten og stabiliteten til crawler-arbeidet. |
Publisert på 17.07.2018 13:54:35
|
|
|
Publisert på 18.07.2018 14:50:55
|
