PHP 複数サーバーのクロスドメイン SESSION 共有

ウェブサイトのビジネス規模と訪問者数が徐々に発展するにつれて、単一サーバーと単一ドメイン名の元のミニウェブサイト構造では開発ニーズを満たすことができなくなりました。

現時点では、より多くのサーバーを購入し、チャネル化された方法で複数の第 2 レベルのサブドメインを有効にして、ビジネス機能に応じて Web サイトを独立したサーバーに分散および展開するか、負荷分散テクノロジー (DNS ポーリング、Radware、F5 など) を使用する可能性があります。 、LVS など）を使用すると、複数のチャネルが単一のサーバー セットを共有できます。

OK、私たちはすでにそのような解決策を頭の中で考えていますが、詳細な開発に入った後、新たな技術的問題が発生します:

Webサイトのプログラムを複数のサーバーに分散・展開し、実装原理によりセッションが制限されるため（PHPのセッションはサーバーのハードディスク上にファイルの形で保存されます）、独立して複数の第2レベルのドメイン名に分割します。デフォルトではローカルサーバー）、当社のWebサイトでは、ユーザーはログインするために複数のチャネル間でユーザー名とパスワードを行き来する必要があることが多く、これによりユーザーエクスペリエンスが大幅に低下します。また、元のプログラムはデータ（ニックネーム、ポイントなど）を直接読み取ることができます。セッション変数はサーバー間で同期的に更新できないため、開発者はリアルタイムでデータベースの読み取りと書き込みを行う必要があり、データベースへの負担が増加します。

その結果、クロスサーバー Web サイト間のセッション共有の問題を解決する必要性が緊急になり、最終的には比較と議論のためにさらに 4 つの実現可能なソリューションが生まれました。

1. NFSに基づくセッション共有

NFSはNet FileSystemの略称で、Unixネットワークホスト間のディレクトリ共有の問題を解決するためにSunによって最初に開発されました。

このソリューションは実装が最も簡単ですが、二次開発をあまり必要とせず、共有ディレクトリ サーバーを各チャネル サーバーのローカル セッション ディレクトリにマウントするだけで済みます。欠点は、NFS が複雑なセキュリティ メカニズムとファイル システムに依存していることです。特に同時読み取りと書き込みが多いセッションなどの小さなファイルの場合、共有ディレクトリ サーバーの io-wait が高くなりすぎ、最終的にフロントエンド WEB アプリケーションの実行効率が低下します。 。

2.データベースベースのセッション共有

最初の選択肢はもちろん有名な Mysql データベースですが、セッション操作の読み書き効率を向上させるためにメモリ テーブル ヒープを使用することをお勧めします。このソリューションは非常に実用的であり、誰もが一般的に使用していると思いますが、その欠点は、セッションの同時読み取りおよび書き込み機能が MySQL データベースのパフォーマンスに依存すると同時に、セッション削除ロジックを実装する必要があることです。データ テーブルのセッション レコードを定期的に更新したり削除したりするには、同時実行性が高すぎるとテーブル ロックが発生する傾向がありますが、行レベルのロックを備えたテーブル エンジンを選択することはできますが、データベースを使用することは拒否する必要があります。 Store Sessions はまだ少しやりすぎです。

3. Cookieベースのセッション共有

私たちはこのソリューションに馴染みがないかもしれませんが、大規模なウェブサイトでは今でも一般的に使用されています。原則として、サイトのすべてのユーザーのセッション情報を暗号化してシリアル化し、それを Cookie として使用して、ブラウザを使用してすべての秒にアクセスするときにルート ドメイン名 (.host.com など) の下に均一に埋め込みます。ルート ドメイン名の下にあるレベルのドメイン名サイトでは、ドメイン名に対応するすべての Cookie コンテンツの特性が渡されるため、複数のサービス間でユーザーの Cookie ベースのセッションへの共有アクセスが実現されます。

このソリューションの利点は、追加のサーバー リソースを必要としないことですが、欠点は、http プロトコル ヘッダーの信頼性の長さの制限により、クッキー化されたユーザー情報のごく一部しか保存できないことです。セッション コンテンツは、安全に暗号化および復号化する必要があります (平文の暗号化と復号化に DES、RSA などを使用し、偽造防止認証に MD5、SHA-1 などのアルゴリズムを使用するなど)。ブラウザは、サーバーに渡された現在のドメイン名でリソースを要求するときに、ローカル Cookie を http ヘッダーに添付するため、一定量の帯域幅リソースが必要になります。

4. Memcacheに基づくセッション共有

Memcache は、Libevent マルチチャネル非同期 I/O テクノロジーに基づいたメモリ共有システムであるため、シンプルな Key + Value データ ストレージ モードにより、コード ロジックがコンパクトかつ効率的になるため、同時処理能力において絶対的な利点があります。これまでの経験 プロジェクトの平均クエリ レートは 2000/秒に達していますが、サーバーの CPU 消費量は依然として 10% 未満です。

また、Memcache のメモリ ハッシュ テーブルに固有の Expires データの有効期限と削除のメカニズムは、セッションの有効期限のメカニズムと一致しており、「データベース ベースのストレージ ソリューション」と比較して、期限切れのセッション データを削除するコードの複雑さが軽減されることにも言及する価値があります。それだけでも、データテーブルに多大なクエリプレッシャーが発生します。

これらのソリューションの中でもMemcacheベースのストレージがおすすめです！

他のソリューションにもまだ用途があります。どれを選択するかは、現在のサーバー リソース、Web サイトの同時実行圧力などに基づいて、開発者による総合的な評価が必要です。