ストリーム上の通信は非同期かつ双方向です。 クライアントは各レコードの確認を待たずに連続的にプッシュし、サーバーはレコードが持続性を持つようになると同じ接続で確認応答を返します。 このデカップリングが、単一のクライアントが高スループットを維持できるようにしています。確認応答がバックグラウンドで届く間も、クライアントはプッシュを続けます。
オフセットと確認応答ループ
ストリーム上のすべての送信は、単一レコードでもバッチでも、そのストリーム内での位置を示す論理的なオフセットが割り当てられます。 サーバーは各投稿を個別に確認するのではなく、これまでに耐久化した最大コミットオフセットまでの累積耐久度の進行状況を報告します。 オフセットは順序付けられているため、1つの確認応答で、その送信とそれ以前のすべての送信が確認されます。
これが確認応答ループであり、接続を高速かつ信頼性に保つものです:
- クライアントはレコードをプッシュし、ローカルのインフライトバッファに保持します。
- サーバーはレコードを永続化し、最も高いコミットオフセットを定期的に返送します。
- そのオフセットを受け取ると、クライアントはそのオフセットまでのバッファされたレコードをすべて安全に削除します。なぜなら、それらのレコードは今や耐久的だからです。
Zerobus Ingest SDKを使うと、SDKがこのループを実行してくれます。 オフセットを追跡し、オンフライトバッファを維持し、プロデューサーがプッシュを続ける間にバックグラウンドで確認応答を処理します。 ループを自分で実装するわけではありません。 オプションでコントロールできるのは耐久性の観察方法です:
- 送り続けてください;SDKは到着した確認応答を処理します。
- 特定のレコードが永続化されるまでアプリケーションが待機する必要がある場合にのみ、オフセットでブロックしてください。 以下を参照してください。
- 確認やエラーに対して非同期で応答するための確認コールバックを登録し、ブロックを避けましょう。 確認応答コールバックを参照してください。
オフセット追跡とバッファリングのループを自分で実装する必要があるのは、SDKを使用しないカスタムクライアントを構築する場合のみです。
飛行中バッファは設定可能な飛行中レコードの制限によって制限されています。 バッファがいっぱいになるまでは、取り込みは非同期で行われます。その時点に達すると、確認応答が届いて空き領域ができるまで、インジェスト呼び出しはブロックされます。 ワークロードの上限を調整し、バッファされたレコードはフライト中にクライアントのメモリを消費することに注意してください。 オプションおよびそのデフォルトについては 、Zerobus SDKリポジトリをご覧ください。
接続が中断された場合、インフライトバッファ内のレコード(最後にコミットされたオフセットを超えたもの)は持続性が確認されていないため、再プレイが可能です。 回復 と再挑戦のパターンを参照してください。
確認応答は永続性を示すものであり、クエリ可能性を示すものではありません。 コミットされたオフセットとは、それらの記録が持続的に保存され、失われないことを意味します。 Zerobus Ingestは、直後に耐久的記録を別のステップとしてデルタテーブルに具現化し、その時点で約5秒でデータがクエリ可能になります。 レイテンシーの詳細については、 レイテンシーをご覧ください。
レコード待ちとスループット最大化
アプリケーションが、その特定のレコードが確実に永続化されたと分かるまでそれ以上の処理をブロックしなければならない場合は、そのレコードのオフセットについて待機します。たとえば、上流システムに作業完了を通知する前などです。 待つことはアプリケーションレベルの同期に関するものであり、耐久性の要件ではありません。 レコードは、それに対してブロックするかどうかにかかわらず、確認応答ループを通じて永続化されます。
ブロッキングにはスループットコストがあります:
- 各レコードのたびに待機すると、データ取り込みは実質的に同期的なワークフローになってしまいます。 各メッセージをブロックしてから次のメッセージを送信すると、クライアントはZerobus Ingestのフルスループットに達することができなくなります。
- ハイスループットのインジェストは連続的かつ非同期です。 クライアントは、過去のレコードのグループに対して確認応答が届く間にレコードを送り続け、各レコードで一時停止することはありません。 アプリケーションが本当に保証を必要とするチェックポイントでのみ特定のオフセットを待つか、確認コール バック を使って進行状況をブロックせずに追跡しましょう。
取り込み方法、オフセットでブロックするタイミング、確認応答コールバックの仕組みについては、「 メッセージブロックと確認応答」を参照してください。
ストリームでの注文
確認応答とオフセットはストリームごとに割り当てられており、順序付けは単一のストリーム内で保証されており、ストリーム全体にわたって保証されるわけではありません。 ストリームごとの注文がどのように機能し、それに合わせた設計方法については 「注文保証」を参照してください。