概要
ストリーミングデータを利用する際、接続時間を最大化し、マッチしたすべてのデータを受信することが基本目標です。これには以下が必要です。- 冗長接続を活用する
- 切断を自動的に検出する
- 迅速に再接続する
- 失われたデータを復旧する計画を持つ
冗長接続
冗長接続を使用すると、同じストリームに複数の同時接続を確立できます。これは 2 つの別々のコンシューマで接続し、両方の接続を通じて同じデータを受信することで冗長性を提供します。 利点:- いずれか一方のストリームが切断された場合のホットフェイルオーバー
- プライマリサーバーが停止した場合の保護
- 再接続中の継続的なデータ配信
使い方
同じストリーム URL に別のクライアントで接続するだけです。データは両方の接続を通じて送信されます。冗長接続は Enterprise アクセスで利用可能です。Filtered Stream は Enterprise プロジェクトで最大 2 つの冗長接続を許可します。Firehose Streams は
partition パラメータを使用して最大 20 の同時接続をサポートし、Sample10（Decahose）は最大 2 パーティションをサポートします。接続数の上限については、各エンドポイントのドキュメントを確認してください。Backfill
切断を検出した後、切断がどの程度続いたかを追跡し、適切な復旧方法を判断する必要があります。5 分以内の切断
再接続時に backfill パラメータ を使用して、切断期間中にマッチした Post を受信します。
リクエスト例:
Filtered Stream:
重要な考慮事項:
- 一般的に、新しくマッチした Post よりも古い Post が先に配信されます
- Post は 重複排除されません — 90 秒間切断していて 2 分間の backfill をリクエストすると、30 秒分の重複した Post を受信します
- システムは重複に対して耐性を持つ必要があります
- Backfill は Enterprise アクセスで利用可能です
Recovery
5 分を超える 切断の場合、Recovery 機能を使用して過去 24 時間以内の欠落データを再生します。Recovery の仕組み
start_timeとend_timeパラメータを付けて接続リクエストを行う- Recovery が指定期間を再ストリームする
- 完了すると接続が切断される
パラメータ
リクエスト例
Filtered Stream:Recovery の制限:
- Enterprise アクセスで利用可能
- Recovery ウィンドウ: 過去最大 24 時間
- Filtered Stream は 2 つの同時 Recovery ジョブを許可
- Firehose、Sample10（Decahose）、言語別 firehose ストリームも Recovery をサポート
- 基本的な 1% Sample Stream は Recovery をサポートしていません。代わりに Search エンドポイントを使用してください
代替の復旧方法: Search
backfill や Recovery 機能にアクセスできない場合、または切断が 24 時間を超えた場合は、Search Posts エンドポイント を使用して欠落データをリクエストできます。Recovery 判断ツリー
ベストプラクティス
- 切断時間を追跡 — 切断が発生した時刻とその継続時間を記録しましょう
- 自動復旧を実装 — 切断時間に基づき、適切な復旧方法を自動的に選択します
- 重複を処理 — backfill と Recovery のいずれも重複した Post を配信する可能性があります。重複排除ロジックを実装してください
- 冗長接続を使用 — 利用可能な場合は複数の接続を維持してデータの損失を防ぎます
- Recovery ジョブを監視 — Recovery 操作のステータスと完了を追跡します
次のステップ
切断の処理
切断を検出して処理
ストリーミングデータの利用
堅牢なストリーミングクライアントを構築
大容量キャパシティ
高スループットのストリームを処理