Github 6.7k star 오픈 소스 IM 프로젝트인 OpenIM 성능 및 메시지 신뢰성 테스트를 적극 권장합니다.

요약하자면, 용량 및 성능의 경우:

서버 리소스: 8 코어 16G 메모리, 6 개의 기계식 디스크, 각각 100G, mongo 조각용, 10MB 대역폭.

용량: 사용자 용량이 65438+ 만, 메시지 수 1 억을 초과합니다.

성능 평가: 동시 온라인 사용자 65438+ 만, 초당 900 개의 메시지 전송, 메시지 지연 1 초 (발신자에서 수신자까지).

Sdk 를 시작하여 50 명의 사용자가 온라인 상태에서 메시지 신뢰도가 100% 인 것을 시뮬레이션합니다.

654.38+ 만 개 메시지 전송, 3 개 실패, 다른 메시지는 상대방에 의해 정확하게 수신되어 로컬 db 에 성공적으로 로그인했습니다. 세 개의 실패한 메시지에 대해 수신자가 받지 못했고 시스템 메시지가 일치했습니다.

OpenIM 은 전 위챗 기술 전문가가 만든 오픈 소스 인스턴트 메시징 구성 요소입니다. Open-IM 에는 IM 서버와 클라이언트 SDK 가 포함되어 있으며, 전체 솔루션, 오픈 소스 코드로 모든 것을 제어할 수 있습니다.

OpenIM 은 모든 플랫폼을 지원할 수 있으며 현재 안드로이드, iOS, Flutter, Uni-app, react-native, JSSDK 등을 지원합니다.

OpenIM 은 사내 사무실, 친구, 온라인 고객 서비스 등 프로젝트나 메타우주에도 사용할 수 있습니다.

Github 주소:/#/

단일 컴퓨터의 경우 온라인 사용자의 메시지 전송 프로세스를 시뮬레이션합니다. 온라인 사용자 수와 메시지 수가 일정 수준에 도달하면 시스템의 CPU, 메모리, 디스크 사용량 및 메시지 지연을 시뮬레이션합니다. 사용자 그룹이 일정 수준에 도달한 후 서버 자원에 대한 사전 평가를 결정합니다. 이 테스트는 한계 테스트가 아닙니다. 첫째, 운영 환경은 사용자와 메시지 수에 따라 제한됩니다. 둘째, OpenIM 의 메시지 모델로 인해 메시지는 처음에는 웹 소켓을 통해 Kafka 로 전송됩니다. 이론적으로 전송된 메시지의 쓰기 성능은 둘의 조합이지만 실제 메시지 전송 병목 현상은 실제로 MongoDB 의 임의 읽기 및 쓰기입니다.

서버 리소스: 텐메시지 클라우드 호스트 (홍콩) 1 세트: Linux Ubuntu 18.04.4 시스템, 4 코어 8G 메모리, 단일 기계 하드 드라이브. 5Mb 대역폭.

테스트 조건: 메시지 저장소 MySQL 을 제거합니다 (MySQL 은 백그라운드 관리에만 사용되며 온라인 사용자 서비스에는 영향을 주지 않기 때문). 로그 수준을 4 이하로 조정합니다. Kafka 에는 2 개의 파티션과 2 개의 msg _ transfer 가 있습니다.

테스트 프로세스: 1 클라이언트 (청두, 윈도 PC, 4 코어 16G 메모리) 10000 개 세션 시작, 서버와 긴 웹 소켓 설정 시뮬레이션 2 개의 클라이언트 * * * 2 만 명의 사용자가 동시에 온라인, 메시지 전송, 메시지 스트림의 각 모듈의 처리 능력 관찰, * * * 2 천 5 백만 개의 메시지 통계, 시스템 메모리 및 디스크 리소스 사용 관찰.

Mongodb 데이터 상황

Redis 데이터 상태

디스크 상태

리소스 사용량 분석

(1)redis 는 메모리를 거의 사용하지 않으며, 사용자당 하나의 데이터 (토큰 및 seq 포함) 는 사용자 수에 비례하며 3 만 명의 사용자가 수십 미터 메모리를 사용합니다.

(2)mongodb 에서 캐시를 제거하면 메모리 소비가 적고 문서당 5000 개의 메시지를 저장하며, 사용자 수 및 메시지 수에 비례합니다. 3 만 명의 사용자 2500 만 개의 메시지 인덱스는 950K 에 불과합니다 (mongo 가 캐시 외부에서 메모리를 소비하는 방식을 더 잘 볼 수 있음).

(3) 2 천 5 백만 개의 메시지가 디스크 공간 10G 를 차지합니다.

(4) 초당 150 개의 메시지, CPU 점유량의 50%, 즉 2 코어가 있습니다.

기술 성능 분석

(1) 성능 병목 현상은 MongoDB 쓰기 작업에 있습니다. 메시지 1 이 있습니다. 발신자와 수신자에 따라 두 번 분할해야 합니다. MongoDB 는 두 번 쓰고 나중에 MongoDB 읽기 및 쓰기를 최적화할 수 있습니다.

(2) CPU 소비가 많은 모듈의 경우 향후 전체 최적화를 수행합니다.

(3) 데이터 양이 증가함에 따라 성능이 안정적이며 감소하지 않습니다. 기계 디스크 IOPs 는 200 에 달하며 기본적으로 장비 한계에 도달합니다.

서버 리소스: 8 코어 16G 메모리, 디스크 6 개, 각각 100G, mongo 조각용, 10MB 대역폭.

성능 평가: 동시 온라인 사용자 65438+ 만, 초당 900 개의 메시지 전송, 메시지 지연 1 초 (발신자에서 수신자까지).

(1)mongo 클러스터 배포, 수억 명의 사용자가 동시에 온라인 상태, 수천억 개의 메시지 지원

(2) 클러스터 배치 단순화;

(3) 데이터 백업 및 복구 도구;

위의 주요 테스트 서버는 성능을 테스트하지만 완벽한 IM 솔루션은 단순한 서버 작업이 아닙니다. 클라이언트의 중요성은 의심의 여지가 없습니다. seq 를 사용하여 서버와 메시지를 동기화하는 방법, 메시지 송수신 타이밍을 보장하는 경우 클라이언트 (세션 변경, 추가 및 새 메시지) 를 리콜하는 방법, 로컬 db 및 seq 와 메시지를 동기화하는 방법, 메시지 푸시와 풀링을 결합하여 메시지 송수신의 신뢰성을 보장하는 방법 등이 포함됩니다.

실제로 메시지의 도달 가능성 (신뢰성) 은 성능 테스트보다 더 중요합니다. 따라서 성능 테스트를 하는 동시에 메시지의 도달 가능성 (신뢰성) 도 테스트해야 합니다. 만약 메시지 송수신의 정확성을 보장할 수 없다면, 아무리 높은 성능도 헛수고이다. 이 문서에서는 OpenIM 의 메시지 도달 가능성 테스트의 시나리오, 프로세스 및 결과를 요약합니다. 첫째, OpenIM 의 메시지 접근성은 100% 로 프로덕션 환경에서 안심하고 사용할 수 있습니다. Seq 정렬 및 동기화 메커니즘은 OpenIM 의 메시지 액세스가 업계 선두임을 보장합니다.

IM 메시징 시스템의 신뢰성은 일반적으로 메시징의 신뢰성을 말합니다. 즉, 우리가 자주 듣는 "메시지는 반드시 도착해야 한다" 는 뜻입니다. 일반적으로 메시지는 손실되지 않고 중복되지 않습니다. 메시지가 전송된 후 수신자가 받을 수 있는지 확인합니다. 네트워크 환경의 복잡성과 온라인 사용자 불확실성으로 인해 메시지의 신뢰성 (손실 없음, 중복 없음) 은 IM 시스템의 핵심 지표이자 IM 시스템 구현의 어려움 중 하나입니다. 일반적으로 IM 시스템의 메시지 "신뢰성" 은 일반적으로 채팅 메시징의 신뢰성을 의미합니다. (정확하게 말하면, 이 메시지는 다양한 사용자가 볼 수 없는 지침과 알림, 그룹 가입 통지, 친구 추가 통지 등을 포함하되 이에 국한되지 않기 때문에 광범위합니다.) 설명하기 쉽도록 통칭하여 "메시지" 라고 부른다.

메시지 발신자와 수신자의 사용자 행동 관점에서 메시지의 "신뢰성" 은 다음과 같은 상황으로 나누어야 합니다.

(1) 전송에 실패했습니다. 이 경우 IM 시스템은 이를 인식하고 발신자에게 명확하게 피드백해야 합니다. 메일 전송에 실패할 경우 발신자는 다시 시도하거나 나중에 다시 시도하도록 선택할 수 있습니다.

(2) 전송에 성공했습니다. 수신자가 온라인 상태인 경우 즉시 이 메시지를 받게 됩니다. 수신자가 오프라인에서 메시지를 수신할 수 없는 경우 온라인 직후 메시지를 수신합니다.

(3) 메시지는 반복할 수 없습니다. 수학 용어로 표현하면' 이 소식밖에 없다' 는 것이다. 반복하면 가능한 의미가 달라진다. 결론적으로, 비즈니스 IM 시스템에는 기본적으로 사용할 수 있는 메시지 "신뢰성" 논리가 포함되어야 합니다. 이것이 IM 시스템의 가장 기본적이고 핵심 논리입니다.

인터넷의 실제 장면은 복잡하지만 클라이언트는 크게 두 가지 경우로 나눌 수 있습니다. (1) 메시지를 보낼 때 수신자는 온라인으로 메시지를 받을 수 있습니다. (2) 메시지를 보낼 때 수신자는 온라인이 아니지만 로그인 후 오프라인 메시지를 받을 수 있습니다. 테스트 프로그램을 사용하여 인터넷 클라이언트의 다양한 시나리오를 시뮬레이션했습니다. 로그인, 메시지 전송 및 메시지 수신에 따라 테스트 클라이언트는 다음 두 가지 유형으로 나뉩니다.

(1) 테스트 시작 시 오프라인, 무작위 수면 0-60 초 후 로그인, 메시지 전송, 메시지 수신.

(2) 테스트를 시작할 때 오프라인, 무작위 수면 0 ~ 60 초 후에 로그인, 메시지만 받고 메시지는 보내지 않는다.

실제 테스트에서는 50 개의 클라이언트가 있고, 약 25 개 (50% 확률) 클라이언트는 메시지만 받지 않고, 약 25 개 (50% 확률) 클라이언트는 메시지를 보내고 받습니다.

전송 방법: 클라이언트당 무작위로 다른 클라이언트를 메시지 수신자로 선택합니다.

테스트 예상: 성공적으로 전송된 각 MsgID 는 수신된 메시지 목록에서 찾을 수 있습니다. 마찬가지로 수신된 각 MsgID 는 성공적으로 전송된 메시지 목록에서 찾을 수 있습니다.

구체적인 조치: (1) 메시지가 성공적으로 전송된 후 OnSuccess 를 통한 MsgID 콜백을 기록합니다. 새 메시지를 받은 후 OnRecvNewMessage 에 응답하여 MsgID； 를 기록합니다. (2) 두 메시지 목록을 정기적으로 비교하여 정확히 일치하는지 확인합니다.

100000 개 데이터 전송 중 3 개 실패, 99999997 개 성공, 수신자가 99999997 개 메시지 수신 성공 (수신자가 성공적으로 메시지 수신, 로컬 db 쓰기, 메시지 콜백 트리거).

성공적으로 전송된 각 메시지는 메시지가 전송될 때 수신자의 로그인 상태가 온라인이든 오프라인이든 간에 정확하게 수신될 수 있습니다.

실패한 메시지를 보낼 때마다 상대방은 받지 않는다.

참고 사항:

(1) SDK 가 로컬 db 를 써야 하기 때문에 클라이언트가 스트레스 병목 현상을 일으킬 수 있기 때문에 스트레스를 제어합니다.

(2) 스트레스 테스트 클라이언트 로그는 테스트 성능에 영향을 줄 수 있습니다.

이 시계는 IM 클라우드 플랫폼의 가격입니다. 월 활동 654.38+ 만 단위로 계산하면 메시지 저장 3 년 동안 매년 654.38+05 만 달러를 지불해야 한다. OpenIM 을 채택하면 클라우드 호스트 한 대만 구매하면 되며, 1 년 비용은 80 만 원 정도입니다.