머리말
오늘, 우리는 설계 문제의 인터뷰 후보자의 연구에 매우 적합 매우 간단 고성능 짧은 체인 시스템, 짧은 체인 설계 시스템의 모습을 설계 할 수 있지만, 각 포인트는 많은 지식을 확장 할 수 있지만, 방법에 대한 이야기,이 문서는 것입니다 우리는 당신이 단순히 관련 시스템에서 할 몇 가지 아이디어를 제공하도록 설계 고성능 짧은 체인 시스템의 생산에 2 년 동안 안정적인 동작을 결합합니다, 나는 약간의 도움을받을 수 있도록 노력하겠습니다.
정보의 양에 다음과 같은 측면을 설명 할 것이 문서에서는, 우리가 읽기 수확이 있어야합니다 많은 생각 각 지점에 포함
- 혜택, 왜 그것을 설계해야하는지, 그래서 짧은 체인, 그것은 긴 체인 향기없는
- 짧은 체인 점프의 기본 원리
- 생성 짧은 사슬의 여러 가지 방법
- 아키텍처 지원 짧은 체인
참고 :이 글의 초점이 아니므로, 블룸 필터, 눈송이 및 다른 많은 기술을 포함, 당신이 더 자신에 대해 다음 학습, 또는 다른 매우 긴 것입니다 공간을 말하기 시작 읽어 보는 것이 좋습니다
짧은 체인의 장점을 무엇 그래서, 그것은 긴 체인 향기없는
내가 메시지를 마케팅 보내 다음과 같은 괴짜 시간을보고 아래의 파란색 링크를 클릭 (짧은 체인)
마지막은 브라우저의 주소 표시 줄에 긴 사슬로 표시됩니다.
왜 짧은 체인을 사용, 긴 사슬의 직접 사용 단어의 짧은 체인과 좋은 바깥 다음, 그것을 할 것이라고 말했다
1, 링크 단축, 내용 길이에 대한 제한과 파견 플랫폼은 편집 가능한 텍스트는 더된다
가장 일반적으로는, 트위터 직접적 긴 체인 증오까지의 문자열, 다른 편집 내용은, 짧은 체인을 실행하는 경우에만 보낼 수 140 자, 다음 링크의 길이가 크게 감소, 자연의 편집을 정의 많이 더 쓰기.
또 다른 예는 일반 메시지 길이 제한이 긴 체인, 문자 메시지는 스물셋 머리로 분할 될 가능성이있는 경우, 문서를 발행 귀찮게 왜이 산 마오,로 SMS 요금의 머리를했다입니다. 또한 짧은 체인 콘텐츠 레이아웃도 기쁘게되어 더 심미적으로.
2, 존재하지 않는 집중, 짧은 체인 문제를 식별하기 어려운 두 가지 차원 코드 워드의 긴 체인이 경우 우리는 종종 다른 사람들과 2 차원 코드 공유로 링크 설정해야하고, 등이 표시
3 링크가 너무 오래 자동으로 일부 플랫폼에서 하이퍼 링크로 인식되지 않습니다
손톱에 도시 된 바와 같이, 긴 링크 만 식별 섹션, 짧은 주소로 이러한 문제를 식별 할 수 없기 때문에
짧은 체인 점프의 기본 원리
는 IT 볼 수있는 위, 짧은 체인 혜택에서, 그것은 그것을 사용하는 방법입니다. 우리는 브라우저의 복 주머니를 살펴
이는 상기 요청 후, 302 (리다이렉트) 위치를 반환 응답 상태 코드가 다음 브라우저는 최종 응답의 상호 작용의 전체 흐름도를 제공하는 다른 장쇄를 요청, 장쇄 것을 알 수있다
주요 단계는 짧은 URL 리디렉션 액세스 B 후 방문하는 것입니다, 다음 질문은, 301 및 302 리디렉션, (301, 302) 사이의 차이를 볼 필요가 결국 어느 사용
- 대표 (301), 영구 리디렉션 긴 링크, 브라우저 요청이 짧은 체인을 갈 다음 번에 얻을 수있는 첫 번째 요청 후 말을하는 것입니다, 그것은 서버에 짧은 URL을 요청하지만, 브라우저의 캐시에서 직접 적용되지 않습니다 서버 수준 있도록, 당신은이 링크가 링크가 단지 활동의 경우,이 활동의 효과를 분석 할 수 없습니다, 짧은 URL의 몇 번의 클릭으로 얻을 수 없습니다. 따라서, 우리는 일반적으로 (301)를 사용하지 않습니다.
- (302) , 대신 임시 리디렉션 , 어떤 요청 짧은 체인마다 그래서 비록 (302)와, (캐시 제어 또는 묵시적 만료 된 브라우저 캐시로 응답하지 않는 한) 너무 쉽게 클릭 서버의 수를 계산하기 위해 서버에 짧은 URL을 요청하는 것을 의미합니다 서버가 압력의 비트를 추가 할 것이다, 그러나 매우 중요한 데이터 오늘,이 코드는 가치가있다, (302)를 사용하는 것이 좋습니다!
생성 짧은 사슬의 여러 가지 방법
1 해시 알고리즘
어떻게 우리가 짧은 체인, 위의 예에서 짧은 체인의주의 깊은 관찰을 생성 할 수 있습니다,이되지 해시 함수로, 문자의 문자열로 매핑하는 방법, 문자의 문자열로 매핑 짧은 체인 도메인 이름 + 긴 체인에 의해 너무 오래 체인을 고정 것이 분명하다 우리는 다음과 같은 설계 아이디어를 가지고, 그래서 당신을 위해 일을하는
그런 다음 해시 함수는 어떻게, 나는 사람들이 약간의 과잉을하고, 사실, MD5, SHA 알고리즘을 사용하여 말의 많은이 있어야 생각을 취할하지만이 성능의 손실이있을 것을 의미 암호화되어 있기 때문에, 우리는 정말 치료를하지 않습니다 반대로 해독의 어려움이 있지만, 더 운영 및 해시 충돌 확률의 속도에 대해 우려.
이 많은 사람들이 여기에 있습니다 MurmurHash 구글 알고리즘을 생성하는 것이 좋습니다 같은 해시 알고리즘을 만날 수, MurmurHash는 것입니다 암호화되지 않은 일반 해시 검색 작업에 대한 해시 함수. 규칙 강력한 키, 임의 분배 MurmurHash 성능 향상을 위해 다른 인기있는 해시 함수와 비교. 비 MD5에 비해, 이러한 기능의 SHA 성능이 확실히 높다는 것을 암호화 수단은, 그것이 2008 년에 나타납니다 그래서 있지만, 이러한 장점 때문에, 그것은 정확하게 (사실, 성능이 더 MD5 암호화 알고리즘 등보다 10 배입니다)하지만, 그것은 널리 레디 스, Memcache를, 카산드라, HBase를, 적용되었습니다 루씬 , 그리고 다른 많은 잘 알려진 소프트웨어입니다.
내레이터 : 작은 에피소드가있다, MurmurHash 명성 후, 저자는 구글의 제안을 가지고, 그래서 더 많은 오픈 소스 프로젝트를 수행 어쩌면 명성 당신은 실수로 ^ _ ^ 구글의 서비스를받을 수 있습니다.
MurmurHash 제공 가능한 URL 패스 짧은하자 두 해시 값의 길이, 32 비트, 128 비트, 우리는 32 비트의 해시 값을 선택, 32 비트는 중소 기업을위한 약 43 억의 최대를 나타낼 수 있습니다 비즈니스 측면에서 충분. 괴짜 장쇄 위에서 MurmurHash 계산해야 함, 해시 값이 우리가 지금 고정 단쇄 단쇄 도메인 + 해시 값을 갖고, 획득 = 3,002,604,296 gk.link/a/300260429 ...
어떻게 도메인 이름을 단축하기 위해?
어떤 사람들은 트릭, 3002604296 다음과 같이 62 진수를 켜 진수, 우리는 길이를 단축 진수 (62)에 넣어,이 해시 값은 십진수 얻을이, 도메인 이름이 조금 긴 말 :
우리가 (3002604296) 그래서 10 = (3hcCxy)를 10 , 그것은 6 10에서 감소되었다! 그래서 지금 우리는 짧은 체인 얻을 gk.link/a/3hcCxy을
음성 해설 : 6 62 진수 번호 56800000000를 나타낼 수있다, 더 충분 긴 체인 변환에 대처하기
어떻게 해시 충돌의 문제를 해결하기 위해?
이 해시 함수이기 때문에, 해시는 필연적으로 (낮은 확률에도 불구하고) 충돌을 생성 할 것이다, 어떻게 그것을 해결합니다.
우리는 긴 사슬로 이동할 수 있습니다 액세스 짧은 체인에 대한 액세스를 알고 있기 때문에, 다음 두 전에이 매핑 관계는 여기에 우리가 가게에 MySQL을 사용하도록 선택 등의 레디 스 또는 MySQL을로 사용할 수, 저장해야합니다. 해야 테이블 구조는 다음과 같습니다
CREATE TABLE `short_url_map` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`lurl` varchar(160) DEFAULT NULL COMMENT '长地址',
`surl` varchar(10) DEFAULT NULL COMMENT '短地址',
`gmt_create` int(11) DEFAULT NULL COMMENT '创建时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
复制代码우리는 다음과 같은 설계 아이디어를 가지고 그래서.
- MurmurHash 단쇄 후의 장쇄 (lurl).
- 짧은 체인은 관련 기록이 short_url_map 경우하지 않을 경우, 저장된 데이터베이스에 긴 체인 짧은 체인 대응 관계를 확인하기 위해 테이블을 찾을 수 있습니다.
- 존재하는 경우, 관련 지침은 다음과 같은 "중복"로, 좋은 긴 문자열에 사용자 정의 필드를 바느질, 기록 된 후 첫 번째 작업을 수행 할 필드 문자열 엉덩이 "lurl + 중복"을 가지고, 또는 마지막 경우 그것을 반복하고 소요되는 시간만큼 문자열 필드 아, 긴 체인을 싸울 때, 즉 원래 문자열의 좋은 긴 체인 짧은 체인을 제거 이러한 사용자 지정.
물론 위의 단계를 최적화 할 수 있습니다,하지만 여전히 두 개의 SQL 쿼리 후 레코드를 삽입 할 (짧은 체인 검사 기록에 따라, 데이터베이스에 체인의 길이와 대응), 높은 동시성의 경우 것은 분명히 병목이 될 것입니다.
음성 해설 : 일반 데이터베이스 (뿐만 아니라 스토리지 컴퓨팅) 응용 프로그램 서비스가 두 개의 서로 다른 서버에 배포 될 것입니다, 당신은 두 개의 SQL이 네트워크 통신을 실행하는 데 필요한 두와 통신하기 위해이 두 네트워크는 전체 짧은 체인을 SQL 실행 시스템 성능 병목 거짓말!
그래서를 최적화하는 방법
- 첫째, 우리는 짧은 체인 필드 surl 플러스 고유 인덱스를 제공해야
- 장쇄 MurmurHash는 단쇄 후의 때, 대응 관계의 사슬 길이는 직접적으로 DB에 삽입이 단쇄의 기록이 더 DB, 삽입물을 함유하지 않는 경우, 포함 된 경우, 고유 인덱스, 길이만큼 긴 시간을 위반 한 우리와 결합 위의 상단 체인 사용자 정의 필드 "중복"다시 해시 한 후 고유 인덱스 위반의 경우 보인다 플러그 말했다는 다중 실행 단계,하지만 우리는 충돌의 가능성을 알 필요가 매우입니다 MurmurHash 이 방식은 허용 너무 낮아서 실질적 덜 발생한다.
물론, 많은 양의 데이터의 경우, 충돌 증가의 가능성은, 우리는 Jiabu 긴 필터를 최적화 할 수 있습니다.
하지 않을 경우 긴 사슬 짧은 사슬의 새로운 세대가 첫 번째 체인이 존재하지 않는 URL 데시벨이 짧은 설명, 블룸 필터의이 짧은을 찾아하는 블룸 필터에 의해 생성 된 모든 짧은 URL을, 건설, 당신은 삽입 할 수 있습니다!
VO : 블룸 필터는 매우 메모리 저장 데이터 구조 천만 블룸 필터의 길이 만 125 M 메모리 공간이다.
요약하면, 해시 함수 디자인 경우, 전체 디자인 아이디어는 다음이다
짧은 체인을 생성하는 데 사용되는 해시 알고리즘이 실제로 우리의 비즈니스 요구를 충족 할 수 있었다, 우리는 짧은 체인 방식으로 증가 시퀀스를 생성하는 방법을 살펴
2 증분 시퀀스 알고리즘
우리는 장쇄 전송 요청 후 62로 변환된다 단쇄, ID를 할당 발전기 ID를 수신 할 때, 1,2,3- ID 증분 정수 같은 자기 ID 생성기의 증식을 유지 짧은 체인 도메인 이름 뒤에 모자이크 진수는 그것을 설계 생성하는 방법에 대한 증식,이 ID를 최종 짧은 URL을 얻을 수 있습니다. 그 디자인이 매우 중요하므로 빠 다행히도 높은 동시성은 낮은 피크 ID 생성에 합성기의 증식 ID는, 시스템 병목 될 수있는 경우.
주로 ID를 얻기 위해 다음과 같은 네 가지 방법에
1, 클래스 UUID
그것은 단순히이다 UUID UUID UUID.randomUUID = (), 이러한 방식으로 생성 된 UUID, UUID (범용 고유 식별자) 전역 고유 식별자는 상기 번호를 참조하는 컴퓨터가 생성 한 동일 시간과 공간에서 확보 모든 기계는 독특하지만, 삽입 된 DB가 자주 발생할 수 있습니다 때이 방법으로 생성 된 ID는 길고 무질서한 상대적이다 페이지 분할 , 삽입 성능에 영향을 미칩니다.
2 레디 스
레디 스 좋은 선택입니다으로, 좋은 성능, 대부분의 비즈니스 시나리오에 맞게 + 요청 w (10)를 지원할 수있는 독립형하지만, 어떤 사람들은 기계가 그것을 수행 할 수없는 경우, 당신은 더 한 가지 이상 설정할 수 있습니다 말, 예를 들어, 나는, (10) 기계를 정렬 각 시스템은 단지 테일 번호 0,1,2, ... ID 9 및 10을 생성 할 수있는 각 또한, 한 에이전트가 라인에서 발생하여 전송 된 ID 번호에 할당 된 랜덤 ID를 생성하기 위해 제공되어있다.
그러나 레디 스 등의 프로그램을 필요로합니다 (같은 짧은 체인 ID 수) 지속 간주, 재해 복구, 약간 높은 비용.
3 눈송이
눈송이는 좋은 선택이지만, 눈송이는 시스템 클럭의 일관성에 따라 달라집니다. 기계 시계 콜백 시스템의 경우, 충돌 ID, ID 또는 장애의 원인이 될 수 있습니다.
4, MySQL은 기본 키를 증분
우리가 ID 짧은 체인으로 MySQL의 자동 증가 기본 키를 사용하므로 이러한 방법으로 간단한의 사용은 쉽게 확장합니다. 다음과 같이 간단히 요약 :
질문은 그래서, 짧은 체인 ID로 MySQL 증가 ID가 높은 동시성에서, DB 쓰기는 큰 압력을 수행하는 방법이 상황이 될 것입니다 경우.
이러한 사전 증가 ID를 생성 할 수 있는지 여부, ID가 수행 할 때 생성하는 데 사용되어야 생각해?
다음과 같이 프로그램은 다음과 같습니다 :
전용 번호 테이블을 설계 변경, 각 레코드가 삽입되고, 단쇄 예약 번호 (기본 키 ID * 1000-999) (기본 키 ID * 1000) 섹션들의 수와 같은 다음
빠 테이블 : url_sender_num
도시 같이 단쇄 시작 ID tmp_start_num의 대표 아이디 tmp_end_num 단쇄 대표 종료.
요청이있을 때 긴 사슬 짧은 사슬 전달은 기계, 짧은 체인 세그먼트의 할당 번호로 나가서 여부에이 기계의 모습을 명중 할당 된 테이블의 레코드 번호를 만들어 삽입, 기계는 짧은 체인 분포의 범위에있을 것입니다 tmp_end_num tmp_start_num에 사이 ID입니다. 발행 ID 번호가 tmp_end_num에 도달하면 tmp_start_num에서 할당,이 tmp_end_num에 할당 된, 아이디 범위 세그먼트가 다음 숫자 ID 범위를 획득 한 머리에 머리의 레코드 번호를 삽입하기 위해 테이블에 가서, 이상 할당 된 설명했다.
음성 오버 : 컴퓨터에 그것을 구현하는 방법을 증가 짧은 체인 ID에서 이것에 대해 생각, 당신은 레디 스를 사용할 수 있지만 간단한 해결책은 물론, AtomicLong, 단일 시스템에서 좋은 성능을 사용하는 것입니다뿐만 아니라 동시의 안전을 보장하기 위해 경우 동시성 많은 양의 , AtomicLong의 성능은 OK, 당신이 높은 동시성에서 LongAdder, 더 뛰어난 성능을 사용하는 것을 고려 할 수 없습니다.
전체 설계는 다음과 같습니다
문제는 간단한에, 우리는 기본 키 체인, 짧은 체인 ID의 길이에 매핑 테이블을 만들 것이다, ID가 짧은 체인 인 빠 ID와 제어를 인수, 잉글랜드 축구 협회를 해결하지만, 에주의 할 필요가있다, 우리는 여러 개의 동일한 긴 체인이 긴 체인을 기반으로 상관 DB 레코드가 있는지 확인하기 위해 먼저 찾기 위해 시간을 필요로이 경우, 다른 짧은 체인 ID를 생성 방지해야 할 수도 있습니다, 일반적인 관행이다 긴 체인 인덱스를 할 수 있지만, 인덱스가 훨씬 작은 수 있도록, 우리는 MD5와 같은 긴 사슬의 압축을 적절한 수 있으며, 다음 MD5 필드의 긴 체인 인덱스를 할 수 있도록 다음 인덱스 공간이 큰 것입니다. 따라서 긴 테이블 기록에있어서 동일의 존재 장쇄 MD5 여부를 확인하기 위해. 그래서 우리는 아래 표를 설계
CREATE TABLE `short_url_map` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '短链 id',
`lurl` varchar(10) DEFAULT NULL COMMENT '长链',
`md5` char(32) DEFAULT NULL COMMENT '长链md5',
`gmt_create` int(11) DEFAULT NULL COMMENT '创建时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
复制代码물론, 경우 많은 양의 데이터, 파티션 또는 포인트 테이블의 하위 라이브러리에 다음 후자의 의지가 필요합니다.
높은 동시성 아키텍처 설계의 짧은 체인 요청
전기 공급 회사에서 자주, 활동, 스파이크의 여지가 높은 빨간색 봉투 등을 잡아하면이 고성능 Nginx에 루아 웹을 기반으로, 시점은,이 상황의 관점에서, 우리가 openResty를 도입합니다 QPS openResty는 또한 통합하고 이러한 레디 스 캐시 모듈 캐싱 메커니즘을 제공하면서 플랫폼 인해 비 차단 IO 모델에 Nginx에 사용 openResty 쉽게 동시의 + 숫자 승 (100)를 지원할 수, 정상적인 상황에서 당신은 단지를 배포 할 수 있습니다, 그것은 직접 MySQL의에 연결할 수 있습니다. 비즈니스 계층 이러한 미들웨어를 연결할 필요가 없습니다 성능이 자연스럽게 많이 높을 것이다
도시 된 바와 같이, 서비스 계층 openResty의 사용이 공정은 직접 상기 버퍼 층과베이스 층을 생략하고, 또한 성능이 많이 향상된다.
개요
이 문서는 당신에게 몇 가지 짧은 체인 디자인 아이디어를 제공하도록 설계 짧은 체인 디자인 디테일을 만들어 분석, 텍스트가 블룸 필터, openRestry 기술처럼 많이 포함, 대화를 시작하지 않은 종이, 내가 다시 볼 수 있다는 제안 에 면밀한 관찰을 다시 가져 가라. 본문에서 언급 한 또 다른 예를 들어 MySQL의 페이지 분할도 기본 운영 체제 및 페이지에 인수 다른 지식보다 자세한 이해를 가지고에 의해 사용되는 B + 트리 데이터 구조를 요구한다, 우리가 각 지식 점은 많은 것을 배웠 정확히 무엇인지 찾을 생각합니다.
거인의 어깨
www.cnblogs.com/rjzheng/p/1...
time.geekbang.org/column/arti...
공공 우려의 코드 번호를 청소에 오신 것을 환영합니다, 탐험