Redis 튜 토리 얼 의 대리 ip 풀 디자인 방법 상세 설명

머리말
프 록 시 ip 은 설정 이 간단 하고 저렴 하기 때문에 반 파충류 의 수단 으로 자주 사용 되 지만 안정성 은 지적 해 왔 다.양질 의 대리 ip 을 선별 하 는 것 은 간단 하지 않 습 니 다.설령 비용 을 지불 하고 구 매 하 는 대리 ip 소스 라 하 더 라 도 판매 자 는 100%사용 할 수 있다 는 것 을 보장 하지 못 합 니 다.또한 대리 ip 의 생명 주기 도 예측 할 수 없 으 며,아마도 1 초 동안 사용 할 수 있 을 것 이 며,다음 초 에 거리 로 뛰 어 들 것 이다.이러한 이유 로 대리 ip 을 사용 하 는 파충류 프로그램 에 많은 불안정 요 소 를 가 져 올 수 있다.프 록 시 ip 의 영향 을 제거 하려 면 일반적인 방법 은 프 록 시 ip 풀 을 만 드 는 것 입 니 다.매번 연못 에 와 서 ip 을 찾 아 달라 고 요청 할 때마다 사용 한 후에 돌려 주 고 연못 안의 ip 이 모두 사용 할 수 있 도록 하 는 것 입 니 다.본 고 는 다음 에 Redis 를 어떻게 사용 하여 대리 ip 풀 을 구축 하고 자동 업데이트,자동 선택 을 실현 하 는 지 연구 하고 자 한다.
전체 흐름

위의 그림 에서 보 듯 이 왼쪽 은 전체 절차 의 폐쇄 고리 가 형성 되 었 고 파충류 프로그램 에서 독점 적 인 방식 으로 대리 ip 을 받 아 기어 오 르 기 까지 ip 을 반환 했다.이 절 차 는 사실 그다지 엄밀 하지 않다.만약 에 파충류 프로그램 이 이상 하 게 중단 되면 ip 를 돌려 주지 못 하고 이 ip 을 순환 적 으로 이용 하지 못 하 게 할 것 이다.그러나 대리 ip 자체 의 특징 으로 양 이 많 고 순환 적 으로 이용 하 는 가치 가 크 지 않 기 때문에 이런 상황 은 let it go 입 니 다.
위 에서 도 ip 은 독점 적 인 방식 으로 얻 는 것 이 라 고 언급 했다.만약 에 전혀 관련 이 없 는 두 개의 사 이 트 를 오 르 려 면 원래 하나의 ip 이면 되 는데 지금 은 두 개가 필요 하 다.자원 의 최대 화 를 위해 채널 ip 풀 과 총 대리 ip 풀 을 도입 했다.두 사 이 트 는 두 채널 로 각자 독점 하고 서로 관련 이 없다.총 연못 은 모든 ip 을 저장 하고 채널 마다 공유 하 는 것 이다.만약 에 하나의 ip:1.1.1.1 만 전체 연못 에 있다 고 가정 하면 A 사 이 트 를 오 르 면 전체 연못 에서 A 채널 의 ip 풀 을 찾 은 다음 에 A 파충류 프로그램 이 A 채널 ip 풀 에서 1.1.1.1 을 꺼 내 사용 할 것 이다.이때 1.1.1.1 은 전체 연못 에 있 지만 A 채널 의 ip 풀 은 1.1.1.1 을 포함 하지 않 는 다.B 사이트 에 오 르 는 것 도 똑 같은 절차 로 1.1.1.1 을 받 았 고 B 자신의 채널 풀 에서 만 얻 었 다.다음은 총 연못 과 채널 연못 에 대해 자세히 말씀 드 리 겠 습 니 다.
총 에이전트 ip 풀
총 연못 의 역할 은 사용 가능 한 모든 ip 을 공유 하 는 것 입 니 다.그러나 ip 을 저장 하 는 연못 으로서 자동 으로 우수한 것 을 선택 할 수 없습니다.이곳 의 선택 은 보통 속도 가 낮은 ip 이 쉽게 선별 되 기 를 바 랍 니 다.그래서 우 리 는 연못 의 ip 이 그들의 지연 상승 순서에 따라 배열 되 고 RedisSorted Sets 데이터 구 조 를 통 해 이 루어 질 수 있 기 를 바 랍 니 다.지연 시간 으로 score 를 표시 합 니 다.ip 는 member 를 나타 낸다.
사용ZADD 새 ip 추가 또는 ip 업데이트 지연:

> ZADD proxy_global_ips 200 1.1.1.1:8080 100 2.2.2.2:80 300 3.3.3.3:8888
(integer) 3

ZRANGE 을 사용 하여 ip 를 가 져 옵 니 다.가 져 온 개 수 를 지정 할 수 있 습 니 다.예 를 들 어 두 개 를 가 져 옵 니 다.

> ZRANGE proxy_global_ips 0 1 WITHSCORES
1) "2.2.2.2:80" 
2) "100" 
3) "1.1.1.1:8080" 
4) "200" 

채널
채널 IP 탱크 의 역할 은 총 탱크 의 IP 를 최대 화하 고 다른 채널 의 IP 탱크 를 격 리 하 는 것 이다.한 ip 의 사용 횟수 가 너무 많 으 면 타 겟 사이트 에 의 해 차 단 될 확률 이 높 기 때문에 여기 서도 우수한 것 을 선택해 야 합 니 다.사용 횟수 가 적은 ip 을 우선 선별 해 야 합 니 다.같은 이치 로 도 사용Sorted Sets입 니 다.사용 횟수 는 score 를 나타 내 고 ip 은 member 를 표시 합 니 다.여기 서 전체 연못 과 현저 한 차이 점 은 key 가 고정 적 이지 않 고 채널 이름 을 조합 해 야 합 니 다.이렇게 채널 간 의 격 리 를 보장 합 니 다.예 를 들 어 채널 abc 의 key:proxy_channel_abc_ips.
채널 연못 의 ip 은 독점 적 인 방식 으로 꺼 내야 하기 때문에 우 리 는ZPOP 방법 이 필요 합 니 다.어떻게 Redis 자체 가 없 습 니까?다행히 Lua 시 뮬 레이 션 을 통 해 원자 조작 에서 ip 을 꺼 낸 다음 에 삭제 할 수 있 습 니 다.

> eval "local el = redis.call('zrange', KEYS[1], 0, 0, 'WITHSCORES'); redis.call('zrem', KEYS[1], el[1]); return el;" 1 proxy_channel_abc_ips

채널 ip 풀 에 ip 추가:

> ZADD proxy_channel_abc_ips INCR 0 1.1.1.1:8080

여 기 는 전체 연못 과 달리INCR 옵션 이 하나 더 있 습 니 다.이것 은 Redis 3.0.2 버 전에 서 지원 하 는 새로운 기능 입 니 다.즉,ZADD 에서 member 충돌 이 발생 할 때 사용 하 는 처리 방식 을 지정 합 니 다.INCR 말 그대로 충돌 후 score 를 누적 하 는 방식 입 니 다.왜 이 옵션 을 사용 하 는 지 아래 절 차 를 보 세 요.

채널 풀 에서 1.1.1.1 만 있 고 사용 횟수 는 10 이다.총 연못 도 1.1.1.1 이 고 첫 번 째

이다.

스 레 드 A 추출 1.1.1.1

스 레 드 B 는 채널 연못 에서 ip 을 찾 았 지만 찾 지 못 했다.총 연못 에서 ip 을 보충 하여 채널 연못 까지:ZADD proxy_channel_abc_ips 0 1.1.1.1;1.1.1.1

꺼 내기

스 레 드 A 반환 1.1.1.1:ZADD proxy_channel_abc_ips 11 1.1.1.1

스 레 드 B 반환 1.1.1.1:ZADD proxy_channel_abc_ips 1 1.1.1.1

5 단계 가 끝 난 후 ip 1.1.1.1 의 수 는 우리 가 예상 한 12 가 아 닌 1 로 잘못 리 셋 되 었 습 니 다.INCR 옵션 을 사용 하면 이 어색 함 을 피 할 수 있 습 니 다.사실은 이것 도 최종 계산 이 정확 할 수 밖 에 없고 중간 에 예상 치 못 한 상황 이 있 을 수 있 습 니 다.예 를 들 어:

채널 연못 에 1.1.1.1 이 있 고 사용 횟수 는 10 이 며 2.2.2.2 도 있 으 며 사용 횟수 는 2 이다.총 연못 도 1.1.1.1 이 고 첫 번 째

이다.

스 레 드 A 추출 1.1.1.1

스 레 드 B 추출 2.2.2

스 레 드 C 는 채널 연못 에서 ip 을 찾 았 지만 찾 지 못 했다.전체 연못 에서 ip 을 보충 하여 채널 연못 까지:ZADD proxy_channel_abc_ips 0 1.1.1.1;1.1.1.1

꺼 내기

스 레 드 C 반환 1.1.1.1:ZADD proxy_channel_abc_ips INCR 1 1.1.1.1

스 레 드 B 반환 2.2.2.2:ZADD proxy_channel_abc_ips INCR 3 2.2.2.2

스 레 드 D 가 연못 에 와 서 ip 을 찾 았 는데 사용 횟수 가 적은 것 에 따라 1.1.1.1 이 배정 되 었 다.이것 은 우리 가 기대 하 는 것 이 아니 라 1.1.1.1 이 실제 적 으로 12 번 사용 되 었 다.우 리 는 2.2.2 가 꺼 지 기 를 바란다

만약 에 이 문 제 를 피 하려 면 간단 하고 거 친 방법 은 채널 연못 의 용량 을 늘 려 서 ip 수가 동시 다발 적 인 스 레 드 수 보다 영원히 많 도록 하 는 것 이다.
업데이트
ip 와 관련 된 두 가지 속성:지연(페이지 를 오 르 는 데 걸 리 는 시간)과 사용 횟수.위 에 서 는 그것들 이 자동 으로 우수한 것 을 고 르 는 것 에 따라 어떻게 갱신 하 는 지 에 대해 서 만 이야기 했다.지연 과 사용 횟수 의 업 데 이 트 는 파충류 프로그램의 협조 가 필요 하 며,프로그램 에 서 는 시간 과 사용 횟수 를 기록 하고,ip 를 반환 할 때 최신 값 을 총 연못 과 채널 연못 에 가 져 다 주어 야 한다.위의 채널 ip 탱크 의 예 도 언급 되 었 다.매번 ip 을 반환 할 때마다 최신 사용 횟수 를 가 져 가 야 하고 그 다음 에 ip 의 지연 시간 을 전체 연못 에 업데이트 해 야 한다.ip 을 반환 할 때 사용 에 실패 한 경우 이 ip 을 전체 연못 에서 삭제 하여 이 ip 이 더 이상 사용 되 지 않도록 해 야 합 니 다.현재 채널 풀 은 돌려 주지 않 아 도 됩 니 다.다른 채널 풀 은 어떠한 처리 도 하지 않 습 니 다.ip 은 현재 채널 에서 사용 할 수 없 기 때 문 입 니 다.보통 차단 되 어 있 기 때문에 다른 채널 은 사용 할 수 있 습 니 다.확실히 사용 할 수 없 더 라 도 다른 채널 에서 ip 을 반환 할 때 삭 제 됩 니 다.
이 두 속성 은 모두 Redis 에서 업데이트 할 수 있 습 니 다.ip 을 가 져 올 때Hashs ip 에 해당 하 는 획득 시간 과 사용 횟수 를 저장 합 니 다.반환 시Hashs 에서 시간 을 꺼 내 지연 시간 을 계산 하고 사용 횟수 를 꺼 내 1 을 더 한 다음 에 총 연못 과 채널 연못 에 각각 업데이트 한다.그리고 위 에서 언급 한 ip 획득 이 기대 에 부합 되 지 않 는 문 제 를 피 할 수 있다.
총결산
레 디 스에 서 업데이트 하 는 방법 도 단점 이 있 습 니 다.지연 시간 은 가 져 오고 반환 하 는 전송 시간 을 포함 합 니 다.파충류 프로그램 이 ip 를 여러 번 가 져 오 면 사용 횟수 통계 가 적 습 니 다.물론 프로그램 에서 Redis 업데이트 ip 의 속성 을 여러 번 호출 하여 해결 할 수 있 습 니 다.이렇게 하면 전체 절차 의 복잡성 을 증가 하고 스스로 평가 해 야 합 니 다.
개인 은 프로그램 에 기록 하 는 경향 이 있 고 마지막 에 Redis 에 업데이트 된다.이 방안 의 논 리 는 확실히 엄밀 하지 않 지만 문제 가 발생 해도 심각 한 결 과 를 초래 하지 않 을 것 이다.프로그램의 건장 성도 bug 가 허용 되 지 않 는 것 이 아니 라 bug 가 나타 나 는 것 이 좋 습 니 다.
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.궁금 한 점 이 있 으 면 댓 글 을 남 겨 주 십시오.