시스템 설계 시리즈에서 짧은 체인 서비스를 설계하는 방법

쇼트 체인 서비스의 원조는 TinyURL으로 , 쇼트 체인 서비스를 제공하는 최초의 웹 사이트입니다. 현재 중국에는 Sina (t.cn), Baidu (dwz.cn), Tencent 등 많은 쇼트 체인 서비스가 있습니다. (url.cn) 등.

왜 짧은 사슬을 사용합니까? 이 질문의 또 다른 의미는 짧은 체인 서비스가 존재해야한다는 것입니다.

대박 대답을 의역하기 위해 : 존재는 합리적입니다.

짧은 체인 서비스 존재의 합리성

먼저 짧은 체인 서비스 존재의 합리성에 대해 이야기하겠습니다.

짧은 사슬의 유일한 장점은 짧다 는 것입니다 .

Weibo의 초기 사용자는 각 Weibo가 140 자로 제한 될 수 있음을 알고 있습니다. 링크를 공유하려면 설명 텍스트를 줄여야합니다.

마찬가지로 마케팅 메시지에 링크를 넣으려면 비용을 고려해야합니다. 초기 휴대 전화 인 경우 사용자가 3 개의 연결이 끊긴 짧은 메시지를 수신 할 수 있으며 이는 짧은 메시지의 도달 및 클릭에 심각한 영향을 미칠 수 있음을 고려해야합니다.

이 경우 링크가 충분히 짧으면 다른 콘텐츠가 더 풍부해질 수 있습니다. 그러나 당사는 비즈니스에 따라 길이가 다른 링크를 정의 할 수 있으며 다른 요구 (예 : 통계적 마케팅 데이터)를 충족하기 위해 일반 링크에 매개 변수를 추가합니다. 따라서 짧은 링크가 탄생했습니다. 리디렉션을 통해 짧은 링크를 사용하여 다른 링크를 대체 할 수 있습니다 . 예를 들어 http://t.cn/A6ULvJho 와 같은 20 자 링크를 통해 리디렉션 할 수 있습니다. 146 자 길이 https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html?spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989 .

위의 두 가지 예는 숏 체인의 가치를 증명하며, 몇 가지 숏 체인의 추가 사용을 요약합니다.

마케팅 문자 메시지를 보내면 더 많은 비용을 절약 할 수 있습니다. 링크가 짧아지고 문자 메시지 길이가 작아지며 지불해야하는 문자 메시지 비용이 줄어 듭니다. 예를 들어 위의 짧은 링크는 20 자이고 원래 링크는 146 자 차이는 모두 돈입니다.
2 차원 코드로 변환하면 더 쉽게 알아볼 수 있습니다. 예를 들어 아래의 2 차원 코드 그림은 내용 수가 다르고 셀의 밀도도 다르기 때문에 같은 크기입니다.
짧은 링크 점프의 원래 링크가 리디렉션 되었기 때문에 유연하고 구성 가능합니다. 특정 시간에 원래 링크에 문제가 있거나 다른 위치로 점프해야하는 경우 리디렉션 된 항목을 수정할 수 있습니다. 대상 주소. 이는 오프라인 자재 전달에 매우 유용합니다. 예를 들어, 이미 2 차원 코드 자료를 배치 한 경우. 이때 다른 웹 사이트 나 활동으로 이동하려는 경우를 발견했습니다. 대상 주소 만 수정하면됩니다. 배치 된 모든 재료를 대체하는 대신 짧은 체인.

짧은 사슬의 원리

실제로 앞에서 언급했듯이 짧은 링크는 서버를 원래 링크로 리디렉션하여 실현됩니다. Sina Weibo의 짧은 체인을 curl -i http://t.cn/A6ULvJho살펴보면 콘솔이 명령을 실행 하고 결과는 다음과 같습니다.

HTTP/1.1 302 Found
Date: Thu, 30 Jul 2020 13:59:13 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 328
Connection: keep-alive
Set-Cookie: aliyungf_tc=AQAAAJuaDFpOdQYARlNadFi502DO2kaj; Path=/; HttpOnly
Server: nginx
Location: https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html??spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989

<HTML>
<HEAD>
<TITLE>Moved Temporarily</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Moved Temporarily</H1>
The document has moved <A HREF="https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html??spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989">here</A>.
</BODY>
</HTML>

위의 정보에서 알 수 있듯이 Sina는 302 점프를 수행했으며 호환성을 위해 수동 조정을 위해 HTML 콘텐츠도 반환했습니다. 전체 대화식 프로세스는 다음과 같습니다.

짧은 체인 점프 프로세스

짧은 체인 생성 방법

에 따르면 페이지 수 통계 정보, 현재 세계에서 5800 만 웹 페이지, 최대 2 ^ 32 = 4294967296 <43 억 <58 억의 자바 int 값, 길이 값은 2 ^ 64> 58 억이다. 따라서 숫자를 사용하는 경우 int는 거의 지원할 수 없습니다 (결국 모든 URL이 short-chain 서비스를 호출하여 short-chain을 생성하는 것은 아닙니다). long을 사용하는 것이 더 안전하지만 공간을 낭비하게됩니다. 특정 유형이 사용됩니다. 사업에 따라 판단해야합니다.

Sina Weibo는 8 비트 문자열을 사용하여 원래 링크를 나타냅니다.이 문자열은 62 ^ 8 = 3521614606208> 3,521 억> 58 억 숫자의 62 16 진수 표현으로 이해할 수 있습니다. 즉, 현재 알려진 URL을 해결할 수 있습니다. 세상에. 기본 62는 10 개의 숫자 + (az) 26 개의 소문자 + (AZ) 26 개의 대문자로 구성된 숫자입니다.

생성 방법 1 : 해시

원래 링크의 해시 값을 취하는 것은 비교적 간단한 사고 방식입니다. 구현할 수있는 기성 알고리즘이 많이 있지만 피할 수없는 문제가 있습니다. 해시 충돌이므로 충돌 률이 낮은 알고리즘을 선택하는 것이 더 중요합니다.

MurmurHash 알고리즘을 권장합니다 .이 알고리즘은 암호화되지 않은 해시 함수로 일반적인 해시 검색 작업에 적합합니다. 현재 Redis, Memcached, Cassandra, HBase, Lucene이 모두이 알고리즘을 사용하고 있습니다.

Guava에서 MurmurHash의 도움으로 :

final String url = "https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html?spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989";
final HashFunction hf = Hashing.murmur3_128();
final HashCode hashCode = hf.newHasher().putString(url, Charsets.UTF_8).hash();
final int hashCodeAsInt = hashCode.asInt();// 这里选择返回 int 值，也可以选择返回 long 值
System.out.println(hashCodeAsInt);// 输出的结果是：1810437348，转换成 62 进制是：1Ywpso

충돌 문제의 경우 가장 간단한 생각은 충돌이 발생하면 충돌이 방지 될 때까지 원래 URL에 특수 문자열을 첨부하는 것입니다. 구체적인 작업은 다음과 같습니다.

해시 + 블룸

생성 방법 2 : 통합 번호 발급자

이것이 무엇이든 상관없이 중앙 집중식 통합 발급자를 통해 ID를 할당합니다.이 ID는 짧은 체인의 콘텐츠입니다. 예를 들어 첫 번째 ID는 https://tinyurl.com/1이고 두 번째 ID는 https입니다. : //tinyurl.com/2 등. 물론 일부 분산 ID 알고리즘은 매우 긴 일련 번호를 가질 수 있습니다. 더 짧은 회로를 얻기 위해 62베이스 문자열로 변환 할 수도 있습니다.

Redis 자체 증가 : Redis는 성능이 우수하고 단일 머신이 10W 이상의 요청을 지원할 수 있습니다. 발행자로 사용되는 경우 Redis 지속성 및 재해 복구를 고려해야합니다.
MySQL 자체 증가 기본 키 :이 체계는 Redis 체계와 유사하며, 데이터베이스 자체 증가 기본 키의 알림을 사용하여 ID가 반복되지 않고 지속적으로 자동 생성되도록합니다.
Snowflake : 현재 널리 사용되고있는 ID 시퀀스 생성 알고리즘으로 Meituan 's Leaf는이 알고리즘을위한 캡슐화 및 업그레이드 서비스입니다. 그러나이 알고리즘은 서버 시계에 의존합니다. 시계가 돌아 가면 ID 충돌이있을 수 있습니다. (어떤 사람들은 밀리 초 단위의 시퀀스 값이이 알고리즘의 병목 현상이라고 생각할 것입니다. 그렇긴해도이 알고리즘은 아이디어를 제공 할뿐입니다. 시퀀스 길이가 충분하지 않다고 생각되면 직접 추가하십시오. 초당 서비스가 정말 나쁩니다. 그 정도입니까?)
등등. . .

후속 조치에서 통합 번호 발급 사를 소개하는 별도의 기사가있을 예정입니다. 그 후 여기에서 수정하고 링크를 첨부하거나 저 (WeChat ID : Watching the Mountain Lodge)를 팔로우하여 직접 정보를 얻을 수 있습니다. .

통합 발행자의 경우 해결해야 할 또 다른 질문은 동일한 원본 링크가 동일한 짧은 체인을 반환해야합니까 아니면 다른 짧은 체인을 반환해야 하는가입니다.

대답은 동일한 원본 링크가 사용자 및 위치와 같은 차원에 따라 다른 짧은 링크를 반환한다는 것입니다. 치수가 모두 같다고 판단되면 동일한 짧은 체인을 반환합니다. 이것의 장점은 짧은 체인 클릭과 요청 정보를 기반으로 통계를 만들 수 있다는 것입니다. 짧은 체인의 경우 우리가 희생하는 것은 일부 저장 및 계산 일 뿐이지 만 수집 된 정보는 매우 중요합니다.

저장 짧은 사슬

일반적으로 데이터 저장소에는 관계형 데이터베이스 또는 NoSQL 데이터베이스의 두 가지 유형이 있습니다. 위의 생성 논리에서 스토리지는 당연한 문제입니다. MySQL에 저장된 테이블 작성 문은 다음과 같습니다.

CREATE TABLE IF NOT EXISTS tiny_url
(
    sid                INT AUTO_INCREMENT PRIMARY KEY,
    create_time        DATETIME  DEFAULT CURRENT_TIMESTAMP NULL,
    update_time        TIMESTAMP DEFAULT CURRENT_TIMESTAMP NULL ON UPDATE CURRENT_TIMESTAMP,
    version            INT       DEFAULT 0                 NULL COMMENT '版本号',
    tiny_url           VARCHAR(10)                         NULL COMMENT '短链',
    original_url       TEXT                                NOT NULL COMMENT '原始链接',
    # 其他附加信息
    creator_ip         INT       DEFAULT 0                 NOT NULL,
    creator_user_agent TEXT                                NOT NULL,
    # 用户其他信息，用于后续统计，对于这些数据，只要存储影响创建短链的必要字段就行，其他的都可以直接发送到数据服务中
    instance_id        INT       DEFAULT 0                 NOT NULL,
    # 创建短链服务实例ID
    state              TINYINT   DEFAULT 1                 NULL COMMENT '-1无效 1有效'
);

장황한 문장에서 스토리지는 데이터 수준을 고려하고 테이블과 데이터베이스로 나눌 필요가 있는지 미리 계획해야합니다.

짧은 체인 요청

저장이 완료되면 다음에 사용할 차례입니다.

일반적인 방법은 요청 된 짧은 체인 문자열을 기반으로 스토리지에서 데이터를 찾은 다음 HTTP 리디렉션을 원래 주소로 반환하는 것입니다. 저장을 위해 관계형 데이터베이스를 사용하는 경우 일반적으로 짧은 체인 필드에 대한 인덱스를 생성해야하며 데이터베이스가 병목 상태가되는 것을 방지하기 위해 데이터베이스는 캐싱을 통해 전면에있는 길을 닦을 것입니다. 또한 캐시의 합리적 사용을 향상시키기 위해 일반적으로 LRU 알고리즘을 통해 비핫 쇼트 체인 데이터를 제거합니다. 과정은 다음과 같습니다.

짧은 체인 요청

그림의 블룸 필터는 캐시 고장을 방지하고 과도한 서버 압력을 유발하는 것입니다.

여기에 또 다른 질문이 있습니다. HTTP가 리디렉션 코드를 반환 할 때 301 또는 302를 사용하는 경우 Sina Weibo가 더 의미있는 301 리디렉션 대신 302를 반환하는 이유는 무엇입니까? (HTTP 상태 코드에 대해 잘 모르는 학생의 경우 "HTTP 상태 코드 요약" 에서 자세한 정보 를 얻을 수 있습니다. )

301은 영구 리디렉션을 나타냅니다. 즉, 브라우저가 첫 번째 요청에 대한 리디렉션 주소를 얻은 후 모든 후속 요청은 브라우저 캐시에서 리디렉션 주소를 직접 가져오고 짧은 체인 서비스를 다시 요청하지 않습니다. 이렇게하면 서비스 요청 수를 효과적으로 줄이고 서버 부하를 줄일 수 있지만 후속 브라우저가 더 이상 백엔드에 요청을 보내지 않기 때문에 실제 클릭 수를 얻을 수 없습니다.
302, 임시 리디렉션을 나타냅니다. 즉, 브라우저가 새 주소를 얻기 위해 서버에 요청을 시작할 때마다 서버에 대한 압력이 증가하지만 오늘날 과도한 하드웨어로 인해 이러한 압력은 데이터에 비해 언급 할 가치가 없습니다. 따라서 302 리디렉션은 짧은 체인 서비스의 첫 번째 선택입니다.

요약하자면

숏 체인 서비스는 실제로 상대적으로 단순하고 비즈니스 로직이 많지 않은데 주로 분산 시스템의 공통 설계에 대한 이해를 검토하고 인터뷰 과정에서 자주 사용되는 질문이기도합니다. 여기에 몇 가지 디자인 아이디어를 제공하기위한 것입니다. 기사에 포함 된 발행자 (분산 ID), Bloom 필터, MurmurHash 등은 각각을 설명하기 위해 몇 마디로되어 있지 않기 때문에 너무 심층적이지 않습니다. 그리고 스스로 해결해야합니다.

개인 홈페이지 : https://www.howardliu.cn
개인 블로그 게시물 : 시스템 디자인 시리즈
CSDN 에서 짧은 체인 서비스를 디자인하는 방법 홈페이지 : http://blog.csdn.net/liuxinghao
CSDN 블로그 게시물 : 디자인 방법 시스템 설계 시리즈 의 짧은 체인 서비스 체인 서비스

공개 번호 : 산장 감상