20 Coherenceトピックの概要
この章の内容は次のとおりです。
トピックの概要
1つ以上のパブリッシャがトピックに値のストリームをパブリッシュします。1つまたは複数のサブスクライバが、トピックへの値のストリームを消費します。トピック値はすべてのOracle Coherenceデータ・サーバーに均等に分散されており、分散形式およびフォルト・トレラント形式での高スループット処理が可能です。トピックに対する各直接サブスクライバは、トピックにパブリッシュされたすべての値を受信します。
図20-1 トピック値
パブリッシュおよびサブスクライブ・メッセージングでは、メッセージはトピックのアクティブ・サブスクライバにのみ配信されます。サブスクライバ・グループは、トピックにキュー処理機能を追加します。トピックでサブスクライバ・グループを作成すると、トピックに送信される値はすべてサブスクライバ・グループに蓄積されます。1つ以上のサブスクライバがサブスクライバ・グループをサブスクライブできます。サブスクライバ・グループによって蓄積された値のストリームの場合、各値はサブスクライバ・グループ・メンバーの1つに対してのみ配信されるので、これらの値の分散パラレル処理が可能になります。
ノート:
基本的なトピック操作の例は、「基本的なトピック・パブリッシュおよびサブスクライブ操作の実行」を参照してください。図20-2 サブスクライバ・グループ内のトピック値
チャネルについて
パブリッシャは、サブスクライバが受信したときにパブリッシュするメッセージに対して存在する順序付け保証を制御するように構成されています。これを実現するには、メッセージを特定のチャネルにパブリッシュします。チャネルにパブリッシュされたすべてのメッセージは、パブリッシャがそのチャネルにパブリッシュした順序でサブスクライバによって受信されます。異なるパブリッシャによってチャネルにパブリッシュされたメッセージは、交互に配置されることがあります。異なるパブリッシャ間で順序付け保証はありません。異なるチャネルにパブリッシュされたメッセージは、サブスクライバが受信する際に交互に配置されることがあり、サブスクライバ・グループ内の異なるサブスクライバが受信することがあります。
トピックが持つチャネルの数により、パブリッシャは、多くのパブリッシャが1つのチャネルにパブリッシュすることで発生する可能性のある競合を回避できるため、より適切にスケーリングできます。複数のサブスクライバ(グループ内)が異なるチャネルにサブスクライブするため、メッセージの消費をスケーリングできます。したがって、順序を維持しながらメッセージの受信をスケール・アップできます。
同じサブスクライバ・グループに新しいサブスクライバが作成されると、使用可能なチャネルは、サブスクライバ間で可能なかぎり公平に割り当てられます。チャネルよりも多くのサブスクライバがある場合、一部のサブスクライバにはチャネルが割り当てられず、メッセージを受信しません。障害やハートビート・タイムアウトなど、なんらかの理由でサブスクライバが切断した場合、割り当てられたチャネルが残りのサブスクライバに再割当てされます。チャネル割当ての変更を通知するリスナーを登録できます。
トピックのチャネル数は構成可能で、理想的には小さな素数(デフォルトは17)です。アプリケーションのユース・ケース、および必要なスケーリングや順序付け保証の種類に応じて、チャネル数が非常に少ない場合と非常に多い場合の長所と短所があります。
ポジションについて
NamedTopic実装によって使用される不透明なデータ構造です。
ポジションは、サブスクライバが受信した要素を追跡する場合、ポジションのコミット時に先行するどの要素がコミットされるかを判断する場合、サブスクライバが再接続または障害からリカバリする際にトピック内の正しいポジションにリカバリする場合に使用されます。
ポジション・データ構造は不透明ですが、シリアライズが可能です。つまり、メッセージ要素の処理を手動で追跡するアプリケーション・コードごとに、別のデータ・ストアに格納できます。チャネルとポジションの組合せは、パブリッシュおよび受信されるメッセージ要素ごとに一意である必要があります。
トピックのリジリエンスと可用性
クラスタ・メンバーでは、トピックは非常に回復力に優れ、クラスタ・メンバーのローリング・アップグレード中に引き続き機能します。
トピックAPIは通常非同期であるため、トピックにパブリッシュまたはサブスクライブするAPIメソッドは引き続き機能しますが、完了には時間がかかります。パブリッシュおよびサブスクライブ操作はストレージ・メンバーの再起動まで一時停止するため、クラスタ・メンバーに対するパブリッシュおよびサブスクライブは、すべてのストレージ対応メンバーが失われても存続できます。
ExtendまたはgRPCクライアントでは、キャッシュと同様に、クライアントは接続されているプロキシが停止した場合、またはネットワークの問題などの他の理由で切断された場合、再接続します。これは通常、クライアントがプロキシに再接続できるかぎり、トピック操作が機能することを意味します。パブリッシャおよびサブスクライバは、非同期コールのバックグラウンドでの接続を試行するため、通常、これらも成功します。スローされる問題や例外は、プロキシ接続が失敗したときに、リクエストが実際に処理中である場合です。この場合、キャッシュと同様に、コール元は例外を受け取りますが、操作はクラスタ上でまだ実行中であり、実際に完了する場合があります。たとえば、パブリッシャの場合、クライアントは例外を受信し、クラスタでパブリッシュ・リクエストが実際に成功したかどうかを認識していない場合があります。非同期トピックAPIコールから返されたCompletableFutureを適切に処理し、エラーに対して実行するアクションを決定するのは、アプリケーション・コードによって異なります。