Zonder proxy-IP zal crawlerwerk moeilijk zijn, dus veel crawler-ingenieurs moeten efficiënte en stabiele proxy-IP kopen. Met een hoogwaardige proxy-IP, kun je achterover leunen en ontspannen? Het is niet zo eenvoudig, en het is ook noodzakelijk om het schema te optimaliseren, middelen rationeel toe te wijzen, de werkefficiëntie te verbeteren en crawlerwerk efficiënter, sneller en stabieler uit te voeren.
Optie 1: Elk proces selecteert willekeurig een lijst van IP's uit de interface-API (bijvoorbeeld het extraheren van 100 IP's tegelijk) om erdoorheen te bladeren, en roept vervolgens de API aan om ze te verkrijgen als deze faalt, en de algemene logica is als volgt:
1. Elk proces (of thread) haalt willekeurig een batch IP's op van de interface en probeert data uit de IP-lijst in een lus op te halen.
2. Als de toegang succesvol is, ga je door met het pakken van de volgende versie.
3. Als het faalt (zoals timeout, verificatiecode, enz.), neem dan een batch IP's van de interface en ga verder met proberen.
Nadelen van de oplossing: Elke IP heeft een vervaldatum; als er 100 worden geëxtraheerd, kan de meeste van de laatste ongeldig zijn wanneer de tiende wordt gebruikt. Als je een HTTP-verzoek opzet met een verbindingstimeout van 3 seconden en een leestimeout van 5 seconden, kun je 3-8 seconden tijd verspillen, en misschien kunnen deze 3-8 seconden tientallen keren worden gepakt.
Optie 2: Elk proces neemt een willekeurig IP van de interface-API om te gebruiken, en roept vervolgens de API aan om een IP te verkrijgen als deze faalt; de algemene logica is als volgt:
1. Elk proces (of thread) haalt willekeurig een IP op van de interface en gebruikt dit IP om toegang te krijgen tot resources.
2. Als de toegang succesvol is, ga je door met het pakken van de volgende versie.
3. Als het mislukt (zoals timeout, verificatiecode, enz.), selecteer dan willekeurig een IP uit de interface en ga verder met proberen.
Nadelen: Het aanroepen van API's om IP-adressen te verkrijgen komt zeer vaak voor, wat grote druk op de proxyserver legt, de stabiliteit van de API-interface beïnvloedt en mogelijk beperkt wordt bij het extraheren. Dit systeem is ook niet geschikt en kan niet op een duurzame en stabiele manier worden uitgevoerd.
Optie 3: Eerst extraheer je een groot aantal IP's en importeer je deze in de lokale database, en neem je vervolgens het IP uit de database; de algemene logica is als volgt:
1. Maak een tabel aan in de database, schrijf een importscript, vraag de API per minuut aan (raadpleeg de suggesties van de proxy IP-serviceprovider), en importeer de IP-lijst in de database.
2. Registreer de importtijd, IP, poort, vervaltijd, IP-beschikbaarheidsstatus en andere velden in de database;
3. Schrijf een grab-script, het crab-script leest het beschikbare IP uit de database, en elk proces verkrijgt een IP uit de database voor gebruik.
4. Voer crawling uit, beoordeel de resultaten, verwerk cookies, enzovoort; zolang er een verificatiecode of fout is, geef dit IP op en verander naar een nieuw IP.
Deze oplossing voorkomt effectief het verbruik van proxyserverbronnen, wijst het gebruik van proxy-IP effectief toe, is efficiënter en stabieler, en zorgt voor de duurzaamheid en stabiliteit van crawlerwerk. |
Geplaatst op 17-07-2018 13:54:35
|
|
|
Geplaatst op 18-07-2018 14:50:55
|
