あなたの元のアイデアは、一時的なサブスクリプションよりも優れていたと思います。うまくいくという意味ですが、まったく不自然に感じます。あなたの要件が何であるかに応じて。たとえば、クライアントは接続中にメッセージを受信するだけでよいのでしょうか?それとも、すべてのクライアントがすべてのメッセージを取得する必要があるのでしょうか?
接続中のみ
あなたの元のアイデアはもっと良かったです。私ならおそらく、クライアントが接続できる gRPC ストリーム サービスを作成することになるでしょう。実装は基本的にオブザーバー パターンです。コンシューマーはメッセージを受信し、サブスクライバーを繰り返し処理して、すべてのサブスクライバーに「送信」を行います。そこから、クライアントがサービスに接続するたびに、そのオブザーバー コレクションに自分自身を登録し、切断すると登録を解除します。クライアントは接続先のインスタンスに固執するため、水平方向のスケーリングは受動的です。
最終的には、誰もが常にメッセージを受け取ります
概念は上記と似ていますが、クライアントは切断時にオブザーバーから暗黙的に登録解除しません。代わりに、(そのように設計されたメソッド/コマンドを介して) 明示的に登録および登録解除します。「切断時」ロジックを変更して、クライアントがオフラインになったことをオブザーバー リストに通知します。次に、コンシューマのブロードキャスト ロジックは少し異なります。リストを繰り返し処理し、「オンラインの場合は送信、そうでない場合はキュー」と言って、メッセージを一時的なキュー (クライアントに属する) に送信します。次に、「接続時」ロジックは、オンラインに戻ったことを消費者に通知する前に、キューにあるすべてのメッセージをクライアントに送信します。基本的に受信箱。RabbitMQ のようなほとんどの製品では、一時的な自己削除キューの設定は非常に簡単です。私はあなたを思う' ただし、キューを削除してもよいかどうかを少し管理する必要があります。たとえば、クライアントが明示的にサブスクライブを解除するか、長い間非アクティブでない限り、キューを削除しないでください。それを怠ると、受信トレイのアイデア全体が崩壊します。
上記の選択された回答は、サブスクリプションがキューであるという点で、ここでサブスクライブしているものに最も似ています。私がこれを行った場合、おそらくオブザーバーではなく内部バスとして実装します（不要になるため）-文字通りメッセージを転送する接続クライアントのオンデマンドでコンシューマーを作成します。メッセージ コンシューマは、クライアントが接続されているかどうかに基づいて、サブスクライブおよびサブスクライブ解除します。Kamal が指摘したように、スケールが pubsub で許可されているサブスクリプションの最大数を超えると、問題が発生します。自分がその立場にあることに気付いた場合は、上記のパターンを実装することでその制約を解くことができます。これは基本的に同じパターンですが、唯一の制約が自分のリソースであるインフラに責任を移します。
gRPC を使用すると、このメカニズムが非常に簡単になります。または、Web の場合、Microsoft スタックを使用している場合は、SignalR を使用するとこれも非常に簡単になります。クライアントはハブに接続し、接続されているすべてのクライアントに公開できます。ここでのコンシューマー パターンはほとんど同じままですが、オブザーバー パターンを手動で実装する必要はありません。
(注: 図の矢印は、データ フローではなく、依存関係の方向です)