ThinkLink 実践ガイド / 現場と運用
ThinkLink の MQTT 復旧を検証する：購読確認・欠損・重複
基本接続の先にある購読確認、転送先、業務処理を検証し、切断中の欠損と重複処理の責任を明確にします。
接続、購読確認、転送先受信、業務保存は別の結果です。再接続の改善だけで、切断時の蓄積、再送、業務上の厳密な一回処理が保証されるわけではありません。
入力から利用側までを図にする
Source Broker、購読トピック、変換、Target Broker、最終利用側を列挙します。AS は元の上りメッセージ、ThinkLink は処理後のデータなので、異なる層の件数をそのまま比較しません。送信先トピック、必要項目、保存担当を明記します。試験は専用端末やトピックへ限定し、各サンプルに追跡可能な業務識別子を付けます。同じ秒に別端末が送ったものを一件と扱わず、件数一致だけで欠損や重複がないと判断しないでください。
接続と購読を別々に確認する
RUNNING は接続状態であり、対象規則の購読成功や業務利用を証明しません。現行文書は購読要求の登録と SUBACK を区別し、入力元が切断中なら復旧後の確認が必要です。有効状態、実トピック、購読結果を確かめ、既知サンプルを送ります。転送先が接続済みでも、変換スクリプトがそのメッセージを除外している場合があります。許可された最小サンプルで変換前後を調べ、調査のために組織全体の機密属性を管理外の Broker へ送らないようにします。
切断中の保証範囲を説明する
文書では転送先が利用不能な場合の新しい蓄積や欠損再送を保証していません。復旧後に新しいメッセージが届いても、中断期間は埋まっていない可能性があります。連続履歴が必要なら照会できる元データ、補完処理、重複排除を設計し、期間と項目を検証します。固定 client_id だけでも永続セッションや業務信頼性は保証されず、同じ Broker の意図しない重複 ID は接続を追い出す場合があります。変更は再接続を伴うため試験時間を決め、再接続を無損失の約束と表現しません。
三種類の中断を試す
正常サンプルの基準を作り、入力元の切断、転送先の切断、利用側の処理停止をそれぞれ試します。復旧後に接続、購読、転送先メッセージ、業務保存を比較し、欠落と重複の識別子を記録します。ローカルの受信処理が二重登録されなくても、MQTT の再配信や送信元の再送は起こり得ます。端末と適切なメッセージ識別子や連番で重複判定を設計し、時刻だけで同秒の正当な値を捨てないようにします。見えない層は成功と推定せず未検証と示します。
- 追跡可能な正常サンプルを作る。
- 入力、転送先、利用側を別々に止める。
- SUBACK、受信、業務保存を確認する。
- 欠損と重複の処理担当を明記する。
受信担当者向けの手順を渡す
トピック、項目契約、双方の担当者、試験 ID、再接続手順、欠損、重複処理を記録します。サーバー属性や共有属性は許可された一部だけの場合があり、項目単位の結合が必要です。状態通知には通常のテレメトリ構造がなく、telemetry_data だけ受ける変換で捨てられる可能性があります。種別追加時は変換条件と利用側処理を再確認します。復旧の完了は接続ランプではなく業務利用側で判定し、履歴再送、順序、信頼できる監査が必要なら独立した設計・検証項目にします。
よくある質問
RUNNING なら業務システムへ届いていますか。
いいえ。購読、変換出力、転送先受信、業務処理を確認します。
固定 client_id なら切断分が再送されますか。
それだけでは保証されません。セッション、Broker、業務復旧を別に検証します。
参考資料と関連情報
以下の公式資料に基づいて作成しています。図は方法の説明用です。正確なメニュー、項目、機能は対象バージョンの資料をご確認ください。リンク先は中国語です。