MQTTは1000以上のクライアントでスケーラブルですか?


10


TCPソケットを介してペイロードを1日1回サーバーに送信するシナリオ IoTデバイス(現在はIPv4デバイス)。サーバーにはパブリックIPアドレスがあり、デバイスはルーター/ NATの背後にあります。ESP8266に基づくモジュール(つまり、Olimexのモジュール)を使用します

目標は、サーバーは、それが必要とする時はいつでも任意のクライアントにデータを送信することができるはずです。ホールパンチングのように、クライアントからクライアントへの直接通信(つまり、スマートフォンからデバイスに接続)には興味がありません。

その他の要件
IoTデバイスは数千まで成長する可能性があります。彼らのインターネット接続は、多くの4G対応ルーター/モデムによって提供されています。それぞれが10〜20のクライアントを処理します。

提案される解決策
私が理解している限り、一般的な解決策はMQTTです。クライアントは定期的にブローカー(ホスティングサーバーで実行されているMosquitto)にデータを送信します。ブローカーは同じサーバーで実行されているメインのWebアプリを更新します。

質問
MQTTアプローチは、4Gルーターの背後にある「多数」のデバイス(1000以上)に適していますか?


質問(1)を個別に質問し、質問本文のタイトルと一致する質問(2)を質問するだけの方がよい場合があります。このように、私たちはあなたの質問のそれぞれに個別に詳細に対処することができます。それが役立つ場合は、新しい質問またはこの質問へのリンクにコンテキストを再度含めることができます。
Aurora0001

1
質問が変更され、2番目の質問が追加されました。
マーク

そのサウンドから、多数のオープン接続を保持することでサーバーの負荷の問題が発生した場合でも、システムは、対応するセッションを保持し、どちらかを渡す中間サーバーにクライアントが接続するツリー型のトポロジと完全に互換性があります。単一のパイプで、より高いサーバーへのトラフィックの上下。あなたはおそらく4Gルーターでこれの最初の層をローカルで行うことさえできるでしょう。
クリスストラットン

回答:


7

1,000クライアントは、適切なMQTTブローカーで簡単に処理できます。Scalagentのベンチマークでは、次の機能を備えたPCを示しています。

  • 3 GHz Intel Core 2 Duoプロセッサ
  • 4 GBのRAM

Mosquittoを実行している60,000の発行元を処理できます。これは、必要な1,000のパブリッシャーをはるかに超えているため、比較的弱いサーバーでも、必要な数を処理できるはずです。

他のいくつかのブローカーは、1,000万のパブリッシャーを処理すると主張しているHiveMQなど、さらに優れたパフォーマンスを(当然、それに応じてサーバーの能力もより高く)主張しています。

MQTTブローカーは通常、永続的な接続を想定しており、ping応答(またはその他のアクティビティ)を定期的に送信しないクライアントをタイムアウトします。公開後にネットワークから切断することもできますが、当然、切断すると何も受信できなくなります。

MQTTは、便利な「保持」メッセージの概念をサポートします。Webクライアントは、保持されたフラグを使用してトピックに何かを公開でき、このメッセージはブローカーによって保管されます。クライアントが再接続してトピックにサブスクライブするたびに、保持されたメッセージを受信します(数時間前に公開された場合でも)。保持されたメッセージは、クライアントがそのトピックにサブスクライブするたびに公開されるため、パッチ接続があり、クライアントが再接続するまでメッセージを保存する必要がある場合に役立ちます。


きっと間違って説明しました。サーバー(商用ホスティングサービス)のみが1000以上のクライアントを処理する必要があります。さまざまな場所に4Gルーターが多数あり、それぞれが10〜20台のクライアントしか処理しません。
マーク・

ああ、私は誤解しました—私のせい、@ Mark、私はあなたが1つの 4Gルーターの後ろにそれらすべてを意味していると思いました。その場合はこれを編集します。
Aurora0001

MQTTの基礎となるコードをまだ完全に理解していません-4G接続を恐れていました。MQTTには永続的なインターネット接続が必要ですか?ネットワークが不安定になる可能性があります...
マーク

私はいくつかの提案、@ Markで編集しました。それが正しい方向を示しているかどうかをお知らせください。
Aurora0001

1
はい、はっきりしています。このトピックについてさらに検索を行います。さらにサポートが必要な場合は、別の質問をします。どうもありがとう。
マーク・

5

クライアントからの永続的なセッションを使用できます。たとえば、接続時にクリーンフラグをfalseに設定します。そのシナリオでは、クライアントがオフラインの場合、ブローカーはメッセージを独自のキャッシュにバッファーし、デバイスが接続すると配信します。

数量について-1台のサーバーでも、10Kは比較的少ない金額です。500Kのアクティブな接続を保持するようにLinuxサーバーを構成できます。ブローカーがクラウドベースになる場合、たとえばプロバイダーによってサービスとして提供される場合は、何百万ものアクティブな接続を保持できます。

ちなみに、Mosquittoやその他のローカルインストールは、開発とテストに最適な選択肢だと思いますが、本番環境に入るときは、HA、冗長性、フェイルオーバーなどのすべての機能を備えたSaaS MQTTブローカーが必要です。


SaaS MQTTブローカーが常に本番環境に最適であるとは思いません。ほとんどのプロフェッショナル(セルフホスト)MQTTブローカーは、完全なMQTT互換性を維持しながら、HA、冗長性、フェイルオーバーを大規模にサポートします。一部のSaaSブローカーはすべてのMQTT機能をサポートしていません。ローカルの蚊に対してテストを行ってからSaaSプロバイダーにアクセスすると、本番環境では意図したとおりに機能しない可能性があります。
ドミニクオーバーマイヤー

いつものように、両方のオプションの長所と短所があります。どのSaaSブローカーも、完璧なコミュニケーションチーム、製品開発の初期段階での長期テスト、明確な稼働時間の保証、さまざまなSLAを必要とすることは明らかです。独自のブローカーを維持することも良い方法ですが、世界はサービスに移行しています。ブローカーをその一部として使用する製品に力を注ぎ、最も有能であるか、非常に経験豊富なMQTTブローカー管理者になるために時間とお金を費やします(開発者になることは決してありません!)。選択の問題+)
シャル
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.