Proxy IP nélkül a crawler munka nehéz lesz, ezért sok crawler mérnöknek hatékony és stabil proxy IP-t kell vásárolnia. Magas minőségű proxy IP-vel tudsz hátradőlni és pihenni? A dolgok nem ilyen egyszerűek, és szükség van a rendszer optimalizálására, az erőforrások ésszerű elosztására, a munkahatékonyság javítására, valamint a crawler munka hatékonyabb, gyorsabb és stabilabb elvégzése is.
1. lehetőség: Minden folyamat véletlenszerűen kiválaszt egy IP-listát az interfész API-ból (például egyszerre 100 IP-t kihúzva), hogy átnézze őket, majd ha meghibásodik, az API-t hívja meg, és az általános logika a következő:
1. Minden folyamat (vagy szál) véletlenszerűen letölt egy IP-csomagot az interfészről, és megpróbálja az adatokat az IP-listáról egy hurokban visszanyerni.
2. Ha sikeresen sikeres, folytasd a következő megszerzését.
3. Ha meghibásodik (például időkorlát, ellenőrző kód stb.), vegyél ki egy adag IP-címet az interfészről, és folytasd a próbálkozást.
A megoldás hátrányai: Minden IP-nek van lejárati dátuma, ha 100-at nyernek ki, a 10. példány használatakor, az utóbbi többsége érvénytelen lehet. Ha HTTP kérést állítasz be 3 másodperces kapcsolati időkorláttal és 5 másodperces olvasási időkorláttal, akkor 3-8 másodpercet pazarolhatsz, és talán ezt a 3-8 másodpercet tucatnyi alkalommal is meg lehet ragadni.
2. lehetőség: Minden folyamat egy véletlenszerű IP-t vesz fel az interfész API-jából, majd meghívja az API-t, hogy megszerezze az IP-t, ha az meghibásodik, az általános logika a következő:
1. Minden folyamat (vagy szál) véletlenszerűen letölt egy IP-címet az interfészről, és ezt az IP-t használja az erőforrásokhoz való hozzáféréshez.
2. Ha sikeresen sikeres, folytasd a következő megszerzését.
3. Ha meghibásodik (például időkorlát, ellenőrző kód stb.), akkor véletlenszerűen válassz egy IP-címet az interfészről, és folytasd a próbálkozást.
Hátrányok: Az API-k hívása IP-címek megszerzéséhez nagyon gyakori, ami nagy nyomást gyakorol a proxy szerverre, befolyásolja az API interfész stabilitását, és korlátozhatja a kinyerést. Ez a rendszer sem megfelelő, és nem működtethető fenntartható és stabil módon.
3. lehetőség: Először nagy számú IP-címet vonjunk ki és importáljuk őket a helyi adatbázisba, majd az IP-t az adatbázisból vegyük ki, az általános logika a következő:
1. Hozz létre egy táblázatot az adatbázisban, írj egy import szkriptet, kérd az API-t percenként (kérd meg a proxy IP szolgáltató javaslatait), és importáld az IP-listát az adatbázisba.
2. Jegyezze fel az importidőt, IP-t, portot, lejárati időt, IP elérhetőségi állapotot és egyéb mezőket az adatbázisban;
3. Írj egy grab scriptet, a crab script felolvassa az adatbázisból elérhető IP-t, és minden folyamat szerez egy IP-t az adatbázisból használatra.
4. Végezze el a crawlinget, ítélje meg az eredményeket, dolgozza fel a sütiket, stb., amíg van ellenőrző kód vagy hiba, add fel ezt az IP-t, és válts új IP-re.
Ez a megoldás hatékonyan elkerüli a proxy szerver erőforrások fogyasztását, hatékonyan osztja ki a proxy IP használatát, hatékonyabb és stabilabb, valamint biztosítja a crawler munka tartósságát és stabilitását. |