이 기사는 Bilibili의 수석 개발 엔지니어인 Huang Shancheng이 공유했습니다. 원래 제목은 "10만 개의 장기 메시지 시스템"이었습니다.
1. 소개
오늘날의 디지털 엔터테인먼트 시대에 사격은 라이브 방송 플랫폼에서 없어서는 안 될 상호작용 요소 중 하나가 되었습니다.

사용자는 사격, 선물 보내기 등을 통해 자신의 생각, 의견 및 대화형 콘텐츠를 실시간 방송 화면에 표시하여 사용자 시청 경험을 풍부하게 할 수 있습니다. 이 과정에서 대화형 정보를 실시간으로 터미널에 푸시하려면 긴 연결을 사용해야 합니다.
이름에서 알 수 있듯이 긴 연결은 애플리케이션 수명 동안 서버와 유지되는 네트워크 데이터 채널이며 전이중 업링크 및 다운링크 데이터 전송을 지원할 수 있습니다. 요청 응답 모드의 단거리 연결 서비스와 가장 큰 차이점은 실시간으로 사용자에게 적극적으로 데이터를 푸시하는 기능을 서버에 제공할 수 있다는 점입니다.
이 기사에서는 Bilibili가 golang을 기반으로 구현한 수천만 개의 장거리 연결 실시간 메시징 시스템의 아키텍처 설계 및 사례를 소개합니다. 여기에는 장거리 연결 서비스의 프레임워크 설계와 안정성 및 높은 관련 최적화가 포함됩니다. 처리량.


2. 관련 기사
- " Bilibili의 마이크로서비스 기반 API 게이트웨이의 0에서 1로의 진화 "
- " Graphite Document Standalone 500,000 WebSocket 긴 연결 아키텍처 실습 "
- " 0에서 1까지 Baidu 통합 소켓 긴 연결 구성 요소의 기술 실습 "
- " Tantan의 IM 긴 연결 기술 실습: 기술 선택, 아키텍처 설계 및 성능 최적화 "
- " iQiyi WebSocket 실시간 푸시 게이트웨이 기술 실습 "
- " LinkedIn의 웹 측 인스턴트 메시징 사례: 단일 시스템에서 수십만 개의 긴 연결 달성 "
- " 긴 연결을 기반으로 한 안전하고 확장 가능한 구독/푸시 서비스 구현 아이디어 "
- " 2,500만 개의 긴 연결을 갖춘 Meizu의 실시간 메시지 푸시 아키텍처의 기술 사례 공유 "
- " Meizu Architect와의 독점 인터뷰: 대규모 장거리 연결을 통한 실시간 메시지 푸시 시스템 경험 "
3. 건축설계
3.1 개요
장거리 연결 서비스는 여러 비즈니스 당사자가 공유하는 장거리 연결입니다.
왜냐하면 설계 시 장기 연결 서비스에 대한 다양한 비즈니스 당사자의 요구와 다양한 비즈니스 시나리오를 고려해야 하는 동시에 비즈니스에 개입하지 않도록 장기 연결 서비스의 경계도 고려해야 하기 때문입니다. 논리 및 장기 연결 서비스의 후속 반복 및 개발에 영향을 미칩니다.
장거리 연결 서비스는 주로 세 가지 측면으로 나뉩니다.
- 1) 긴 연결의 설정, 유지 및 관리
- 2) 다운링크 데이터 푸시;
- 3) 업링크 데이터 전달(현재는 하트비트만 있고 실제 비즈니스 시나리오 요구 사항은 없음)
3.2 전체 아키텍처

긴 연결 서비스의 전체 구조는 위 그림과 같습니다. 전체 서비스에는 다음과 같은 부분이 포함됩니다.
1) 제어 계층: 주로 접속 합법성 확인, 신원 확인 및 라우팅 제어를 위한 연결 설정을 위한 사전 호출입니다.
주요 임무:
- 1) 이용자 본인 인증
- 2) 조립 데이터를 암호화하고 합법적인 토큰을 생성합니다.
- 3) 액세스 노드의 동적 스케줄링 및 할당.
2) 액세스 계층: 장기 연결의 핵심 서비스로 주로 인증서 제거, 프로토콜 도킹 및 장기 연결 유지 관리를 담당합니다.
주요 임무:
- 1) 인증서 및 프로토콜을 제거합니다.
- 2) 클라이언트와의 연결을 설정 및 유지하고 연결 ID와 roomid 간의 매핑 관계를 관리하는 역할을 담당합니다.
- 3) 업링크 및 다운링크 메시지를 처리합니다.
3) 로직 레이어: 주로 장기적인 연결 비즈니스 기능을 위해 단순화된 액세스 레이어입니다.
주요 임무:
- 1) 온라인 번호 신고 기록
- 2) 연결 ID의 각 속성과 각 노드 간의 매핑 관계를 기록합니다.
- 4) 메시지 배포 계층: 메시지가 액세스 계층으로 푸시됩니다.
주요 임무:
- 1) 메시지 캡슐화, 압축 및 집계가 해당 에지 노드로 푸시됩니다.
5) 서비스 계층: 다운스트림 메시지 푸시를 위한 입구를 제공하는 비즈니스 서비스 도킹 계층입니다.
주요 임무:
- 1) 비즈니스 푸시 권한을 관리하고 제어합니다.
- 2) 메시지 감지 및 재조립;
- 3) 자체 시스템 보호를 위해 특정 정책에 따라 메시지 흐름을 제한합니다.
3.3 핵심 프로세스

긴 연결은 주로 세 가지 핵심 프로세스로 구성됩니다.
- 1) 연결 설정 : 클라이언트가 먼저 시작하여 제어 계층을 통해 장치의 합법적인 토큰과 액세스 포인트 구성을 얻습니다.
- 2) 연결 유지 : 주로 클라이언트는 긴 연결이 활성화되어 있는지 확인하기 위해 정기적으로 하트비트를 시작합니다.
- 3) 다운링크 푸시 : 다운링크 푸시는 비즈니스 서버에 의해 시작됩니다. 서비스 계층은 관련 식별자에 따라 연결 식별자와 액세스 노드를 결정하고 메시지 배포 계층을 통해 해당 액세스 계층으로 푸시가 전송됩니다. 연결한 후 클라이언트에 배포합니다.
3.4 기능 목록
스테이션 B의 비즈니스 시나리오와 결합하여 다운링크 데이터 푸시는 다음과 같은 일반 기능을 제공합니다.
- 1) 사용자 수준 메시지: 특정 사용자에게 푸시되도록 지정됩니다(예: 특정 앵커에 초대 pk 메시지 보내기).
- 2) 장치 수준 메시지: 특정 장치를 개발하고 푸시합니다(예: 기록되지 않은 장치에 대한 클라이언트 로그 보고 지침 푸시).
- 3) 방 수준 메시지: 특정 방의 연결에 대한 푸시 메시지(예: 생방송 방의 모든 온라인 사용자에게 사격 메시지 푸시)
- 4) 파티션 메시지: 특정 파티션의 방에 메시지를 푸시합니다(예: 특정 파티션에서 방송되는 모든 방에 특정 수익 활동을 푸시).
- 5) 지역 전체 뉴스: 모든 플랫폼 사용자에게 푸시 메시지를 보냅니다(예: 모든 온라인 사용자에게 푸시 이벤트 알림).
4. 높은 처리량 기술 설계
비즈니스가 발전하고 확장됨에 따라 온라인 사용자가 점점 많아지고 있으며, 특히 S-Games 기간 동안 인기 이벤트의 라이브 방송의 경우 장기적인 연결 시스템에 대한 압박이 커지고 있습니다. 전체 플랫폼의 메시지 처리량은 수천만 개에 이르렀고 Changlian 시스템의 메시지 배포 평균 지연은 약 1초이며 메시지 도착률은 99%에 달합니다. Changlian이 취한 조치.
4.1 네트워크 프로토콜
올바른 네트워크 프로토콜을 선택하는 것은 장거리 연결 시스템의 성능에 매우 중요합니다.
- 1) TCP 프로토콜 : 안정적인 연결과 데이터 전송을 제공할 수 있으며 높은 데이터 신뢰성이 요구되는 시나리오에 적합합니다.
- 2) UDP 프로토콜 : 신뢰할 수 없는 프로토콜이지만 전송 효율이 높으며 높은 데이터 신뢰성이 요구되지 않는 시나리오에 적합합니다.
- 3) WebSocket 프로토콜 : 너무 많은 오버헤드를 추가하지 않고 양방향 통신을 구현하며 웹 측에서 더 많이 사용됩니다.
액세스 계층은 프로토콜 모듈과 연결 모듈로 분할됩니다.
- 1) 프로토콜 모듈 : 특정 통신 계층 프로토콜과 상호 작용하고 다양한 통신 프로토콜의 인터페이스와 논리적 차이점을 캡슐화합니다.
- 2) 연결 모듈 : 장기 연결 비즈니스 연결 상태를 유지하고, 업링크, 다운링크 및 기타 비즈니스 로직 요청을 지원하고, 연결 속성 및 룸 ID와의 바인딩 관계를 유지합니다.
위의 1) 항목 과 관련하여 프로토콜 모듈은 연결 설정, 데이터 읽기, 쓰기 등을 포함하여 연결 모듈에 통합 데이터 인터페이스를 제공합니다. 향후 새로운 프로토콜이 추가되더라도 프로토콜 모듈에서 조정이 완료되는 한 다른 모듈의 장기적인 비즈니스 로직에는 영향을 미치지 않습니다.
의 장점:
- 1) 비즈니스 로직과 통신 프로토콜은 통신 프로토콜의 반복 추가를 용이하게 하고 다중 통신 프로토콜과의 호환성 구현 어려움을 단순화하기 위해 격리됩니다.
- 2) 제어 계층은 클라이언트의 실제 상황을 기반으로 더 나은 통신 프로토콜을 발행할 수 있습니다.
4.2 로드 밸런싱
로드 밸런싱 기술을 사용하면 처리를 위해 요청을 여러 서버 노드에 분산하여 단일 노드의 과도한 로드를 방지하고 시스템의 확장성과 안정성을 향상시킬 수 있습니다.
장기 연결은 로드 밸런싱을 위한 제어 계층을 추가합니다. 제어 계층은 http 짧은 연결 인터페이스를 제공하고 클라이언트와 각 에지 노드의 실제 상황 및 근접 원칙을 기반으로 적절한 액세스 노드를 동적으로 선택합니다.
액세스 계층은 수평 확장을 지원하고 제어 계층은 할당 노드를 실시간으로 추가 및 축소할 수 있습니다. S 게임에서는 온라인 인원이 수천만 명에 육박했을 때 각 노드의 CPU와 메모리가 안정적인 범위 내에 있도록 각 액세스 노드의 균형을 맞추고 예약했습니다.
4.3 메시지 큐
메시지 푸시 링크는 다음과 같습니다. 비즈니스가 푸시를 보내고 서비스 계층을 통해 에지 노드에 푸시한 다음 클라이언트에 전달합니다.
서비스 계층은 실시간으로 각 에지 노드에 배포됩니다. 룸 유형의 메시지인 경우 여러 에지 노드에 푸시해야 합니다. 서비스 계층에서는 비즈니스 로직도 처리하므로 메시지 처리량에 큰 영향을 미칩니다.
따라서 메시지 큐와 메시지 배포 계층이 추가됩니다. 메시지 배포 계층은 각 엣지 노드의 정보를 유지하고 메시지를 푸시하므로 시스템의 동시 처리 기능과 안정성이 향상되고 메시지 푸시 차단으로 인한 성능 문제가 방지됩니다.
4.4 메시지 집계
인기 있는 이벤트가 발생하면 동시에 온라인에 접속하는 사람의 수가 수천만 명에 달할 수 있으며, 온라인의 모든 사람이 1초에 하나의 메시지를 보내면 엄청난 양의 메시지가 수천만 대의 단말기에 전파됩니다. 전송해야 하는 메시지 양은 1kw*1kw로 매우 많은 양입니다. 이때 메시지 배포 계층과 액세스 계층은 큰 압박을 받게 됩니다.
분석 결과 이들 메시지는 모두 같은 방에서 나온 것으로 S게임방 등 핫룸에 속해 있어 시청자 수를 줄일 수 없어 메시지 수에 대해 호들갑을 떨 수밖에 없는 것으로 드러났다. 비즈니스 메시지 푸시(Push)는 줄일 수 없고, 분산된 메시지 수를 줄여야 하므로 메시지 집계(Aggregation)를 고려했습니다.
회의실 메시지의 경우 메시지 집계는 특정 규칙에 따라 수행되고 일괄적으로 푸시됩니다.

메시지 집계가 온라인 상태가 된 후에는 메시지 배포 계층에서 액세스 계층으로 호출되는 QPS가 약 60% 감소하여 액세스 계층과 메시지 배포 계층에 대한 부담이 크게 줄어듭니다.
4.5 압축 알고리즘
메시지 집계 후 메시지 수는 줄어들지만 메시지 본문 크기가 늘어나 쓰기 IO에 영향을 미치므로 메시지 본문 크기를 줄여야 하는 경우 메시지 압축을 고려합니다.
압축 알고리즘의 경우 비교를 위해 시장에서 일반적으로 사용되는 두 가지 zlib 및 brotli를 선택했습니다.
우리는 온라인 비즈니스에서 푸시한 데이터를 캡처하고 가장 높은 압축 수준을 선택하고 압축 검증을 통과했습니다.

brotli는 zlib에 비해 큰 이점을 갖고 있으며 최종적으로 brotli 압축 알고리즘이 선택되었음을 알 수 있습니다 .
각 액세스 노드에서 반복되는 압축과 성능 낭비를 방지하려면 메시지 배포 계층에서 메시지 압축을 수행하도록 선택합니다. 온라인에 접속한 후에는 처리량이 향상될 뿐만 아니라 광대역 사용 비용도 절감됩니다.
5. 서비스 보장 기술 설계
오늘날 일부 기업에서는 장기 푸시 메시지에 크게 의존하고 있습니다. 메시지 손실은 기껏해야 사용자 경험에 영향을 미치고 최악의 경우 후속 비즈니스 프로세스를 차단하여 비즈니스 흐름에 영향을 미칩니다. 장기적인 서비스 메시지 보장을 위해 다음과 같은 작업이 이루어졌습니다.
5.1 다중 활성 배포
다중 활성 배포는 동일한 시스템 아키텍처와 서비스를 서로 다른 지리적 위치에 배포함으로써 단일 지리적 오류가 발생할 경우 시스템의 신속한 장애 조치를 달성하여 시스템의 안정성과 가용성을 향상시킵니다.

장기 서비스 배포에는 주로 다음 사항이 포함됩니다.
- 1) LongConnect는 중국 동부, 중국 남부 및 중국 북부에 액세스 포인트를 배포했으며, 3개 주요 사업자를 지원하기 위해 액세스 포인트도 중국 남부와 중국 중부의 자체 구축 컴퓨터실에 배포하여 해외 사용자, 독립적인 액세스를 지원했습니다. 싱가포르 컴퓨터실에 포인트가 추가되었습니다.
- 2) 다양한 비즈니스 시나리오의 경우 클라우드 노드와 자체 구축된 노드 간에 실시간 전환이 가능합니다. 클라우드 노드와 자체 구축된 전산실의 비용이 다르기 때문에 서비스 품질을 보장하면서 비용을 최대한 통제해야 합니다.
현재 온라인 작업 중에 단일 노드나 컴퓨터실의 네트워크 지터가 가끔 발생합니다. 제어 계층을 통해 문제가 있는 노드를 몇 초 안에 제거하므로 비즈니스에 미치는 영향이 크게 줄어듭니다.
5.2 하이 및 로우 메시지 채널
다중 서비스 메시지는 긴 연결에 액세스하지만 사격 메시지 및 초대 pk 메시지와 같은 다양한 메시지의 중요성이 다릅니다. 몇 개의 사격 메시지가 손실되면 사용자 경험에 큰 영향을 미치지 않지만 초대 pk 메시지가 손실되는 경우 , 이로 인해 pk 비즈니스가 후속 프로세스를 진행할 수 없게 됩니다.
다양한 수준의 메시지에는 고품질 메시지 채널이 사용됩니다. 중요한 뉴스는 고품질 채널에, 일반 뉴스는 저품질 채널에 갑니다. 이런 방식으로 중요 메시지와 일반 메시지를 물리적으로 분리하고, 메시지 배포는 중요한 메시지를 우선적으로 처리합니다.

고품질 채널의 경우 이중 전달이 보장되고 액세스 계층에서 멱등성 중복 제거가 수행됩니다. 우선, 중요한 메시지는 사용자 수준을 위한 것이고, 그 양이 그다지 크지 않을 것이기 때문에 액세스 레이어에 대한 부담이 크게 커지지는 않을 것입니다. 또한 이중 전달 작업은 여러 컴퓨터실에 배포되어 단일 컴퓨터실에서 네트워크 지터의 영향을 줄입니다.
고품질 및 저품질 채널이 온라인화된 후 인트라넷 아웃바운드 불안이 발생했습니다. 당시 인트라넷에 연결된 작업 노드는 메시지를 비정상적으로 푸시했지만 클라우드의 고품질 작업 노드는 메시지를 정상적으로 푸시할 수 있었습니다. 고품질 메시지 도착을 보장하여 고품질 서비스가 영향을 받지 않도록 보장합니다.
5.3 건담 기능
높음-낮음 최적화 채널은 작업에서 액세스 계층으로의 링크를 해결하지만 메시지 푸시 연결에는 서비스 계층에서 작업으로, 액세스 계층에서 클라이언트로의 링크와 같은 여러 링크가 포함됩니다.
전체 링크에 대해 도달 기능이라고 하는 필수 도달 메커니즘을 구현하여 단말의 도착률을 보장합니다.

기능 구현:
- 1) 각 메시지에는 msgID가 포함되며, 클라이언트는 메시지를 받은 후 멱등성 중복 제거 및 수신 확인을 수행합니다.
- 2) 서버는 msgid에 대해 ack 감지를 수행하고, ack가 없는 경우 유효기간 내에 전달을 재시도합니다.
최종 도착률 = (1-(1-r)^(n+1)), 여기서 r은 브로드캐스트의 단일 도착률이고 n은 최대 재시도 횟수입니다.
예: r = 97%, n=2이면 최종 도착률은 (1-(1-0.97)^(2+1)) = 99.9973%에 도달할 수 있습니다.
6. "방"에 들어오고 나가는 메시지에 대한 전달 보장 설계
일부 비즈니스 시나리오에서는 사용자 입장 및 퇴장 정보를 사용해야 합니다. 예를 들어, 사용자 A가 라이브 방송 방에 입장하면 페이지에 사용자 A가 방에 입장하거나 온라인 목록에 참여하도록 환영하는 메시지가 표시됩니다.
1) 객실 입장 정보가 손실되므로 보상 메커니즘이 필요합니다. 방 입장 메시지는 하트비트로 연결하면 보상될 수 있을 거라 생각했는데, 하트비트가 계속 연결되는 온라인 기간 동안 업체에서는 방 입장 메시지를 한 번만 받기를 바라기 때문에 방 입장 메시지에는 멱등성이 있어야 합니다. 기구.
2) 객실 체크아웃 정보도 손실됩니다. 이 경우 회사는 온라인 목록에서 사용자를 제거할 수 없습니다. 이때 연결을 위한 상태 머신을 추가하고 하트비트를 통해 상태 머신을 유지해야 합니다. 하트비트가 손실되면 연결이 끊어진 것으로 간주되어 사용자가 체크아웃합니다.

7. 미래 계획
통합 장접속 서비스는 여러 차례 반복된 후 기본 기능이 안정되었으며 향후 장접속 서비스는 개선되고 최적화될 예정입니다.
주로 다음 방향에 중점을 둡니다.
- 1) 데이터화 : 장거리 연결 전체 링크 네트워크 품질 데이터 통계 및 고가치 메시지 전체 링크 추적을 수집하는 능력을 더욱 향상시킵니다.
- 2) 지능화 : 기기 내 연결 설정, 액세스 포인트 선택 등을 실제 환경에 따라 자동으로 조정할 수 있습니다.
- 3) 성능 최적화 : 액세스 계층의 연결 모듈에서는 업링크 및 다운링크 메시지를 처리하는 Ctrip이 공유되어 액세스 계층의 Ctrip 수를 줄이고 단일 시스템 성능과 연결 수를 더욱 향상시킵니다.
- 4) 기능 확장 : 오프라인 메시지 기능 추가 등
8. 참고자료
[1] TCP를 기반으로 긴 소켓 연결을 작성하는 방법을 단계별로 가르칩니다.
[2] IM 긴 연결, 하트비트 및 재연결 메커니즘을 올바르게 이해하고 직접 구현합니다.
[3] 10,000 단어의 긴 기사: 효율적인 IM 긴 연결 적응형 하트비트 연결 유지 메커니즘을 구현하는 방법을 단계별로 설명합니다.
[4] JWT 기술을 사용하여 IM 시스템 소켓 긴 연결의 신원 인증 문제점을 해결합니다.
[5] TCP/IP 상세 설명 - 11장·UDP: 사용자 데이터그램 프로토콜
[6] TCP/IP 상세 설명 - 17장·TCP: 전송 제어 프로토콜
[7] WebSocket 초보자부터 숙련자까지 30분이면 충분합니다!
[8] TCP 프로토콜을 빠르게 이해하려면 기사 하나면 충분합니다.
[10] 단 한 번의 소변으로 TCP와 UDP의 차이점을 빠르게 이해할 수 있습니다.
[11] 소켓이란 정확히 무엇입니까? 글 하나로 이해해보세요!
[12] 소켓을 읽고 쓸 때 정확히 무엇을 읽고 쓰는 걸까요?
[13] TCP 프로토콜을 설계한다면 무엇을 하시겠습니까?
[14] 한 기사에서 운영 체제에 대해 자세히 알아보고 소켓이 무엇인지 이해하세요.
[15] 고성능 서버가 어떻게 구현되는지 이해하기 쉽습니다.
[16] 12306 티켓 잡기가 가져온 깨달음: Go를 사용하여 백만 QPS 플래시 판매 시스템을 구현하는 방법 보기(소스 코드 포함)
- 모바일 IM 개발에 대한 소개 기사: " 초보자를 위한 기사 하나면 충분합니다: 처음부터 모바일 IM 개발 "
- 오픈 소스 IM 프레임워크 소스 코드: https://github.com/JackJiang2011/MobileIMSDK ( 대체 주소는 여기를 클릭하세요 )
(이 글은 http://www.52im.net/thread-4647-1-1.html 에 동시에 게재되었습니다 .)