PHPセッション共有のある複数のサーバー
これについては他にも確かに他のスレッドがありますが、もう1つ質問があります。
複数のサーバーを持つように、作業中のWebサイトを拡張しようとしています。そして、サーバー間でセッションを共有する必要があります。
私たちはさまざまなソリューションを検討してきました。1つはmemcachedで、MemcachedをPHPのセッションハンドラーとして使用します。それはおそらくうまくいくでしょう。
そして、すべてのマシンでmemcachedを実行し、すべてのWebサーバーが他のすべてのサーバーのmemcachedサーバーにアクセスできるようにするというアイデアです。そうすれば、マシン間でセッションを共有できます。 （スティッキーセッションでセットアップするリソースはまだありません。これは後のプロジェクトです。これを実行する必要があり、今すぐ実行する必要があります。スターターとしてDNSを使用して負荷分散します）
しかし、その後...たとえば、メンテナンスのために1台のサーバーを停止したい場合、サーバーがクラッシュした場合、またはその他の理由で。ユーザーがセッションを失うだけで最初からやり直さなければならないのは望ましくありません...そのため、Memcachedがサポートしていない何らかのレプリケーションが必要です。
それから私は http://repcached.lab.klab.org/ -memcachedのマルチマスターレプリケーションを持っていることを見つけました。これは素晴らしいことであり、私が欲しいものです。しかし、2台以上のマシンで動作しますか？ 3、5、10と言いますか？将来のスケーリングのために。
また、redisを調べました http://redis.io/ -これも素晴らしいようですが、php-session-handlerのサポートがあり、マルチマスターがないため、少し「不安定」です-レプリケーション。
Memcachedを使用するのが好きですが、セッションの半分を失うことなく、2つのボックスのうちの1つをパワーダウンできるようにしたいのです。助言がありますか？
MemcacheAPIを使用してレプリケートされたキーストアを実装するcouchdbを確認することをお勧めします。また、ほとんどのmemcache実装よりも適切にメモリストレージのオーバーフローを処理します（フェイルオーバー中に発生する可能性があります）。レプリケーションの実装方法の詳細に精通していないことを認めなければなりません。
私が見た「スティッキー」セッションのすべての実装は、リクエストを明示的なデバイスにバインドします-これは適切なフェイルオーバーにはなりません-そしてPHPセッションアフィニティはストレージサブストレートにのみ関連します（通常はロジック層にある必要があるJavaとは異なります）。したがって、HTTP層でスティッキーセッションを使用することは関係ありません。
確かに、サブストレートで非同期MySQLレプリケーションを使用することは、レプリケーションの遅延とシングルスレッド書き込み操作のために簡単ではありません-これに対処するためにPHP（フェイルオーバー中に設定とブロックを実装する）で接続ブローカーを使用します。 MySQLはセッション処理の最も効率的なソリューションではありませんが、アプリケーションがすでに高可用性のリレーショナルデータベースに依存している場合は、それをセッションストレージに使用することは非常に理にかなっています。MySQLにはマルチマスターレプリケーションの実装があります。例：Percona。
MongoDBも非同期レプリケーションを使用しますが、MySQLのシングルスレッド依存関係はありません。
ノードをどのようにフェンスするかについて考えるのに少し時間を費やす必要があります。仮想アドレスの乗っ取り（正しく実装されている場合）は操作を透過的にする必要がありますが、IMEを正しく実行するのは難しい場合があり、フェイルオーバー中の大きな一時停止を回避するために、arpアドレスとIPアドレスを乗っ取る必要があります。
3、5、10と言いますか？将来のスケーリングのために
この程度まで拡張することを計画している場合は、おそらく複数のデータセンターについて検討する必要があります。これは、共有ファイルシステムではなく、低帯域幅/高遅延に対応できる同期方法を意味します。
Memcachedの代わりに データベースセッションハンドラー をお勧めします。とにかくデータベースを使用している可能性があります。データベースがダウンしている場合はサイトもダウンしているため、新しい障害モードを追加しません。
Memcachedはフェイルオーバーを処理しません。システム内のこのような複数のマスター環境でのキャッシュの無効化は、遅くて複雑（同期）または信頼性が低い（非同期）かのいずれかです。したがって、あるサーバーにセッション変数を設定し、次のリクエストがこの変数の古い値を持つ別のサーバーに送信される状況が発生します。