ロードバランシング、セッションホールド、セッション同期

ナイフが飛んでいる · 掲載地 2015/05/14 0:16:44

1. ロードバランシングとは何か
新しいウェブサイトはトラフィック量が少ないため、ロードバランスを取るべきではありません。そうした作業は不要です。しかし、ウェブサイトのトラフィックとトラフィックの急速な増加により、単一のサーバーはハードウェア条件に制限されており、これほど多くの訪問に耐えるのは困難です。この場合、選択肢は2つあります:
1. シングルサーバーのハードウェアをデュアルコアからクアッドコアに更新し、メモリを増やすなど。
2. サーバーの負担を分担するためにサーバー数を増やすこと。ネットワーク帯域幅の増加とサーバーの処理能力の向上という目的を達成すること。
最初の方法は垂直展開と理解でき、常に制限があります。 2つ目の方法は問題解決に正しい選択です
負荷分散の方法は大きく分けて二つの方向に分けられます。一つはソフトウェアを使って負荷分散を実現する方法、もう一つはハードウェア負荷分散(ハードウェアとソフトウェアを組み合わせるを含む)を実装することです
ソフトウェアを使って負荷分散を実現し、その過程でシステムリソースの一部が消費され、応答時間も増加します。例えば、LVS、nginx、haproxy、apacheなど、これらのアプリケーションベースのロードバランシングソフトウェアは、特に訪問者数が少ないウェブサイトに適しています。 sinaや163のように訪問数が多いウェブサイトの場合、ハードウェアを使ってロードバランシングを実装するのが最も明白な選択肢です。
リクエスト数、ルートIPアドレス、トラフィックベースのアルゴリズムなど、多くの負荷分散アルゴリズムがあります。私がよく使うアルゴリズムは2つあります。
1つはリクエスト数に基づいています
A、各サーバーが顧客のリクエストを均等に共有できることを認識でき、もしサーバーがダウンしても悪影響は及ばないことを認識できます。
b. サーバー間の状態はセッションのように同期されなければならず、これらの状態を同期させるための他の手段が必要です。
一つは知的財産によるものだ
A、ip_hashアルゴリズムはIPをサーバーにマッピングでき、セッション同期の問題を解決できます
b. ip_hashの悪い点は、サーバーの一つがダウンすると、そのサーバーに割り当てられたユーザーが落ち込むことです。
c、ip_hashは簡単に負荷のバランスを崩す原因になり得ます。今や川クラブ政府がGoogleの検索キーワードをフィルタリングしているので、Googleが開けないことがよくわかりますが、しばらくすれば問題なくなります。これによりGoogleの熱狂的な支持者たちは落胆し、多くのユーザーが海外でエージェントを探しに行きました。もしそうなると、これらのプロキシは同じサーバーに割り当てられ、負荷のバランスが崩れ、時には障害が発生することもあります。

次に、セッションホールディングとは何か、そしてその機能は何かということです
セッションホールドとは、ロードバランサー上の機構で、同じユーザーに関連付けられたアクセスリクエストが同じサーバーに分散されるようにする仕組みのことです。
セッションホールドは何をするのか、例を挙げてください
もしユーザーアクセスリクエストがサーバーAに割り当てられ、サーバーAにログインし、短時間でこのユーザーが別のリクエストを送った場合、セッションホールド機能がなければ、そのユーザーのリクエストはサーバーBに割り当てられる可能性が高いです。この時点でサーバーBにログインがないため、再度ログインしなければなりませんが、ユーザーは自分のリクエストがどこに割り当てられているか分からず、ユーザーの感覚は「ログインしているのに、なぜまたログインしなければならないのか」というもので、ユーザー体験は非常に悪いです。
また、Taobaoで何かを購入する場合、ログイン=「何かを撃つ=」 add address = 「支払う」から、これは一連のプロセスであり、操作プロセスとも理解できます。これらの一連の操作プロセスは1台のサーバーで完了し、ロードバランサーによって異なるサーバーに割り当てることはできません。
セッションホールドには時間制限があります(ip_hashのように固定されたサーバーは除きます)。様々なロードバランシングツールがこのセッションホールド時間設定、LVS、Apacheなどを提供します。 PHP言語もセッションホールド時間を設定するsession.gc_maxlifetimeを提供しています
セッション保持時間はセッション生存時間よりも長く設定すべきであり、これにより同期の必要性を減らすことができますが、完全には排除できません。したがって、同期セッションは依然として行う必要があります。

第三に、セッション同期
なぜセッション同期が必要なのか、セッションキーピングについて話すときに言及されています。詳細については、「Webクラスターにおける3つのセッション同期方法」をご覧ください

ウェブクラスタにおけるセッション同期には3つの方法があります

ウェブクラスタを導入した後は、まずセッション同期を検討してください。なぜなら、ロードバランシングの後、同じページのIPアクセスが異なるサーバーに割り当てられるからです。この記事では、この状況に応じてこの問題を解決する3つの異なる方法を紹介します。
まず、データベースを使ってセッションを同期します
マルチサーバーセッション同期の際にはこの方法は使わなかったが、もし使わなければならないなら、2つの方法を考えた。
1. 低価格コンピュータを使ってウェブサーバーのセッションを保存するデータベースを構築するか、この特別なデータベースをファイルサーバーに構築します。ユーザーがウェブサーバーにアクセスすると、セッションの状況を確認するためにこの特別なデータベースにアクセスし、セッション同期の目的を達成します。
2. この方法は、セッションが格納されるテーブルを他のデータベーステーブルと同時に配置することです。もしmysqlもクラスタ化されている場合、各mysqlノードにこのテーブルが必要であり、このセッションテーブルのデータテーブルはリアルタイムで同期されなければなりません。
説明:セッションを同期するためにデータベースを使うと、ボトルネックが発生しやすいデータベースへの負担が増えます。上記の2つの方法のうち最初の方がより優れており、セッションが独立に配置されるテーブルを分離し、実際のデータベースへの負担を軽減します
2. セッションの同期にクッキーを使う
セッションはサーバー側に保存されるファイル状況で、クッキーはクライアント側のファイル状況です。同期はどうやって実現するのでしょうか? この方法は非常にシンプルで、ユーザーの訪問ページから生成されたセッションをクッキーに取り込み、クッキーを中継局として使う方法です。あなたはウェブサーバーAにアクセスし、セッションを生成してクッキーに入力します。アクセス権はウェブサーバーBに割り当てられます。この時点で、ウェブサーバーBがまずサーバーにこのセッションがあるかどうかを判断します。持っていなければクライアントのクッキーにセッションがあるか確認します。もし存在しなければ、そのセッションは本当に保存されていないことを意味します。クッキー内のセッソインをウェブサーバーBに同期させ、セッションを同期させます。
注意:この方法は実装が簡単で便利であり、データベースへの負担を増やすことはありませんが、クライアントがクッキーを無効にするとセッションが同期できず、ウェブサイトに損失が生じます。クッキーは高度に安全ではなく、暗号化されているものの偽造される可能性があります。

3. セッション同期のためにmemcacheを使用する
Memcacheは分散可能であり、この機能がなければセッション同期には使えません。彼はウェブサーバー内のメモリを組み合わせて「メンプール」にすることができ、どのサーバーがセッソインを生成しても、そのメモリをこの「メンプール」に入れ、その他すべてを使えます。
利点:このようにセッションを同期してもデータベースの負担が増えず、クッキー使用と比べてセキュリティが大幅に向上し、メモリにセッションを格納する方がファイルから読み取るよりもはるかに高速です。
欠点:メモリを多くのストレージブロックの仕様に分割します。ブロックやサイズがあります。この方法ではメモリを完全に活用できず、メモリ断片化を生じます。ストレージブロックが不足するとメモリオーバーフローも発生します。

第四に、概要
上記の3つの方法すべてが実現可能です
システムの速度に最も影響を与える最初の方法は推奨されません。
2つ目の方法は良い結果を得ますが、安全上の危険は同じです。
三つ目の方法は、個人的には三つ目の方法が一番だと思います。皆さんにおすすめします。

ロードバランシング、セッションホールド、セッション同期

閲覧したセクション