WebSocketクライアントを使用した一時メッセージキューサブスクリプションのアーキテクチャパターン
一時的なWebSocketクライアントで使用したいイベントストリームにはGooglePub/Subを使用します。クライアントが接続されなくなったときにサブスクリプションを作成してクリーンアップするための適切なパターンは何ですか？主な使用例は、データ変更イベントに基づいてリアルタイムで表示を更新する管理ポータルです。
最初の考え：
- クライアントはシャットダウン時に自分自身の後に確実にクリーンアップしないため、クライアントが消えたときにサブスクリプションを外部からクリーンアップする必要があります
- 各サーバーノードは、起動時にトピックサブスクリプションを作成し、関心のあるクライアントにメッセージを再ブロードキャストできますが、2番目の部分は、新しいメッセージキューを構築するようなものです。
- （2）の場合、サブスクリプションを削除せずにノードがクラッシュすると、クリーンアップの問題が発生します（ただし、各WebSocketクライアントのサブスクリプションを作成するよりもはるかに少ないです）
この問題を解決する一般的なアーキテクチャパターン（または既存のプロジェクト）はありますか？
誰かがこれに遭遇した場合、私が見つけた最も簡単な答えは、WebSocketクライアントにRedis Pub/Subを使用することです。 Redisには永続的なサブスクリプションや保証された配信がないため、より信頼性の高いGoogle Pub/Subにサブスクライブし、特定のトピックをRedis Pub/Subに挿入するクライアントがいます。 WebSocketクライアントはRedis経由でサブスクライブし、その時点から送信されたメッセージのみを取得し（バックログなし）、切断後のクリーンアップのサブスクリプションはありません。まさに私が探していた行動。