Uden proxy-IP vil crawler-arbejde være vanskeligt, så mange crawler-ingeniører er nødt til at købe effektiv og stabil proxy-IP. Med en proxy-IP af høj kvalitet, kan du så læne dig tilbage og slappe af? Tingene er ikke så simple, og det er også nødvendigt at optimere ordningen, rationelt fordele ressourcer, forbedre arbejdseffektiviteten og udføre crawler-arbejde mere effektivt, hurtigere og mere stabilt.
Mulighed 1: Hver proces vælger tilfældigt en liste af IP'er fra interface-API'en (for eksempel ved at udtrække 100 IP'er ad gangen) for at cykle igennem dem, og kalder derefter API'en for at hente dem, hvis den fejler, og den generelle logik er som følger:
1. Hver proces (eller tråd) henter tilfældigt en batch af IP'er fra interfacet og forsøger at hente data fra IP-listen i en løkke.
2. Hvis adgangen lykkes, fortsæt med at tage den næste.
3. Hvis det fejler (såsom timeout, verifikationskode osv.), tag en batch IP'er fra interfacet og fortsæt forsøget.
Ulemper ved løsningen: Hver IP har en udløbsdato; hvis 100 udtrækkes, kan de fleste af sidstnævnte være ugyldige, når den 10. bruges i brug. Hvis du opsætter en HTTP-forespørgsel med en forbindelsestimeout på 3 sekunder og en læsetimeout på 5 sekunder, kan du spilde 3-8 sekunder, og måske kan disse 3-8 sekunder tages dusinvis af gange.
Mulighed 2: Hver proces tager en tilfældig IP fra interface-API'en til brug og kalder derefter API'en for at opnå en IP, hvis den fejler; den generelle logik er som følger:
1. Hver proces (eller tråd) henter tilfældigt en IP fra grænsefladen og bruger denne IP til at tilgå ressourcer.
2. Hvis adgangen lykkes, fortsæt med at tage den næste.
3. Hvis det fejler (såsom timeout, verifikationskode osv.), så vælg tilfældigt en IP fra interfacet og fortsæt forsøget.
Ulemper: At kalde API'er for at få IP-adresser er meget hyppigt, hvilket vil lægge stort pres på proxyserveren, påvirke stabiliteten af API-grænsefladen og kan være begrænset i at udpakke. Dette system er heller ikke egnet og kan ikke drives på en bæredygtig og stabil måde.
Mulighed 3: Først udtrækker du et stort antal IP'er og importerer dem til den lokale database, og tag derefter IP'en fra databasen, den generelle logik er som følger:
1. Opret en tabel i databasen, skriv et importscript, anmod API'en pr. minut (konsulter proxy-IP-tjenesteudbyderens forslag), og importer IP-listen til databasen.
2. Registrer importtid, IP, port, udløbstid, IP-tilgængelighedsstatus og andre felter i databasen;
3. Skriv et grab-script, crab-scriptet læser den tilgængelige IP fra databasen, og hver proces får en IP fra databasen til brug.
4. Udfør crawling, vurder resultaterne, behandl cookies osv., så længe der er en verifikationskode eller fejl, giv denne IP op og skift til en ny IP.
Denne løsning undgår effektivt forbruget af proxyserverressourcer, allokerer effektivt brugen af proxy-IP, er mere effektiv og stabil og sikrer holdbarheden og stabiliteten af crawler-arbejdet. |
Opslået på 17/07/2018 13.54.35
|
|
|
Opslået på 18/07/2018 14.50.55
|
