个人猜想的方案

まず第一に、セッションとクッキーの違いを明確にする必要があります。ブラウザ側は Cookie を保存し、ブラウザがサーバーにリクエストを送信するたびに、HTTP ヘッダーに Cookie 情報が自動的に追加されます。サーバーはユーザーの Cookie をキーとして使用して、ストレージ内の対応する値 (セッション) を見つけます。

同じドメイン名のウェブサイトには同じ Cookie があります。したがって、サーバーがいくつあっても、ルートレスリクエストがどのサーバーに振り分けられるかというと、同じユーザーのCookieは
変化しません。つまり、Cookie に対応するセッションもユニークです。

複数のビジネスサーバーが同じ Redis サーバー (またはクラスター) にアクセスしていることを確認してください。 これで目標は達成されます。したがって、あなたの計画 2 は正しいです

共有されるため、もちろん同じ Redis に保存する必要があります。これが 2 番目のオプションです。

Redis を使用してセッションを共有する 重要なのは、セッションが Redis 上にデプロイされ、Redis に保存されることです。セッション ファイルはローカルにデプロイされなくなります。

Redis を使用してセッションを共有することは、基本的に Redis のインスタンスが 1 つだけであることを意味しますが、このインスタンスが Redis サービスを開始するだけなのか、複数のサーバーに Redis クラスターをデプロイするのかは、アプリケーション層とは何の関係もありません。

高い信頼性要件を持つアプリケーションの場合、前述のソリューション 1 と同様に、Redis をクラスターにデプロイする必要がありますが、これらの Redis 間には、シャーディングや冗長ストレージなどを実現するための対応する内部通信メカニズムが存在します。アクセスするときに Redis の場所を制限する必要はありません。たとえば、サーバー A 上の B 上の Redis にアクセスでき、B 上の Redis の実際のデータ ストレージはサーバー C にある可能性があります。アプリケーションではこれはすべて問題ありません (クライアント）これはブラックボックスなので、気にする必要はありません。

php.ini にはセッション設定が含まれています。構成を Redis または memcache に変更すれば、他は何も心配する必要はありません

個人的には、セッションの共有はデータを共有するという概念に過ぎないと感じていますが、セッション内に本来保存する必要があるデータは、保存のためにredisに移行されます。 もちろん、セッションと同様に固有のセッションIDを生成する必要もあります。それをクライアントに渡して Cookie に保存します。クライアントはリクエストを行うたびに、変更した Cookie を一緒に送信し、対応するデータを Redis から取得する必要があります。
実際、共有セッションに関しては、実際には単なる共有キャッシュです。

もちろん、私は概念について話しています。おそらく、サーバー上の実際のセッションを直接redisに保存できるツールがあるかもしれませんが、概念は次のようなものだと思います。

実際、上記の解決策は両方とも実現可能です。まず、最初の解決策は、サービスの安定性とパフォーマンスを向上させ、セッション キャッシュ データの損失につながる可能性がある単一障害点を回避するために Redis クラスターを構築できます。 。 2 番目のオプションは、追加のマシンで Redis サービスを開くことです。サービスの安定性を向上させるために、マスター/スレーブ サービスを構築できます。 Cookie とセッションは、redis の Key-Value に似ています