RocketMQ MQTT 概要

従来のメッセージキューMQは、主にサービス（エンド）間のメッセージ通信に使用されます。例えば、eコマース分野におけるトランザクションメッセージ、決済メッセージ、物流メッセージなどです。しかし、メッセージという大きなカテゴリの中で、もう一つ非常に重要で一般的なメッセージ分野があります。それは、IoT端末デバイスメッセージです。近年、スマートホームや産業相互接続に起因するIoTデバイス向けのメッセージ、そして10年以上発展してきたモバイルインターネットのモバイルAPP側のメッセージは、爆発的に増加しており、その規模は依然として巨大です。端末デバイスのメッセージの規模は、従来のサーバーのメッセージよりも桁違いに大きく、現在も急速に成長しています。

もし、統一されたメッセージシステム（製品）があり、マルチシナリオコンピューティング（ストリーム、イベントなど）とマルチシナリオ（IoT、APP）アクセスを提供できれば、非常に価値があります。なぜなら、メッセージも重要なデータだからです。システムが1つしかないということは、ストレージコストを最小限に抑え、異なるシステム間のデータ同期によって引き起こされる一貫性の問題や課題を効果的に回避できることを意味します。

これに基づき、RocketMQ-MQTT拡張プロジェクトを導入し、RocketMQがIoTデバイスとサーバーのメッセージに統一的にアクセスできるようにし、統合されたメッセージストレージと相互通信機能を提供します。

MQTT プロトコル

IoT端末のシナリオでは、MQTTプロトコルが現在業界で広く使用されています。これは、モノのインターネットのIoTシナリオに端を発する、OASIS Allianceによって定義された標準のオープン プロトコルです。IoTデバイスの種類が多く、動作環境も異なるため、標準のアクセスプロトコルは特に重要です。

MQTTプロトコルは、RocketMQと同様にPub/Sub通信モデルを定義していますが、サブスクリプションの方法がより柔軟で、複数レベルのトピックサブスクリプション（例： "/t/t1/t2"）をサポートし、ワイルドカードサブスクリプション（例： "/t/t1/+"）もサポートできます。

モデル紹介

キューストレージモデル

多次元配信に対応するために、トピックキューモデルを設計しました。上図に示すように、メッセージは様々なアクセスシナリオ（サーバー側のMQ/AMQP、クライアント側のMQTTなど）から来ることができますが、commitlogには1つのコピーのみが書き込まれ、格納されます。そして、複数の需要シナリオのキューインデックス（ConsumerQueue）を配信します。例えば、サーバー側のシナリオ（MQ/AMQP）は、第1レベルのトピックキューに従って従来のサーバー側消費を実行でき、クライアント側のMQTTシナリオは、MQTT複数レベルのトピックとワイルドカードサブスクリプションに従って消費できます。

このようなキューモデルは、サーバーと端末のシナリオのアクセスとメッセージの送受信を同時にサポートし、統合の目標を達成することができます。

プッシュプルモデル

上図はプッシュプルモデルを示しています。図中のPノードはプロトコルゲートウェイまたはブローカープラグインであり、端末デバイスはMQTTプロトコルを介してゲートウェイノードに接続されます。メッセージは様々なシナリオ（MQ/AMQP/MQTT）から送信できます。トピックキューに格納された後、新しいメッセージの到着をリアルタイムで感知する通知ロジックモジュールがあり、メッセージイベント（つまり、メッセージのトピック名）が生成されます。イベントはゲートウェイノードにプッシュされ、ゲートウェイノードは接続されている端末デバイスのサブスクリプション状態に応じて内部マッチングを実行し、どの端末デバイスがマッチングできるかを見つけ、ストレージ層にプルリクエストをトリガーしてメッセージを読み取り、端末デバイスにプッシュします。

アーキテクチャ概要

私たちの目標は、RocketMQに基づいて統合された自己完結型のループを実現することですが、Brokerがより多くのシナリオロジックに侵入されることを望んでいません。プロトコル計算層を抽象化します。これはゲートウェイまたはブローカープラグインです。BrokerはQueueの問題の解決と、上記の計算ニーズを満たすためのQueueストレージの適応または変換に焦点を当てています。プロトコル計算層はプロトコルアクセスを担当し、プラグイン可能でデプロイ可能である必要があります。