＃をサブスクライブしないでください-Mosquittoを使用してすべてのメッセージをデータベースにダンプする方法は？

HiveMQのブログには、すべてのメッセージをデータベースにダンプしようとするときにマルチレベルワイルドカードをサブスクライブしない「ベストプラクティス」の下にリストされています。彼らは、サブスクライブしているクライアントが高負荷のメッセージに追いつくことができないかもしれないと主張し、代わりにブローカプラグインを使用してメッセージのストリームに直接フックすることを提案します。

場合によっては、すべてのメッセージをサブスクライブする必要があります。これらのメッセージは、すべてのメッセージをデータベースに永続化する場合など、ブローカー経由で転送されます。これは、MQTTクライアントを使用して、マルチレベルワイルドカードをサブスクライブすることで実行しないでください。その理由は、多くの場合、サブスクライブしているクライアントが、送信されるメッセージの負荷を処理できないことです。特に、大量のスループットがある場合。推奨されるソリューションは、MQTTブローカーに拡張機能を実装することです。たとえば、HiveMQのプラグインシステムを使用すると、HiveMQの動作にフックし、非同期ルーチンを追加して各着信メッセージを処理し、データベースに保持できます。

どちらかありますか

• mosquittoブローカー用の同様のシステム（拡張機能/プラグイン）、
• 蚊と連携する別の推奨方法、または
• このアプローチがまったく不要であるという合理的な証拠、すなわち、購読しているクライアント#がうまくいくことができるということですか？

^{/programming//q/31584613/3984613は、この質問を網羅的に扱っていません。}

mosquittoブローカー用の同様のシステム（拡張機能/プラグイン）

私の知る限り、mosquittoブローカー用のプラグイン/拡張機能はありません（少なくともオープンソースはありません）

mosquittoで動作する別の推奨方法

MosquittoブローカーとAWS IoTでの経験から言えば、「＃」に直接サブスクライブできます

合理的な証拠

この質問を見た後、スループットの限界を知り、拡張システムが必要かどうかを知りたいと思いました。そこで、以下を設定しました。

• 仮想エンドデバイスとして機能して、ゲートウェイにランダムデータを送信する100個のAWS Lambda関数（EC2インスタンスt2.nano500MB RAM）
• 60秒ごとに機能がトリガーされ、さまざまなトピックへのゲートウェイにデータを公開します（lambdatoec2 / {VariableTopicNumberFrom1-100}
• EC2インスタンスはMosquitto 1.4.10を実行しています

今のところ、拡張システムなしで＃をサブスクライブしても問題ないことがわかります。しかし、ここでもいくつかのエッジケースシナリオについてテストする必要があります（テストしたら回答を更新します）。

openHABメーリングリストに関するこの議論は、#すべてのメッセージを受信するためのサブスクリプションとしての使用に問題がないことを示唆しているようです。

MQTTデバイスのトラブルシューティング中に、特定のトピックではなく、Mosquittoブローカーが表示するすべてのMQTTメッセージを表示したい場合があります。これを行う方法はありますか？

Mosquittoリストで誰かがこの質問に答えてくれました。ワイルドカードを使用します。（＃）

このStack Overflowの質問も同じ方法を提案しています。

＃にサブスクライブすると、$で始まるトピックを除くすべてのサブスクリプションが提供されます（これらは通常とにかくコントロールトピックです）。

もちろん、最初にサブスクライブしているものを把握し、ブローカーの構成によっては明示的に＃サブスクライブできない場合があることに注意してください。

Bence Kaulicsが指摘したように、仕様はそれ#が有効であると述べています。

非規範的コメント

• 「＃」は有効で、すべてのアプリケーションメッセージを受信します

正直なところ、元の主張が本当に意味をなすかどうかについては異議を唱えます。

その理由は、多くの場合、サブスクライブしているクライアントが、送信されるメッセージの負荷を処理できないことです。

その場合、ブローカーはそもそもメッセージをどのように処理できますか？クライアントがブローカーと同様のパフォーマンス特性を持っている限り、そのレベルのトラフィックもブローカーを圧倒し、最初にクラッシュさせるため、クライアントを圧倒する可能性があることを強く疑います。

要約すると、HiveMQの主張は他の情報源からの多くの証拠によって裏付けられていないようであり、実際に何を意味するのかを考えると、特に論理的ではないようです。

他のソフトウェアと同様に、MQTTブローカーにはさまざまなユースケースがあることを考慮することが重要だと思います。

10億人のユーザー（多くのユーザー、ユーザーあたりの比較的低いメッセージレート）のチャットメッセージの処理は、クライアントが少ないがメッセージレートが高いシステムとは異なり、どちらもホームオートメーションシステム（少数のクライアント、低いメッセージレート）とは異なります。

HiveMQは、非常に高いクライアント/メッセージレートアプリケーションについて考えています。この場合、ブローカーの能力はほぼ確実にクライアントの能力をはるかに上回ります。

#ホームオートメーションシステムで購読したい場合、問題を引き起こす可能性はほとんどありません。いずれにしても、ブローカーが過剰なCPUを使用しているかどうかを確認できます。

他の回答と同様に、にサブスクライブする#と、すべての「通常の」トピック、つまりで始まらないすべてのトピックが表示されます$。で始まる各トピック$はそれ自体が完全に別個のツリーであると言っていると仕様を解釈しているため$SYS/#、すべて$whatever/#を取得するには、サブスクライブする必要があります。とにかく、通常のアプリケーションではそれをしたくないでしょう。