M2Mqttメッセージのバッファリング

Question

私は、M2MQTTがすぐに使用できるディスクバッファリングをサポートしていないことを知っています。しかし、私はこれを実装する必要があります。この目的は、公開されたすべてのメッセージが実際にブローカに到達したことを確認することです。

今すぐメッセージを公開すると、クラスはディスクに保存されているKey-Valueデータベースに直接メッセージを挿入します。

別のスレッドでは、メソッドがキー値データベースのピーク操作をループし、パブリッシュするメッセージを探します。キー値データベースに新しいメッセージが見つかると、スレッドはM2MqttメソッドPublishを呼び出し、内部M2MQTT内列キューに直接入り、パブリッシュIDを返します。その後、他のデータを公開する前にM2MqttイベントのMessagePublishedを待ちます。イベントが呼び出されると、イベントからのMessagePublished IDとPublishメソッドから受け取ったIDを比較します。それらが等しい場合、メッセージが正常に公開されたことがわかります。

要約すると：

1. スレッド1つのエンキューメッセージをキーと値のデータベースへのキーと値のデータベースキューに
2. スレッド2つの実行PEEKループを
3. スレッド2は、新しいメッセージ
4. スレッドを見つけました2がM2Mqttを呼び出すPublishメソッドからID1を発行して受信する
5. スレッド2は停止し、MessagePublishedイベントを待機し、発行されたIDがID1と等しいかどうかを確認します。この場合、key-va lueデータベースキューは一度デキューされ、この時点でメッセージは正常に送信されたとみなされます。
6. スレッド2は、ステップ2と同様にループを継続し、新しいメッセージを公開することを探します。

すべての操作中にスレッド1が大量のメッセージをエンキューすることがありますが、スレッド2はメッセージを1つずつ公開してメッセージが正常に発行されたことを確認してからキー値データベースを作成し、それを送信することを検討してください。スレッド1から出たのと同じ順序でブローカーに公開する必要があります。

スレッド2がスレッド1から受信したすべてのメッセージをキー値データベース経由で公開したばかりです。スレッド2は、メッセージがブローカに実際に届かなかったにもかかわらず、キー値データベースから値をデキュー/削除する可能性があります。 RAMの空き待ち行列にある可能性がありますが、サーバの再起動またはサービスの再起動によってこのキューは空になり、スレッド2は実際にブローカに到達したことを確認せずにキー値データベースからメッセージ2を取り出します。

M2Mqttを使用してこの実装をベストプラクティスで行う必要があるかどうかをガイドできますか？パターンはベストプラクティスより優れていますか？このタイプの実装には、どのようなキーバリューデータベースが適していますか？今はSqlCeCompactを使ってみました。

Answer 1

MQTTクライアントが再起動された瞬間に、問題が発生します。これは、番号付けもリセットされるためです。 私にとって重要なのは私の立場では、メッセージは順番に保管され、タイムスタンプを使用する必要があります。これは、メッセージの順序を追跡し、サーバー上のメッセージを処理する唯一の可能性です。 トピックに公開すると、トピック内の単一のメッセージに制限されます。キューベースのプロトコルを使用するほうが良いでしょう。