Linuxクラスタ/分散環境におけるセッション処理方法の紹介

この記事では、主に Linux クラスター/分散環境でのセッション処理の 5 つの戦略をサンプル コードと写真を通じて詳しく紹介します。ぜひ編集者をフォローして一緒に学んでください。

はじめに

一般に、クラスター環境をセットアップした後、考慮しなければならない問題の 1 つは、ユーザーのアクセスによって生成されたセッションをどのように処理するかです。処理が行われない場合、ユーザーは頻繁にログインすることになります。たとえば、クラスター内に 2 つのサーバー A と B があり、ユーザーが初めて Web サイトにアクセスすると、Nginx は負荷分散を通じてユーザーのリクエストをサーバー A に転送します。この時点で、サーバー A はユーザーのセッションを作成します。ユーザーが 2 回目にリクエストを送信すると、Nginx はリクエストをサーバー B にロード バランシングします。この時点では、サーバー B にはセッションがないため、ユーザーはログイン ページに移動します。これはユーザー エクスペリエンスを大幅に低下させ、ユーザーの喪失につながります。このような状況はプロジェクトでは決して発生すべきではありません。

スティッキーセッション、セッションコピー、またはセッション共有を通じてユーザーエクスペリエンスを確保するために、生成されたセッションを処理する必要があります。

以下では、5 つのセッション処理戦略を説明し、その長所と短所を分析します。多くを語る必要はありません。詳細な紹介を見てみましょう。

最初のタイプ: スティッキー セッション

原則: スティッキー セッションとは、ユーザーを特定のサーバーにロックすることを指します。たとえば、上記の例では、ユーザーが最初のリクエストを行うときに、ロード バランサーが使用されます。リクエストはサーバー A に転送されます。ロード バランサーがスティッキー セッションを設定すると、ユーザーからの後続のリクエストはすべてサーバー A に転送されます。これは、ユーザーとサーバー A を結合することと同じです。これがスティッキー セッション メカニズムです。 。

利点: シンプルで、セッションで処理を行う必要はありません。

短所: フォールトトレランスの欠如。現在アクセスしているサーバーに障害が発生し、ユーザーが 2 番目のサーバーに転送された場合、そのセッション情報は無効になります。

該当するシナリオ: 障害が顧客に及ぼす影響はわずかです。サーバー障害は確率が低いイベントです。

実装方法: Nginx を例に挙げると、スティッキーセッションは上流モジュールで ip_hash 属性を設定することで実現できます。

upstream mycluster{
 #这里添加的是上面启动好的两台Tomcat服务器
 ip_hash;#粘性Session
  server 192.168.22.229:8080 weight=1;
  server 192.168.22.230:8080 weight=1;
}

2 番目: サーバーセッションのレプリケーション

原則: いずれかのサーバー上のセッションが変更 (追加、削除、変更) されると、ノードはセッションのすべてのコンテンツをシリアル化し、次にブロードキャストします。他のすべてのノードは、他のサーバーがセッションを必要とするかどうかに関係なく、セッションの同期を確保します。

利点: フォールトトレラントで、サーバー間のセッションはリアルタイムで応答できます。

短所: セッション数が多いと、ネットワーク負荷に一定の圧力がかかり、ネットワークの混雑が発生し、サーバーのパフォーマンスが低下する可能性があります。

実装方法:

① Tomcat、server.xmlを設定してTomcatクラスター機能を有効にします

アドレス: ローカルIPを入力し、ポート番号を設定し、ポートの競合を防ぐだけです。

② アプリケーションに情報を追加する: アプリケーションが現在クラスター環境にあり、分散をサポートしていることを通知します。

Web にオプションを追加します。memcached や Redis などのソリューションでは、Memcached または Redis がクラスターである必要があります。 <distributable></distributable>

セッション共有を使用するメカニズムも 2 つあります。その 2 つの状況は次のとおりです:

① スティッキーセッション処理メソッド

原則: 異なる Tomcat は異なるメイン memcached へのアクセスを指定します。複数の Memcached 間の情報が同期され、マスター/スレーブのバックアップと高可用性が可能になります。ユーザーがアクセスすると、まず Tomcat でセッションを作成し、次にそのセッションを対応する memcahed にコピーします。 Memcache はバックアップの役割のみを果たし、読み取りと書き込みはすべて Tomcat 上で行われます。特定の Tomcat がハングアップすると、クラスターはスタンバイ Tomcat へのユーザーのアクセスを特定し、Cookie に保存されている SessionId に基づいてセッションを検索します。セッションが見つからない場合は、対応する memcached にアクセスしてセッションを見つけます。それを見つけたら、スタンバイ Tomcat 上位にコピーします。

② 非スティッキーセッション処理方法

原則: memcached はマスターとスレーブのレプリケーションを行い、セッションへの書き込みはスレーブの memcached サービスに書き込まれ、読み取りはすべてマスターの memcached 自体から行われます。セッションを保存しません

利点: フォールトトレラント、セッションはリアルタイムで応答します。

実装方法: オープンソースのmsmプラグインを使用して、Tomcat間のセッション共有を解決します: Memcached_Session_Manager (MSM)

a. 复制相关jar包到tomcat/lib 目录下

JAVA memcached客户端：spymemcached.jarmsm项目相关的jar包：1. 核心包，memcached-session-manager-{version}.jar2. Tomcat版本对应的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar序列化工具包：可选kryo，javolution,xstream等，不设置时使用jdk默认序列化。

b. 配置Context.xml ，加入处理Session的Manager

粘性模式配置：

非粘性配置：

 

第四种：session持久化到数据库

原理：就不用多说了吧，拿出一个数据库，专门用来存储session信息。保证session的持久化。

优点：服务器出现问题，session不会丢失

缺点：如果网站的访问量很大，把session存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

第五种terracotta实现session复制

原理：Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点。可以看成是对第二种方案的优化。

优点：这样对网络的压力就非常小，各个节点也不必浪费CPU时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在session同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。

实现方式：篇幅原因，下篇再论。

小结

以上讲述的就是集群或分布式环境下，session的5种处理策略。其中就应用广泛性而言，第三种方式，也就是基于第三方缓存框架共享session，应用的最为广泛，无论是效率还是扩展性都很好。而Terracotta作为一个JVM级的开源群集框架，不仅提供HTTP Session复制，它还能做分布式缓存，POJO群集，跨越群集的JVM来实现分布式应用程序协调等，也值得学习一下。

以上がLinuxクラスタ/分散環境におけるセッション処理方法の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。