Nginx負荷等化、同時にセッション共有を実現
前言:
プロジェクトの実践では、サーバのブロードバンドを拡張し、スループットを増加させ、ネットワークデータの処理能力を向上させ、ユーザーの体験感を高め、プロジェクトの品質を保証するために、複数のサーバを負荷する必要がある場合があります.1つのプロジェクトが複数のサーバに配備されると、nginxを使用して負荷の等化に慣れ、同じIPでプロジェクトにアクセスすると自動的に異なるサーバに割り当てられます.
しかし、複数のサーバのセッションが同期していないと、私たちのログイン状態、ユーザー情報、デジタル辞書などがゼロになり、再ログインしてから取得する必要があり、ユーザーの体験感が悪くなります.したがって、複数のサーバで負荷分散を行う場合は、複数のサーバ間のセッション同期を考慮する必要があります.以下にいくつかのソリューションを提供します.
ソリューション:
1.クライアントのクッキーをログイン情報を格納する媒体として使用する
クッキーはユーザ登録情報をユーザ端末に格納するデータキャリアであり、sessionとの最大の違いは、sessionがサーバ側に格納されていることである.したがって、このセッションの複数のサーバ共有の問題を簡単に解決できます.クライアントがログインすると、サーバaにアクセスし、ログインに成功した後、セッションを抽出してクライアントのクッキーに保存します.そしてクライアントが2回目にアクセスすると、サーバbにアクセスします.今回はサーバbでログインに成功したセッションがあるかどうかを検索します.空であれば、クライアントのクッキーを検索します.クッキーにセッションが格納されている場合は、クッキーのセッションをサーバbに同期すれば、プロセス全体が通じます.ユーザーも再ログインする必要はありません.
利点:この方法は実現が簡単で、便利で、操作が簡単で、データベースの負担を大きくしません.
欠点:クライアントがクッキーを無効にすると、sessionは同期できなくなり、クッキーの安全性が高くなく、外部で偽造されやすくなります.
2、mysqlデータベースを使用してセッションを保存する
各サーバが同じセッションを使用する必要がある以上、セッションを同じデータベースに保存することができます.アクセスするたびに、このセッションがあるかどうか、またはこのセッションが期限切れであるかどうかをデータベースにチェックし、複数のサーバのセッション同期を行うことができます.
利点:この方法を使うのは簡単で、便利で、簡単に操作することができます;
欠点:データベースを使用してセッションを同期すると、データベースのIOが大きくなり、データベースの負担が増加します.同時に、アクセスするたびに要求をブロックし、データベースをクエリーする必要があり、複数の層がアクセスするビジネス層とデータベースsessionの読み取り時間を浪費します.
3、memcacheまたはredisなどのキャッシュメカニズムを使用してセッションを保存する
memcacheやredisなどの分散キャッシュメカニズムを使用してsessionデータを格納することは、現在多くの大型プロジェクトの負荷均衡同期sessionの人気案である.その原理はプロジェクトが同じ場所のmemcacheやredisのキャッシュを使用していることであり、ユーザーがログインすると、sessionをキャッシュに格納し、その後、プロジェクトのサーバにアクセスしても、同じ場所からsessionキャッシュを取得することで、簡単にsession同期を実現することができる.
利点:キャッシュでsessionを同期することで、データベースの負担を増大させることはなく、手動でsessionが存在するか期限切れであるかどうかを判断する必要もなく、一部の業務ロジックを省くと同時に、redisなどのキャッシュがサーバ側に格納されているため、安全性も大幅に向上する.
欠点:memcacheやredisはメモリを多くの規格のメモリブロックに分け、ブロックがあればサイズがあるという方法で決定します.memcacheやredisはメモリを完全に利用できず、メモリの破片が発生し、メモリブロックが不足するとメモリオーバーフローが発生します.
4、ip_hash
nginxのip_hashテクノロジーは、あるipの要求を同じバックエンドアプリケーションサーバに固定することができ、このipの下のクライアントとあるバックエンドが安定したセッションを確立することができる.ip_hashはupstream構成で定義されています.
利点:ip_hashアルゴリズムはipを1台のサーバにマッピングすることができ,session同期の問題を解決することができる.このように各訪問者はバックエンドサーバに固定的にアクセスし、sessionの問題を解決することができる.
欠点:ip_の使用hashはセッション共有を行い、その原理は各アクセス者に固定的なアクセスipを提供し、ユーザーが現在アクセスしているサーバ上でしか操作できないようにし、セッション同期を維持しているが、負荷の不均衡の問題も発生し、現在のユーザーアクセスのサーバーが切れたら問題が発生する.
参考ブログ:https://blog.csdn.net/zdyueguanyun/article/details/57948393
プロジェクトの実践では、サーバのブロードバンドを拡張し、スループットを増加させ、ネットワークデータの処理能力を向上させ、ユーザーの体験感を高め、プロジェクトの品質を保証するために、複数のサーバを負荷する必要がある場合があります.1つのプロジェクトが複数のサーバに配備されると、nginxを使用して負荷の等化に慣れ、同じIPでプロジェクトにアクセスすると自動的に異なるサーバに割り当てられます.
しかし、複数のサーバのセッションが同期していないと、私たちのログイン状態、ユーザー情報、デジタル辞書などがゼロになり、再ログインしてから取得する必要があり、ユーザーの体験感が悪くなります.したがって、複数のサーバで負荷分散を行う場合は、複数のサーバ間のセッション同期を考慮する必要があります.以下にいくつかのソリューションを提供します.
ソリューション:
1.クライアントのクッキーをログイン情報を格納する媒体として使用する
クッキーはユーザ登録情報をユーザ端末に格納するデータキャリアであり、sessionとの最大の違いは、sessionがサーバ側に格納されていることである.したがって、このセッションの複数のサーバ共有の問題を簡単に解決できます.クライアントがログインすると、サーバaにアクセスし、ログインに成功した後、セッションを抽出してクライアントのクッキーに保存します.そしてクライアントが2回目にアクセスすると、サーバbにアクセスします.今回はサーバbでログインに成功したセッションがあるかどうかを検索します.空であれば、クライアントのクッキーを検索します.クッキーにセッションが格納されている場合は、クッキーのセッションをサーバbに同期すれば、プロセス全体が通じます.ユーザーも再ログインする必要はありません.
利点:この方法は実現が簡単で、便利で、操作が簡単で、データベースの負担を大きくしません.
欠点:クライアントがクッキーを無効にすると、sessionは同期できなくなり、クッキーの安全性が高くなく、外部で偽造されやすくなります.
2、mysqlデータベースを使用してセッションを保存する
各サーバが同じセッションを使用する必要がある以上、セッションを同じデータベースに保存することができます.アクセスするたびに、このセッションがあるかどうか、またはこのセッションが期限切れであるかどうかをデータベースにチェックし、複数のサーバのセッション同期を行うことができます.
利点:この方法を使うのは簡単で、便利で、簡単に操作することができます;
欠点:データベースを使用してセッションを同期すると、データベースのIOが大きくなり、データベースの負担が増加します.同時に、アクセスするたびに要求をブロックし、データベースをクエリーする必要があり、複数の層がアクセスするビジネス層とデータベースsessionの読み取り時間を浪費します.
3、memcacheまたはredisなどのキャッシュメカニズムを使用してセッションを保存する
memcacheやredisなどの分散キャッシュメカニズムを使用してsessionデータを格納することは、現在多くの大型プロジェクトの負荷均衡同期sessionの人気案である.その原理はプロジェクトが同じ場所のmemcacheやredisのキャッシュを使用していることであり、ユーザーがログインすると、sessionをキャッシュに格納し、その後、プロジェクトのサーバにアクセスしても、同じ場所からsessionキャッシュを取得することで、簡単にsession同期を実現することができる.
利点:キャッシュでsessionを同期することで、データベースの負担を増大させることはなく、手動でsessionが存在するか期限切れであるかどうかを判断する必要もなく、一部の業務ロジックを省くと同時に、redisなどのキャッシュがサーバ側に格納されているため、安全性も大幅に向上する.
欠点:memcacheやredisはメモリを多くの規格のメモリブロックに分け、ブロックがあればサイズがあるという方法で決定します.memcacheやredisはメモリを完全に利用できず、メモリの破片が発生し、メモリブロックが不足するとメモリオーバーフローが発生します.
4、ip_hash
nginxのip_hashテクノロジーは、あるipの要求を同じバックエンドアプリケーションサーバに固定することができ、このipの下のクライアントとあるバックエンドが安定したセッションを確立することができる.ip_hashはupstream構成で定義されています.
upstream backend {
server 127.0.0.1:8001;
server 127.0.0.1:8002;
ip_hash;
}利点:ip_hashアルゴリズムはipを1台のサーバにマッピングすることができ,session同期の問題を解決することができる.このように各訪問者はバックエンドサーバに固定的にアクセスし、sessionの問題を解決することができる.
欠点:ip_の使用hashはセッション共有を行い、その原理は各アクセス者に固定的なアクセスipを提供し、ユーザーが現在アクセスしているサーバ上でしか操作できないようにし、セッション同期を維持しているが、負荷の不均衡の問題も発生し、現在のユーザーアクセスのサーバーが切れたら問題が発生する.
参考ブログ:https://blog.csdn.net/zdyueguanyun/article/details/57948393