Webクラスター負荷分散ソリューション-セッションの永続性
1.基本的な考え方
1.セッションとは何ですか？
セッションはネットワークでは「セッション」と呼ばれる必要があり、サーバーとクライアントシステム間の必要な相互作用を提供できます。HTTPプロトコル自体はステートレスであるため、Sessionを介してサーバーとブラウザーの間で状態を維持するためのソリューションを提供する必要があることがよくあります。セッションは、アプリケーションサーバーによって維持されるサーバー側のストレージスペースです。ユーザーがサーバーに接続すると、サーバーは一意のSessionIDを生成します。これは、サーバー側のセッションストレージスペースにアクセスするための識別子として使用されます。
SessionIDのデータはCookieを使用してクライアントに保存されます。ユーザーがページを送信すると、SessionIDがサーバーに送信されてSessionデータにアクセスします。サーバーはまた、URL書き換えを通じてSessionID値を渡すため、Cookieに完全に依存しているわけではありません。クライアント側のCookieが無効になっている場合、サーバーはURLを書き換えることでセッション値を自動的に保存でき、このプロセスはプログラマーに対して透過的です。
2.セッション共有とは何ですか？
ウェブサイトビジネスの規模と訪問数が徐々に増加すると、単一のサーバーと単一のドメイン名で構成される元のミニサイト構造は、開発ニーズを満たさなくなる可能性があります。
現時点では、サーバーを追加購入し、チャネル化された方法で複数の第2レベルのサブドメインを有効にしてから、ビジネス機能に応じて、または負荷分散テクノロジー（Haproxy、Nginxなど）を介してWebサイトを別々のサーバーに展開する場合があります））チャネルはサーバーのセットを共有します。
セッションの実装原則の制限により、Webサイトプログラムを複数のサーバーに個別に展開し、それらをいくつかの第2レベルのドメイン名に分割する場合（PHPのセッションはハードディスクにファイルの形式で保存されます）その結果、Webサイトのユーザーは、ログインするために複数のチャネル間でユーザー名とパスワードを入力する必要があり、ユーザーエクスペリエンスが大幅に低下します。さらに、元のプログラムはユーザーのセッション変数（ニックネーム、ポイント、ログイン時間など）からデータを直接読み取ることができます。これは、セッション変数をサーバー間で同期的に更新できないため、開発者はデータベースを実際に読み書きする必要があるためです。時間、それによってデータベースの負担が増加します。その結果、ウェブサイトのサーバー間セッション共有の問題を解決する必要性がますます緊急になり、最終的にさまざまな解決策が生まれました。比較と議論のためのさらに4つの実行可能な解決策を次に示します。
1.Cookieベースのセッション共有
読者はこのスキームに慣れていないかもしれませんが、大規模なWebサイトで一般的に使用されています。原則として、サイト上のすべてのユーザーのセッション情報を暗号化し、シリアル化後にCookieの形式でルートドメイン名（.host.comなど）で植え付けます。
ブラウザがルートドメイン名ですべてのセカンドレベルドメインサイトにアクセスすると、ドメイン名に対応するCookieコンテンツのすべての特性がブラウザに渡され、複数のサービス間でのユーザーのCookieセッションの共有アクセスが実現されます。 。
このスキームの利点は、追加のサーバーリソースが必要ないことです。欠点は、HTTPプロトコルヘッダーの長さの制限により、ユーザー情報のごく一部しか保存できないことです。同時に、コンテンツCookie化されたセッションの一部を暗号化および復号化する必要があります（DES、RSAなどを使用）。プレーンテキストの暗号化と復号化、MD5、SHA-1、およびその他の偽造防止認証のアルゴリズムを実行します。さらに、ブラウザはローカルCookieをHTTPヘッダーに添付し、現在のドメイン名でリソースを要求するときにサーバーに渡すため、一定量の帯域幅リソースも消費します。
2.データベースに基づくセッション共有
もちろん、最初の選択肢はMySQLデータベースであり、セッション操作の読み取りと書き込みの効率を向上させるために、メモリテーブルヒープを使用することをお勧めします。このソリューションは実用性が高く、誰もが広く使用していますが、セッションの同時読み取りおよび書き込み機能がMySQLデータベースのパフォーマンスに依存するという欠点があります。同時に、セッション除去ロジックを自分で実装する必要があります。データテーブルから定期的に更新するため。セッションレコードを削除すると、同時実行性が高すぎると、テーブルロックが表示されやすくなります。行レベルのロックを備えたテーブルエンジンを選択できますが、データベースを使用して保存することを認める必要があります。セッションはまだ少しやり過ぎです。
3.セッションコピー
TomcatまたはWeblogicに精通している友人は、セッションレプリケーションにも精通している必要があります。名前が示すように、Session Copyは、ユーザーのセッションをWebにコピーすることです。内政の増加とネットワークの負のフェーズの指数関数的な増加により、この処理メカニズムがもたらされます。ただし、その欠点も非常に明白です。マシンの数が増えると、ネットワークの負担が指数関数的に増加し、サーバーの数が増えるとパフォーマンスが急激に低下し、ネットワークストームが発生しやすくなります。
4. Memcache / Redisに基づくセッション共有
Memcacheは、Libeventのマルチチャネル非同期IOテクノロジーに基づくメモリ共有システムです。シンプルなKey + Valueデータストレージモードにより、コードロジックが小さく効率的になるため、同時処理機能に絶対的な利点があります。
Memcace Pは、期限切れのセッションデータを削除するコードの複雑さを軽減することにも言及する価値があります。ただし、これは、期限切れのセッションデータを削除するための「データベースベースのストレージソリューション」を削減するセッション期限切れメカニズムと一致します。ロジックだけで、データテーブルに大きなクエリ圧力がかかります。
NoSQLの新星として、Redisはしばしばmemcachedと比較されます。NoSQLの新星として、Redisはしばしばmemcachedと比較されます。キャッシュとして、または単にNoSQLデータベースと呼ばれるものとして、redisは豊富なデータ型（リスト、セットなど）を提供します。これにより、単一のマシンメモリからredisクラスターに大量のデータソートを解放して処理できます。軽量レベルのメッセージミドルウェアを実現するために使用されます。memcachedとredisのパフォーマンス比較では、データの読み取りおよび書き込み速度が100k未満の場合、redisはmemcachedよりも優れています。私たちのシステムでは、セッションデータを保存するためにredisがmemcachedに取って代わりました。
3.セッションの永続性とは何ですか？
セッションの保持はセッションの共有ではありません。
ほとんどのeコマースアプリケーションシステム、またはユーザーID認証を必要とするオンラインシステムでは、クライアントとサーバーは、トランザクションまたは要求を完了する前に、いくつかの対話を行うことがよくあります。これらの相互作用は密接に関連しているため、これらの相互作用の過程で、サーバーは特定の相互作用ステップを完了するために、前の相互作用の処理結果または前のステップの相互作用結果を理解する必要があります。プロセスは1つのサーバーによって完了され、ロードバランサーによって異なるサーバーに分散することはできません。
また、この一連の関連する対話プロセスは、クライアントとサーバー間の1つの接続の複数のセッションによって完了することも、クライアントとサーバー間の複数の異なる接続の複数のセッションによって完了することもあります。異なる接続の複数のセッションに関して、最も一般的な例はHTTPベースのアクセスです。顧客はトランザクションを完了するために複数回クリックする必要があり、新しいクリックによって生成されたリクエストは、前のクリックによって確立された接続を再利用する場合があります。新しく作成された接続でもあります。
セッションの永続性とは、クライアントとサーバー間の対話プロセスの関連性を識別できるメカニズムがロードバランサーにあることを意味します。ロードバランシングを実行している間、一連の関連するアクセス要求が同じものに割り当てられるようにすることもできます。 。サーバー上。
次に、ロードバランサーのセッション保持メカニズム（インタビューの焦点）
セッション保持メカニズムの目的は、特定のユーザーとシステムセッションが特定の期間内に処理するために同じサーバーにのみ渡されるようにすることです。これは、オンラインバンキング、オンラインショッピング、その他のニーズを満たす場合に特に重要です。アプリケーションシナリオ。ロードバランサーはセッション保持を実装します。一般に、いくつかの解決策があります。
1.送信元IPアドレスに基づく継続的なメンテナンス。これは主に4層の負荷分散に使用されます。このソリューションは誰にとっても最も馴染み深いものです。LVS/ HAProxyとNginxには、Nginxのip_hashアルゴリズムやHAProxyのソースアルゴリズムなど、同様の処理メカニズムがあります。
2.クッキーデータに基づく継続的なメンテナンス。これは主に、同じセッションのパケットを同じサーバーに分散できるようにするためのレイヤー7負荷分散に使用されます。その中で、サーバーの応答メッセージにサーバー情報を含むCookieの設定フィールドが含まれているかどうかに応じて、Cookieの挿入と保持、およびCookieの傍受と保持に分けることができます。
3.HTTPヘッダーに基づく継続的なメンテナンス。これは主に7層の負荷分散に使用されます。ロードバランサーは特定のクライアントから最初の要求を受信すると、HTTPヘッダーキーワードに基づいて永続的なエントリを確立し、クライアントに割り当てられたサーバーのステータスを記録します。セッションエントリの存続期間中、同じHTTPヘッダー情報を持つ後続の接続が処理のためにサーバーに送信されます。
3. LvSセッション保持メカニズムの実際のケース（インタビューの焦点）
LVSセッション保持メカニズム
LVSは、構成ファイルの==永続性（秒単位）==設定を使用して、セッションの保持時間を設定します。このオプションは、eコマースWebサイトにとって特に重要です。ユーザーがアカウントを使用してWebサイトにリモートでログインする場合、このセッションを渡します。ホールド機能は、ユーザーの要求を同じアプリケーションサーバーに転送できます。ここで仮定を立てましょう。LVS環境があり、LVS / DR転送モードを使用すると、2つの実際のWebサーバーがあり、LVSロードバランサーはセッション永続化機能を有効にしません。ユーザーが初めてアクセスすると、ロードバランサーによってアクセス要求が実サーバーに転送され、ログインページが表示され、最初のアクセスが完了します。次に、ログインボックスにユーザー名とパスワードを入力して送信しますが、この時点で問題が発生する可能性があり、ログインに失敗します。セッションの保持がないため、ロードバランサーは2番目のリクエストを別のサーバーに転送する場合があります。これにより、ブラウザーはクライアントに再度リクエストする必要があることを通知します。
ケース実際の戦闘
ホストベースの持続的接続
各クライアントが永続的である場合、同じクライアントからのすべての要求は以前に選択されたRSに送信されます。つまり、IPが
同じである限り、割り当てられたサーバーは常に同じです。
ipvsadm -A -t 172.16.0.8:0 -s wlc -p 120
# 添加一个 tcp 负载集群，集群地址为 172.16.0.8 ，算法为 wlc，持久化时间为 120s
ポートに基づく持続的接続
各ポートが永続的である場合、同じクライアントからの同じサービス（ポート）に対する要求は、常に以前に選択されたRSに送信されます。
ipvsadm -A -t 172.16.0.8:80 -s rr -p 120
# 添加一个 tcp 负载集群，集群地址为 172.16.0.8:80 ，算法为 wlc，持久化时间为 120s
ファイアウォールに基づく持続的接続
指定されたサービス（ポート）に対する同じクライアントからの要求は、常に選択されたRSに送信されますが、2つの無関係なポートをクラスターサービスとして定義できます。
iptables -t mangle -A PREROUTING -d 172.16.0.8 -p tcp --dport 80 -j MARK --
set-mark 10 # 添加一个防火墙规则，当目标地址为 172.16.0.8 并且 目标端口为 80 时给数据包打一个标记，设置mark 值为 10
iptables -t mangle -A PREROUTING -d 172.16.0.8 -p tcp --dport 443 -j MARK --
set-mark 10
# 添加一个防火墙规则，当目标地址为 172.16.0.8 并且 目标端口为 443 时给数据包打一个标记，设置mark 值为 10
service iptables save # 保存防火墙规则持久化生效
ipvsadm -A -f 10 -s wlc -p 120 # 添加一个负载调度器，当 mark 值为 10 时进行负载均衡使用wlc 算法，持久化生效时间为 120s