프록시 IP가 없으면 크롤러 작업이 어렵기 때문에 많은 크롤러 엔지니어들이 효율적이고 안정적인 프록시 IP를 구매해야 합니다. 고품질 프록시 IP를 가지고 있으면 편안히 쉴 수 있을까요? 상황이 그렇게 단순하지 않으며, 계획을 최적화하고, 자원을 합리적으로 배분하며, 작업 효율성을 높이고, 크롤러 작업을 더 효율적이고 빠르며 안정적으로 수행하는 것도 필요합니다.
옵션 1: 각 프로세스는 인터페이스 API에서 무작위로 IP 목록을 선택해 순환시키고, 실패하면 API를 호출해 이를 얻습니다. 일반적인 로직은 다음과 같습니다:
1. 각 프로세스(또는 스레드)는 인터페이스에서 무작위로 IP 배치를 가져와, IP 리스트에서 데이터를 반복적으로 가져오려 시도합니다.
2. 접근이 성공하면 다음 것을 계속 잡으세요.
3. 실패하면(예: 타임아웃, 검증 코드 등), 인터페이스에서 IP 묶음을 가져와 계속 시도합니다.
해결책의 단점: 각 IP는 만료일이 있으며, 100개를 추출하면 10번째 IP를 사용할 경우 대부분의 만료일이 무효가 될 수 있습니다. 만약 HTTP 요청을 3초의 연결 타임아웃과 5초의 읽기 타임아웃으로 설정한다면, 3-8초의 시간을 낭비할 수 있고, 이 3-8초가 수십 번 가져갈 수도 있습니다.
옵션 2: 각 프로세스는 인터페이스 API에서 임의 IP를 가져와 사용하고, 실패하면 IP를 얻기 위해 API를 호출합니다. 일반적인 로직은 다음과 같습니다:
1. 각 프로세스(또는 스레드)는 인터페이스에서 무작위로 IP를 가져와 이 IP를 사용해 자원에 접근합니다.
2. 접근이 성공하면 다음 것을 계속 잡으세요.
3. 만약 실패하면(타임아웃, 검증 코드 등) 인터페이스에서 무작위로 IP를 선택하고 계속 시도합니다.
단점: IP 주소를 얻기 위해 API를 호출하는 일이 매우 자주 발생하여 프록시 서버에 큰 부담을 주고 API 인터페이스의 안정성에 영향을 미치며, 추출이 제한될 수 있습니다. 이 제도 역시 적합하지 않으며 지속 가능하고 안정적인 방식으로 운영될 수 없습니다.
옵션 3: 먼저, 많은 수의 IP를 추출하여 로컬 데이터베이스에 가져오고, 그 다음 데이터베이스에서 IP를 추출합니다. 일반적인 논리는 다음과 같습니다:
1. 데이터베이스에 테이블을 생성하고, 가져오기 스크립트를 작성하며, 분당 API를 요청(프록시 IP 서비스 제공업체의 제안을 참고), IP 목록을 데이터베이스에 가져오세요.
2. 가져오기 시간, IP, 포트, 만료 시간, IP 가용성 상태 및 기타 데이터베이스 필드를 기록합니다;
3. grab 스크립트를 작성하면, crab 스크립트가 데이터베이스에서 사용 가능한 IP를 읽고, 각 프로세스가 데이터베이스에서 IP를 얻어 사용합니다.
4. 크롤링을 수행하고, 결과를 판단하며, 쿠키를 처리하는 등 검증 코드나 실패가 있을 경우 해당 IP를 포기하고 새로운 IP로 변경합니다.
이 솔루션은 프록시 서버 자원 소비를 효과적으로 피하고, 프록시 IP의 사용을 효과적으로 할당하며, 더 효율적이고 안정적이며, 크롤러 작업의 내구성과 안정성을 보장합니다. |