1000 개 이상의 클라이언트에서 MQTT를 확장 할 수 있습니까?

TCP 소켓을 통해 하루에 한 번 서버에 페이로드를 보내는 시나리오 IoT 장치 (현재 IPv4 장치). 서버에 공개 IP 주소가 있고 장치가 라우터 / NAT 뒤에 있습니다. ESP8266 (예 : Olimex one)을 기반으로 모듈을 사용하겠습니다

목표 서버 가해야 할 때마다 모든 클라이언트에 데이터를 송신 할 수 있어야한다. 홀 펀칭과 같이 클라이언트 간 통신 (예 : 스마트 폰에서 장치에 연결)에 관심이 없습니다.

기타 요구 사항
IoT 장치는 최대 수천 개까지 성장할 수 있습니다. 인터넷 연결은 많은 4G 지원 라우터 / 모뎀에서 제공됩니다. 각각 10-20 명의 클라이언트를 처리합니다.

제안 된 솔루션
제가 알고있는 한 일반적인 솔루션은 MQTT입니다. 클라이언트는 주기적으로 데이터를 브로커 (예 : 호스팅 서버에서 실행되는 Mosquitto)로 전송하여 동일한 서버에서 실행되는 기본 웹 앱을 업데이트합니다.

질문
MQTT 접근 방식이 4G 라우터 뒤에있는 "대형"장치 (1000+)에 가장 적합합니까?

mqtt wifi routers

— 표
소스

질문 (1)을 별도로 요청하고 질문 본문의 제목과 일치하는 질문 (2)를하는 것이 좋습니다. 이러한 방식으로 각 질문을 개별적으로 자세히 처리 할 수 있습니다. 새로운 질문에 컨텍스트를 다시 포함 시키거나 도움이되는 경우이 질문에 링크 할 수 있습니다.

— Aurora0001

질문이 바뀌었고 두 번째 질문이 추가되었습니다.

— Mark

소리를 들으면서 많은 수의 열린 연결을 보유 할 때 서버로드 문제가 발생하더라도 시스템은 클라이언트가 해당 세션을 보유하고 중간 세션에 연결하는 트리 유형의 토폴로지와 상당히 호환됩니다. 단일 파이프에서 각각 더 높은 서버로의 드문 트래픽 증가 및 감소 아마도 4G 라우터에서 로컬의 첫 번째 계층을 수행 할 수도 있습니다.

— Chris Stratton

답변:

적절한 MQTT 브로커가 1,000 개의 클라이언트를 쉽게 처리 할 수 있습니다. Scalagent 의 벤치 마크 는 다음과 같은 PC를 보여줍니다.

3GHz Intel Core 2 Duo 프로세서
4GB의 RAM

모스키토를 운영하는 6 만 명의 출판사를 처리 할 수있었습니다. 이는 필요한 1,000 명의 게시자를 훨씬 초과하므로 상대적으로 약한 서버에서도 필요한 수를 처리 할 수 있어야합니다.

일부 다른 중개인 은 천만 명의 게시자 를 처리한다고 주장한 HiveMQ 와 같이 더 나은 성능 (물론 서버 성능도 높음 )을 주장합니다 .

MQTT 브로커는 일반적으로 지속적인 연결을 기대하며 주기적으로 핑 응답 (또는 다른 활동)을 보내지 않는 클라이언트를 제한 시간 초과합니다. 게시 후 네트워크에서 연결을 끊을 수 있지만 연결을 끊으면 아무 것도 수신 할 수 없습니다.

MQTT는 유용 할 수있는 '보류 된'메시지 개념을 지원합니다. 웹 클라이언트는 보유 된 플래그를 사용하여 주제에 무언가를 게시 할 수 있으며이 메시지는 브로커에 의해 저장됩니다. 클라이언트가 주제를 다시 연결하고 구독 할 때마다 보존 된 메시지를받습니다 (시간 전에 게시 된 경우에도). 보관 된 메시지는 클라이언트가 해당 주제를 구독 할 때마다 게시 되므로 패치 연결이되어 있고 클라이언트가 다시 연결될 때까지 메시지를 저장해야하는 경우 도움이 될 수 있습니다.

— Aurora0001
소스

나는 분명히 그것을 잘못 설명했다. 서버 (상업용 호스팅 서비스)만이 1000 개 이상의 클라이언트를 처리해야합니다. 여러 곳에 4G 라우터가 많이 있으며 각각 10-20 개의 클라이언트 만 처리합니다.

— Mark

오, 나는 잘못 읽었다 – 나의 잘못, @Mark, 나는 당신이 하나의 4G 라우터 뒤에 모든 것을 의미한다고 가정했다 . 이 경우에 이것을 편집하겠습니다.

— Aurora0001

아직 MQTT의 기본 코드를 완전히 이해하지 못합니다. 4G 연결이 두렵습니다. MQTT에 지속적인 인터넷 연결이 필요합니까? 아마도 네트워크가 불안정 할 것입니다 ...

— Mark

@Mark; 그것이 올바른 방향으로 당신을 가리키는 경우 알려주십시오.

— Aurora0001

예, 지금은 더 명확합니다. 이 주제에 대한 추가 검색을 수행 할 것이며 여전히 도움이 필요한 경우 다른 질문을하겠습니다. 고마워

— Mark

클라이언트에서 영구 세션을 사용할 수 있습니다 (예 : 연결시 정리 플래그를 false로 설정). 이 시나리오에서 클라이언트가 오프라인 일 때 브로커는 메시지를 자체 캐시로 버퍼링하고 장치가 연결되면 전달합니다.

수량 정보-10K는 한 서버에서도 비교적 적은 양입니다. 500K 활성 연결을 보유하도록 Linux 서버를 구성 할 수 있으며 브로커가 클라우드 기반 (예 : 일부 제공자가 서비스로 제공) 인 경우 수백만 개의 활성 연결을 보유 할 수 있습니다.

그건 그렇고, Mosquitto 또는 다른 로컬 설치는 개발 및 테스트에 완벽한 선택이라고 생각하지만 프로덕션 환경에 들어가려면 HA, 중복, 장애 조치 등과 같은 모든 기능을 갖춘 SaaS MQTT 브로커가 필요합니다.

— 샬
소스

SaaS MQTT 브로커가 항상 프로덕션에 최고라고 생각하지 않습니다. 대부분의 전문 (자체 호스팅) MQTT 브로커는 완전한 MQTT 호환성을 유지하면서 HA, 중복성 및 페일 오버를 대규모로 지원합니다. 일부 SaaS 브로커는 모든 MQTT 기능을 지원하지 않습니다. 현지 모기에 대해 테스트 한 다음 SaaS 제공 업체에 가면 의도 한대로 생산에 문제가있을 가능성이 있습니다.

— 도미니크 오버 마이어

평소와 같이 두 옵션의 장단점이 있습니다. 모든 SaaS 브로커는 완벽한 의사 소통 팀, 제품 개발 초기 단계의 장기 테스트, 명확한 가동 시간 보장 및 다양한 SLA가 필요합니다. 자체 중개인을 유지하는 것도 좋은 방법이지만 세계는 서비스로 이동하고 있습니다. 브로커를 그 일부로 사용하는 제품에 노력을 기울이고 가장 유능한 사람이거나 숙련 된 MQTT 브로커 관리자 (및 개발자가되지 않음)가되기 위해 시간과 돈을 소비하게됩니다. 선택의 문제 +)

— shal