# 구독하지 마세요-모스키토를 사용하여 모든 메시지를 데이터베이스에 덤프하는 방법은 무엇입니까?

HiveMQ의 블로그 는 "모범 사례"아래에 모든 메시지를 데이터베이스에 덤프하려고 할 때 멀티 레벨 와일드 카드를 구독하지 않는 것으로 표시합니다. 그들은 구독 클라이언트가 많은 양의 메시지를 따라 잡을 수 없으며 대신 브로커 플러그인을 사용하여 메시지 스트림에 직접 연결할 것을 제안합니다.

경우에 따라 브로커를 통해 전송되는 모든 메시지를 구독해야하는 경우가 있습니다 (예 : 모든 메시지를 데이터베이스에 유지하는 경우). MQTT 클라이언트를 사용하고 멀티 레벨 와일드 카드를 구독하여 수행하면 안됩니다. 그 이유는 구독 클라이언트가 자주 오는 메시지를 처리 ​​할 수 ​​없기 때문입니다. 특히 처리량이 많은 경우. 권장되는 솔루션은 MQTT 브로커에서 확장을 구현하는 것입니다. 예를 들어 HiveMQ의 플러그인 시스템을 사용하면 HiveMQ의 동작에 연결하고 비동기 루틴을 추가하여 각 수신 메시지를 처리하고 데이터베이스에 유지할 수 있습니다.

어느 쪽이 있습니까

• 모기 브로커와 유사한 시스템 (확장 / 플러그인)
• 모기와 함께 작동하는 다른 권장 방법 또는
• 이 접근법이 전혀 필요하지 않다는 합리적인 증거, 즉 구독하는 고객이 #잘 할 수 있다는 합리적인 증거 ?

^{/programming//q/31584613/3984613 은이 질문을 철저히 다루지 않습니다.}

모기 브로커와 유사한 시스템 (확장 / 플러그인)

내가 아는 한 모기 중개인을위한 플러그인 / 확장 프로그램이 없습니다 (적어도 오픈 소스가 없음)

모기와 함께 작동하는 또 다른 권장 방법

모스키토 브로커와 AWS IoT에 대한 나의 경험에 따르면 '#'을 직접 구독하면됩니다.

합리적인 증거

이 질문을 살펴본 후 처리량 제한을 알고 확장 시스템이 필요한지 궁금했습니다. 그래서 다음을 설정했습니다.

• 게이트웨이에 임의의 데이터를 전송하기위한 가상 엔드 디바이스 역할을하는 100 개의 AWS Lambda 함수 (EC2 인스턴스 t2.nano500MB RAM)
• 60 초마다 함수가 트리거되어 다른 주제로 데이터를 게이트웨이에 게시합니다 (lambdatoec2 / {VariableTopicNumberFrom1-100}
• EC2 인스턴스가 Mosquitto 1.4.10을 실행 중입니다

현재로서는 확장 시스템없이 #을 구독하는 데 아무런 문제가 없음을 알았습니다. 그러나 다시 한 번 소수의 시나리오를 테스트해야합니다 (테스트 한 번하면 답변을 업데이트 할 것입니다).

openHAB 메일 링리스트에 대한이 논의는# 모든 메시지를 수신하기 위해 구독으로 사용 하는 데 아무런 문제가 없음을 시사하는 것 같습니다 .

MQTT 장치의 문제점을 해결하는 동안 때때로 특정 주제 대신 Mosquitto 브로커가 보는 모든 MQTT 메시지를 볼 수 있기를 원했습니다. 이것을 할 수있는 방법이 있습니까?

누군가가 모스키토 목록에서이 질문에 답변했습니다. 와일드 카드를 사용하십시오. (#)

이 스택 오버플로 질문 도 동일한 방법을 제안합니다.

#을 구독하면 $로 시작하는 주제를 제외한 모든 주제를 구독하게됩니다 (이는 일반적으로 제어 주제입니다).

물론 무엇을 구독하고 있는지 아는 것이 좋습니다. 물론 일부 브로커 구성에서는 #을 명시 적으로 구독하지 못할 수도 있습니다.

에 의해 지적 벤스 Kaulics , 사양은 상태 않습니다 #유효을 :

비 규범적인 의견

• “#”은 유효하며 모든 신청 메시지를받습니다

솔직히, 나는 원래의 주장이 정말로 의미가 있는지에 대해 이의를 제기합니다.

그 이유는 구독 클라이언트가 자주 오는 메시지를 처리 ​​할 수 ​​없기 때문입니다.

이 경우 브로커가 메시지를 처음에 어떻게 처리 할 수 ​​있습니까? 언제 까지나 당신의 클라이언트가 브로커와 비슷한 성능 특성이 있기 때문에, 나는 강하게 은 트래픽의 수준도 첫 충돌이있는 브로커와 원인을 압도하기 때문에, 클라이언트를 압도 할 수있을 것이라고 의심한다.

요약하면, HiveMQ 클레임은 다른 출처의 많은 증거에 의해 뒷받침되지 않는 것으로 보이며 실제로 의미하는 바를 고려할 때 특히 논리적으로 보이지는 않습니다.

MQTT 브로커에는 다른 소프트웨어와 마찬가지로 다양한 사용 사례가 있다고 생각하는 것이 중요하다고 생각합니다.

10 억 사용자 (많은 사용자, 사용자 당 비교적 낮은 메시지 전송률)의 채팅 메시지 처리는 클라이언트가 적지 만 메시지 전송률이 높은 시스템과 다르며 홈 자동화 시스템 (클라이언트가 적고 메시지 전송률이 낮은 시스템)과 다릅니다. .

HiveMQ는 매우 높은 클라이언트 / 메시지 비율 응용 프로그램에 대해 생각하고 있습니다.이 경우 브로커의 기능이 클라이언트의 기능을 거의 능가합니다.

#홈 오토메이션 시스템에 가입하고 싶다면 실제로 문제가 발생하지 않을 것입니다. 어떤 경우에도 브로커가 과도한 CPU를 사용하고 있는지 확인할 수 있습니다.

다른 답변에서와 같이 구독 #하면 모든 '정상적인'주제, 즉로 시작하지 않는 주제가 제공됩니다 $. 나는부터 시작하여 각 주제는 것을 말 사양을 해석하는 $당신이에 가입해야 할 것, 그래서 그 자체가 전체 분리 된 나무입니다 $SYS/#, $whatever/#얻기 위해 모든 것을 . 어쨌든 일반적인 응용 프로그램에서는 그렇게하고 싶지 않습니다.