큐잉과 접속 여부 판단을 위해 MySQL을 사용하고 있는데, Redis의 지속성 특성이 별로 좋지 않고, 당시에는 Redis나 다른 것을 사용할 생각이 없었기 때문에 MySQL을 사용하는데는 문제가 없습니다. 당분간.
구체적인 방법은 URL의 md5 값을 고유하게 인덱싱하는 것입니다. 각 쿼리는 빠르고 테이블 구조는 간단합니다.
대기열은 테이블 조회 형식을 사용하며 SQL은 다음과 같습니다(구체적인 상태는 자체 정의된 일부 상태를 나타냄).
상태 = 0인 t_down_task에서 *를 선택하고 ID 제한 1로 주문;
정기적으로 완료된 작업 삭제

http://en.wikipedia.org/wiki/Bloom_fi...

4G 메모리는 매우 큰 BloomFilter를 열 수 있습니다. 각 URL은 URL 길이에 관계없이 몇 비트만 필요합니다. BloomFilter에는 특정 오류율(예: 구성에 따라 1/1000 또는 1%)이 있어 일부 웹페이지가 누락되지만 반복적으로 크롤링되지는 않습니다.

4G 메모리로 BloomFilter를 여는 것만으로는 충분하지 않은 경우 작성자는 크롤링된 웹 페이지를 저장하는 방법을 고려해야 합니다.

데이터의 양이 그다지 크지 않은 경우 KV 저장소의 md5 해시 저장소는 상대적으로 안정적입니다. 인덱스의 양이 크면 충분하지 않을 수 있으므로 다음과 같은 공간 압축이 포함된 일부 특수 알고리즘을 사용해야 합니다. 위에서 누군가가 언급한 블룸필터

어떤 사람들은 Memcache 프로토콜(http://code.google.com/p/mc-bloom-fil...)을 사용하여 이 알고리즘 저장소를 구현하기도 했습니다.

일부 영구 k/v 데이터베이스를 고려할 수 있으며 leveldb를 사용하는 것이 좋습니다.

이 작업을 수행하려면 Redis를 사용하지 말고 파일 시스템을 직접 사용하세요

수집된 URL은 MD5를 통해 16진수 문자열로 변환된 후 4자씩 디렉토리로 사용되며, 마지막 4자는 파일명으로 사용됩니다.

URL 수집 여부를 확인하려면 현재 URL을 직접 MD5하고 위의 규칙에 따라 파일 경로를 생성한 후 파일 경로가 존재하는지 직접 확인합니다.

최고의 블룸필터. 다음과 같이 사용할 수 있습니다. leveldb를 사용하여 URL을 저장한 다음 Bloomfilter를 사용하여 쿼리할 때 라이브러리에 없는 대부분의 URL을 차단하면 충분합니다.
lz가 크롤링하려면 URL이 몇 개 필요합니까? 수억 개에 달하는 URL이 많고 Hadoop이 있는 경우 Hadoop을 사용하여 새 URL과 기존 URL의 중복을 제거할 수도 있습니다.