テーマ
トピックは、接続されている各クライアントのメッセージをフィルター処理するためにブローカーが使用する UTF-8 文字列です。トピックは 1 つ以上のトピック レベルで構成されます。各トピック レベルはスラッシュ (トピック レベル区切り文字) で区切られます。
トピックはメッセージ キューに比べて非常に軽量です。ブローカーは事前初期化なしですべての有効なトピックを受け入れるため、クライアントはパブリッシュまたはサブスクライブする前に必要なトピックを作成する必要はありません。
以下にいくつかのサンプルテーマを示します。
myhome/1 階/リビングルーム/温度
米国/カリフォルニア/サンフランシスコ/シリコン バレー
5ff4a2ce-e485-40f4-826c-b1a5d81be9b6/ステータス
ドイツ/バイエルン/車/2382340923453/緯度
各件名には少なくとも 1 バイトが含まれている必要があり、スペースも含めることができることに注意してください。また、テーマでは大文字と小文字が区別されるため、myhome/temperatureとMyHome/Temperature は2 つの別個のテーマになります。さらに、スラッシュだけでも有効なテーマです。
ワイルドカード
クライアントがトピックをサブスクライブする場合、メッセージがパブリッシュされた正確なトピックを使用することも、ワイルドカードを使用してより多くのトピックを同時にサブスクライブすることもできます。ワイルドカードはトピックをサブスクライブする場合にのみ使用でき、メッセージをパブリッシュする場合には使用できません。以下では、単一レベルとマルチレベルのワイルドカードという 2 つの異なるタイプを 1 つずつ紹介します。
単一レベル: +
名前がすでに示しているように、単一レベルのワイルドカードがサブジェクト レベルを置き換えます。プラス記号は、トピック内の単一レベルのワイルドカードを示します。
ワイルドカード以外の任意の文字列で構成されるトピック レベルは、単一レベルのワイルドカードで構成されるトピック レベルと照合できます。たとえば、myhome/groundfloor/+/temperatureへのサブスクリプションは、次のトピックと一致するか一致しません。
マルチレベル: #
シングルレベルのワイルドカードは 1 つのトピック レベルのみをカバーしますが、マルチレベルのワイルドカードは任意の数のトピック レベルをカバーできます。一致する件名を決定するには、マルチレベル ワイルドカードは常に件名の最後の文字であり、その前にスラッシュを付ける必要があります。
マルチレベルのワイルドカードを使用してトピックをサブスクライブしているクライアントは、トピックが取得される長さや深さに関係なく、ワイルドカードの前のパターンで始まるすべてのメッセージを受信します。マルチレベルのワイルドカードをトピック ( # ) としてのみ指定した場合、MQTT ブローカー経由で送信されたすべてのメッセージを取得することになります。このアンチパターンで高いスループットが期待される場合は、以下のベスト プラクティスを参照してください。
$で始まるトピック
一般に、トピックに名前を付けるのは完全に自由ですが、例外が 1 つあります。$ で始まる各トピックは特別に扱われます。たとえば、#を購読する場合、$ で始まるこれらのトピックは購読されたコンテンツには含まれません。これらのトピックは、MQTT ブローカー サーバーの内部機能として予約されています。したがって、クライアントはこれらのトピックにメッセージをパブリッシュできません。現在、ブローカーがリリースするトピックの形式に関する明確な公式標準はありません。一般的には、***$SYS/*** で始まり、その後に別の形式が続きます。$SYS トピックの提案はMQTT GitHub wikiにあります。いくつかの例を次に示します。
$SYS/broker/clients/接続済み
$SYS/broker/clients/切断
$SYS/broker/clients/合計
$SYS/broker/messages/sent
$SYS/broker/uptime
概要
これらは、MQTT メッセージ トピックに関する基本です。ご覧のとおり、MQTT トピックは動的であり、開発者に大きな柔軟性を与えます。ただし、この知識を実際のプログラムに適用する場合には、いくつかの課題があることに注意する必要があります。昨年から MQTT の学習を開始し、多くのプロジェクトで MQTT を頻繁に使用したベスト プラクティスを集めました。コメントでの提案や議論を歓迎します。ベスト プラクティスに同意できない場合は、ベスト プラクティスをお知らせください。
スラッシュで始めないでください。 MQTT では、 /myhome/groundfloor/livingroom
のように、スラッシュで始めることができます。ただし、これにより、最初に不要なゼロバイトのトピック レベルが生成されます。この状況は何の役にも立たず、不必要な混乱を引き起こすため、避けるべきです。
トピック内でスペースを使用しないでください。
スペースはすべてのプログラマーにとって天敵です。スペースを含むトピックの読み取りとデバッグは、例外が発生した場合に非常に困難になる可能性があります。したがって、最初の点と同様に、許可されていることは、それを行うよう推奨されることを意味するものではありません。UTF-8 には多くの種類のスペースがあり、この特殊文字の使用を避けるべきであることは明らかです。
件名を短く明確にする
すべての情報には、その情報に使用される件名が含まれるため、件名を簡潔に保つように努める必要があります。特に小型デバイスでは、すべてのバイトが重要になります。
ASCII 文字のみを使用し、印刷不可能な文字を避ける
ASCII 以外の UTF-8 文字を使用すると、これらの文字は正しく表示されないことが多いため、文字に起因するタイプミスやエラーを見つけることが困難になります。必要な場合を除き、件名に非 ASCII 文字を使用することはお勧めしません。
メッセージを公開したクライアントを簡単に識別できるように、トピックに一意の識別子を埋め込むか、トピックにクライアント ID を埋め込んでメッセージを公開したクライアントの一意の識別子を埋め込むと便利です。もう 1 つの便利な側面は認証です。これにより、クライアントは自分の ID に関連付けられたトピックのみを公開できるようになります。したがって、 ID client1を持つクライアントはclient1/statusのみを公開できますが、client2/statusは公開できません。
サブスクライブしない#
場合によっては、たとえばデータをデータベースに永続化する必要がある場合など、すべてのブローカーで送信されるメッセージをサブスクライブする必要があります。この機能を実現するために、MQTT クライアントを使用してマルチレベルのワイルドカードをサブスクライブしないでください。これは、特にシステムのスループットが大きい場合、クライアントが蓄積されたメッセージを処理できないためです。HiveMQ のプラグイン システムを使用するなど、MQTT ブローカーに拡張機能を実装することをお勧めします。これにより、HiveMQ アクションをフックし、受信した各メッセージを処理してデータベースに保存する非同期プログラムを追加できます。
スケーラビリティを忘れないでください トピック
は柔軟な概念であり、スペースを事前に割り当てる必要はありませんが、パブリッシャーとサブスクライバーの両方がそれを認識している必要があります。したがって、新しい機能を追加しながら、現在のテーマをうまく拡張する方法を考えることが重要です。たとえば、スマート ホーム システムに新しいセンサーを追加する必要がある場合、テーマのアーキテクチャを変更せずにセンサーを追加できる必要があります。
一般的なトピックではなく、特定の
トピックを使用する トピックに名前を付ける場合に重要なのは、トピックをキュー内で使用しないようにすることです。たとえば、
すべてのメッセージに同じトピックを使用するのは悪いパターンです。件名はできるだけ具体的にする必要があります。したがって、リビング ルームに 3 つのセンサーがある場合は、myhome/livingroom を通じてすべての値を送信するのではなく、myhome/livingroom/温度、myhome/livingroom/明るさ、myhome/livingroom/湿度などのトピックを使用する必要があります。これにより、メッセージの永続化などの他の MQTT 機能も簡単に使用できるようになります。これについては次の章で説明します。
著者：qinwenbo
リンク：https://www.jianshu.com/p/fd8b379225fe
出典：Jianshu
著作権は著者に属します。商業的転載の場合は著者に連絡して承認を求め、非商業的転載の場合は出典を明記してください。