Tomcatクラスタ構築(nginx+tomcat+redis)
13834 ワード
目次
前言
1 nginxとapacheの違い
2ソフトウェアのインストール
2.1インストールの説明
2.2 nginxインストール
2.2.1依存パッケージのインストール
2.2.2 nginxインストール
2.2.3テスト
2.3 redis取付
3クラスタ構成
3.1 nginx構成
3.2テスト
3.2.1テスト項目の作成
3.2.2発表項目
3.2.3テストクラスタ
4セッション共有
4.1関連jarパッケージのダウンロード
4.2関連構成
4.3テスト
4.3.1プロジェクトファイルの修正
4.3.2テスト
5まとめ
前言
以前は、サーバクラスタについても理解していましたが、ここではあまり説明しません.ここでTomcatクラスタ構築(APACHE+MOD_JK+TOMCAT構成)を参照してください.
1 nginxとapacheの違い
apacheサーバを構築すると、apr、apr-util、expat-devel、libtool-ltdl-develなど、多くのパッケージに依存しているため、インストール中に異なる環境に応じて適切なインストールファイルを修正してインストールを実行する必要があります.また、apacheがhttpリクエストを処理するのはnginxのようにブロックではなくブロックであるため、その処理リクエストの効率はnginxほど高くない.
両者の最も核心的な違いはapacheが同期マルチプロセスモデルであり、1つの接続が1つのプロセスに対応することである.nginxは非同期であり、複数の接続(万レベル)は1つのプロセスに対応することができる.nginxは静的ファイルを処理するのがよく、メモリの消費量が少ない.しかし、apacheは依然として現在の主流であり、多くの豊富な特性を持っているに違いない.だからまだ組み合わせる必要があります.もちろん、nginxが需要に適していると判断できれば、nginxを使用するのがより経済的な方法になります.
nginxは良いフロントエンドサーバで、負荷性能がよく、webbenchで10000個の静的ファイル要求をシミュレートするのは骨が折れず、apacheよりも負荷能力が高い.しかし、apacheはダイナミックな処理に優れており、nginxの同時性が優れ、CPUメモリの消費量が低く、rewriteが頻繁であればapacheが良い.
両者の長所と短所を以下に述べる
nginxのapacheに対する利点:
(1)軽量級、同様のwebサービスはapacheより少ないメモリと資源を占有する.
(2)同時抵抗、nginx自体は逆エージェントサーバであり、処理要求は非同期非ブロックであり、apacheはブロック型であり、高合併下でnginxは低資源低消費高性能を維持することができ、apacheはそうではない.
(3)高度なモジュール化の設計、モジュールの作成は比較的簡単で、そのコミュニティも非常に活発で、各種の高性能モジュールの出品は迅速である.
(4)nginxプロファイルは簡潔に書かれており、正規構成により多くのことが簡単に実行でき、リソースの占有量が少なく、エージェント機能が強く、フロントエンド応答サーバに適しています.
apacheのnginxに対する利点:
(1)rewriteは、nginxのrewriteより強い.
(2)多くのモジュールは、結局発展の時間が長いので、基本的に考えていることはすべて見つけることができます.
(3)安定で成熟しており,比較的バグが少ないが,nginxは相対的に若く,nginxのバグは比較的多い.
2ソフトウェアのインストール
2.1インストールの説明
ここで使用するlinuxバージョンはcentos 7で、インストールするソフトウェアはjdk、tomcat、redis、nginxがあり、nginxはgzipモジュールに依存しています(zlibライブラリが必要です.http://www.zlib.net/ダウンロード)、rewriteモジュール(pcreライブラリが必要で、http://www.pcre.org/ダウンロード)とsslモジュール(opensslライブラリが必要で、http://www.openssl.org/ダウンロード).
nginxの依存パケットのインストール順序はopenssl,zlib,pcreの順である.
関連パッケージの説明は以下の通りです.
jdk:jdk-8u181-linux-x64.tar.gz
tomcat:apache-tomcat-7.0.90.tar.gz
redis:redis-4.0.10.tar.gz
nginx:nginx-1.6.2.tar.gz、openssl-1.0.2o.tar.gz、zlib-1.2.11.tar.gz、pcre-8.38.tar.gz
このうち、jdkとtomcatのダウンロードインストールはここではあまり言わないが、ネット上では多くのものを見つけることができるか、ここでTomcatクラスタ構築(APACHE+MOD_JK+TOMCAT構成)を参照することができる.
2.2 nginxインストール
2.2.1依存パッケージのインストール
(1)依存するライブラリのインストール
(2)Openssl依存ライブラリの解凍
(3)zlib依存ライブラリの解凍
(4)pcre依存ライブラリの解凍
2.2.2 nginxインストール
2.2.3テスト
nginxを開く
nginxに関するコマンド
Webページにアクセスし、http://192.168.17.132/ここで注意したいのは、80ポートが開いていなければアクセスできないので、ファイアウォールが必要で80ポートを開くにはここを参考にしてください.https://blog.csdn.net/qq_15092079/article/details/81460237.
2.3 redis取付
redisサービスプロセスを開始すると、テストクライアントプログラムredis-cliとredisサービスインタラクションを使用できます.
これでredisのインストールに成功しました!
ここでは特に説明する必要があります.redisとtomcatが同じマシンにいない場合は、対応する構成が必要です.そうしないと、redisが接続を拒否します.
3クラスタ構成
3.1 nginx構成
説明、nginxの負荷等化方式はいくつかあり、それぞれポーリング方式(デフォルト)、weight重み付けポーリング、ip_hash方式、fair方式、url_hash方式.
Weight重み付けポーリング、ポーリング確率を指定し、weightとアクセス比率を比例させ、バックエンドサーバのパフォーマンスが不均一な場合に使用します.
ip_hash方式では、各リクエストはipにアクセスするhash結果によって割り当てられ、このように各ゲストがバックエンドサーバに固定的にアクセスし、sessionの問題を解決することができる.
fair方式では,バックエンドサーバの応答時間に応じてリクエストを割り当て,応答時間の短い優先割当てを行う.Weight割り当てポリシーと似ています.
url_hash方式では,urlにアクセスしたhash結果に応じて要求を割り当て,各urlを同じバックエンドサーバに指向させ,バックエンドサーバがキャッシュである場合に有効である.注意:upstreamにhash文を追加し、server文にweightなどの他のパラメータを書き込むことはできません.hash_methodはhashアルゴリズムを使用します.
nginxについてconfプロファイルの詳細は、次のとおりです.
3.2テスト
3.2.1テスト項目の作成
新規プロジェクト:プロジェクト名はすべてTestTomcat新規jspページ:名前はtestjsp.jsp
3.2.2発表項目
(1)テスト項目をtomcat 1サーバにパブリッシュする.(2)項目testjspを修正する.jspファイル
(3)変更した項目をtomcat 2サーバにパブリッシュする
3.2.3テストクラスタ
nginxエージェントサーバには、それぞれ異なるクライアントでアクセスします. http://192.168.17.132/TestTomcat/testjsp.jspアクセス結果、tomcat 2=========Wed Jun 29 13:25:03 CST 2011またはtomcat 1====Wed Jun 29 13:26:03 CST 2011
4セッション共有
なぜ以前apacheがクラスタを構築する際にtomcatが持参したセッションを直接コピーする方式でセッション共有を達成していたのか、ここではredisがセッションを格納する方式でセッション共有を達成していたのか.実は、ここではtomcatが持参したセッションコピー方式を直接使用することもできますが、この方式は中小規模システムにのみ適用され、少し大きいシステムでもこの方式を使用すると、ネットワーク嵐のリスクをもたらす可能性があります(各サーバでセッションを再作成し、セッションメッセージを放送しているため、システムが崩壊する可能性が高いという意味です).したがって,セッションをredisで格納することでセッション共有を達成するリスクはない.
4.1関連jarパッケージのダウンロード
(1)commons-poolをダウンロードし、ここではbinすなわちパッケージされたjarパッケージをダウンロードするだけでよい、commons-pool-1.6-bin.tar.gz中のcommons-pool-1.6.JAr(tomcat-redis-session-managerのバージョンは更新されていないため、現在はcommons-pool 1バージョンのみサポートされています).
(2)tomcat-redis-session-managerをダウンロードし、ここでダウンロードしたバージョン、tomcat-redis-session-manager-1.2-tomcat-7.jar.
(3)jedis-2.1.0をダウンロードする.JArは、javaのredisクライアントとして、commons-poolがバージョン1を使用しているため、ここでjedisのバージョンもあまり高くないように注意してください.そうしないと、commons-pool 2の対応するクラスが見つからないと報告されます.
最後に、この3つのjarを両方のtomcatのlibに配置します.
4.2関連構成
(1)tomcatプロファイルconf/contextを変更する.xml
説明、maxInactiveInterval="60"の設定は役に立たず、tomcatのsession失効間隔はconf/webを読む.xmlのsession-configノードで構成されているsession-timeoutプロパティ値は、分単位で検証しても無駄です.の
4.3テスト
4.3.1プロジェクトファイルの修正
4.3.2テスト
テストの結果、sessionは共有に成功したことが分かった.
アクセスhttp://192.168.17.132/TestTomcat/testjsp.jsp結果表示
tomcat1=======Wed Aug 08 20:12:43 CST 2018===12B141B8BEDD905A893937119506D70B.tomcat1==I am tomcat1==I am tomcat2
再更新アクセスhttp://192.168.17.132/TestTomcat/testjsp.jsp結果表示
tomcat2=======Wed Aug 08 20:12:48 CST 2018===12B141B8BEDD905A893937119506D70B.tomcat2==I am tomcat1==I am tomcat2
これでcentos 7システム上の単純なnginx+tomcat 7+redisのtomcatクラスタの構築が完了した.
5まとめ
総じて言えば、nginxでtomcatクラスタを構築するのはapacheで構築するよりずっと簡単で、しかもその高い同時性能と簡単な構成は、私が期待していることです.しかし、ここで注意しなければならないのは、redisによってsession共有を実現する場合、その3つのjarパッケージのバージョンが合わないと、分刻みでエラーが報告されることです.最後に、ファイアウォールポートのオープンについても言及します.第1に、nginxのtcpポート番号、デフォルト80です.第二に、tomcatとnginxが同じマシンにいない場合、各tomcatのtcpポート番号を開く必要があります.デフォルトは8080です.第三に、tomcatとredisが同じマシンにない場合、このredisのtcpポートを開く必要があり、デフォルト6379であると同時に、redisの対応する構成にも注意しなければならない.詳細は、本明細書2.3の末尾を参照してください.
プログラムでオブジェクトをRedisに入れる場合、そのオブジェクトはjavaを実現する必要がある.io.Serializableインタフェース、そうでないとエラーが報告され、オブジェクトに他のオブジェクトの参照がある場合、その参照オブジェクトもjavaを実現する必要がある.io.Serializableインタフェースはrequestを使用する.getSession().setAttribute()メソッドの場合は、この詳細に注意してください.
前言
1 nginxとapacheの違い
2ソフトウェアのインストール
2.1インストールの説明
2.2 nginxインストール
2.2.1依存パッケージのインストール
2.2.2 nginxインストール
2.2.3テスト
2.3 redis取付
3クラスタ構成
3.1 nginx構成
3.2テスト
3.2.1テスト項目の作成
3.2.2発表項目
3.2.3テストクラスタ
4セッション共有
4.1関連jarパッケージのダウンロード
4.2関連構成
4.3テスト
4.3.1プロジェクトファイルの修正
4.3.2テスト
5まとめ
前言
以前は、サーバクラスタについても理解していましたが、ここではあまり説明しません.ここでTomcatクラスタ構築(APACHE+MOD_JK+TOMCAT構成)を参照してください.
1 nginxとapacheの違い
apacheサーバを構築すると、apr、apr-util、expat-devel、libtool-ltdl-develなど、多くのパッケージに依存しているため、インストール中に異なる環境に応じて適切なインストールファイルを修正してインストールを実行する必要があります.また、apacheがhttpリクエストを処理するのはnginxのようにブロックではなくブロックであるため、その処理リクエストの効率はnginxほど高くない.
両者の最も核心的な違いはapacheが同期マルチプロセスモデルであり、1つの接続が1つのプロセスに対応することである.nginxは非同期であり、複数の接続(万レベル)は1つのプロセスに対応することができる.nginxは静的ファイルを処理するのがよく、メモリの消費量が少ない.しかし、apacheは依然として現在の主流であり、多くの豊富な特性を持っているに違いない.だからまだ組み合わせる必要があります.もちろん、nginxが需要に適していると判断できれば、nginxを使用するのがより経済的な方法になります.
nginxは良いフロントエンドサーバで、負荷性能がよく、webbenchで10000個の静的ファイル要求をシミュレートするのは骨が折れず、apacheよりも負荷能力が高い.しかし、apacheはダイナミックな処理に優れており、nginxの同時性が優れ、CPUメモリの消費量が低く、rewriteが頻繁であればapacheが良い.
両者の長所と短所を以下に述べる
nginxのapacheに対する利点:
(1)軽量級、同様のwebサービスはapacheより少ないメモリと資源を占有する.
(2)同時抵抗、nginx自体は逆エージェントサーバであり、処理要求は非同期非ブロックであり、apacheはブロック型であり、高合併下でnginxは低資源低消費高性能を維持することができ、apacheはそうではない.
(3)高度なモジュール化の設計、モジュールの作成は比較的簡単で、そのコミュニティも非常に活発で、各種の高性能モジュールの出品は迅速である.
(4)nginxプロファイルは簡潔に書かれており、正規構成により多くのことが簡単に実行でき、リソースの占有量が少なく、エージェント機能が強く、フロントエンド応答サーバに適しています.
apacheのnginxに対する利点:
(1)rewriteは、nginxのrewriteより強い.
(2)多くのモジュールは、結局発展の時間が長いので、基本的に考えていることはすべて見つけることができます.
(3)安定で成熟しており,比較的バグが少ないが,nginxは相対的に若く,nginxのバグは比較的多い.
2ソフトウェアのインストール
2.1インストールの説明
ここで使用するlinuxバージョンはcentos 7で、インストールするソフトウェアはjdk、tomcat、redis、nginxがあり、nginxはgzipモジュールに依存しています(zlibライブラリが必要です.http://www.zlib.net/ダウンロード)、rewriteモジュール(pcreライブラリが必要で、http://www.pcre.org/ダウンロード)とsslモジュール(opensslライブラリが必要で、http://www.openssl.org/ダウンロード).
nginxの依存パケットのインストール順序はopenssl,zlib,pcreの順である.
関連パッケージの説明は以下の通りです.
jdk:jdk-8u181-linux-x64.tar.gz
tomcat:apache-tomcat-7.0.90.tar.gz
redis:redis-4.0.10.tar.gz
nginx:nginx-1.6.2.tar.gz、openssl-1.0.2o.tar.gz、zlib-1.2.11.tar.gz、pcre-8.38.tar.gz
このうち、jdkとtomcatのダウンロードインストールはここではあまり言わないが、ネット上では多くのものを見つけることができるか、ここでTomcatクラスタ構築(APACHE+MOD_JK+TOMCAT構成)を参照することができる.
2.2 nginxインストール
2.2.1依存パッケージのインストール
(1)依存するライブラリのインストール
yum -y install make gcc-c++ libtool
yum -y install lrzsz(2)Openssl依存ライブラリの解凍
# openssl-1.0.2o.tar.gz /usr/softwares
rz
#
cd /usr/softwares
#
tar -xzvf openssl-1.0.2o.tar.gz
# ，
#
cd openssl-1.0.2o
./config --prefix=/usr/openssl # /usr/openssl
#
make && make install(3)zlib依存ライブラリの解凍
# zlib-1.2.11.tar.gz /usr/softwares
rz
#
cd /usr/softwares
#
tar -xzvf zlib-1.2.11.tar.gz
# ，
#
cd zlib-1.2.11
./configure --prefix=/usr/zlib # /usr/zlib
#
make && make install(4)pcre依存ライブラリの解凍
# pcre-8.38.tar.gz /usr/softwares
rz
#
cd /usr/softwares
#
tar -xzvf pcre-8.38.tar.gz
# ，
#
cd pcre-8.38
./configure --prefix=/usr/pcre # /usr/pcre
#
make && make install2.2.2 nginxインストール
1)
# nginx-1.6.2.tar.gz /usr/softwares
rz
#
cd /usr/softwares
#
tar -xzvf nginx-1.6.2.tar.gz
2)
cd nginx-1.6.2
./configure --prefix=/usr/nginx --with-openssl=/usr/softwares/openssl-1.0.2o --with-zlib=/usr/softwares/zlib-1.2.11 --with-pcre=/usr/softwares/pcre-8.38
# ，nginx apache ，apache --with ， nginx --with
# openssl、zlib pcre ， ，
#
make && make install2.2.3テスト
nginxを開く
cd /usr/nginx
./sbin/nginxnginxに関するコマンド
， nginx
./sbin/nginx # nginx
./sbin/nginx -s reload|reopen|stop|quit # | | | nginx
./sbin/nginx -t #
Webページにアクセスし、http://192.168.17.132/ここで注意したいのは、80ポートが開いていなければアクセスできないので、ファイアウォールが必要で80ポートを開くにはここを参考にしてください.https://blog.csdn.net/qq_15092079/article/details/81460237.
2.3 redis取付
1)
# redis-4.0.10.tar.gz /usr/softwares
rz
#
cd /usr/softwares
# /usr/redis
mkdir /usr/redis
mv redis-4.0.10.tar.gz /usr/redis
#
cd /usr/redis
tar -xzvf redis-4.0.10.tar.gz
2)
cd redis-4.0.10
make
3)
./src/redis-server
# redis 。 redis 。
./src/redis-server ./redis.conf
#redis.conf 。 。
redisサービスプロセスを開始すると、テストクライアントプログラムredis-cliとredisサービスインタラクションを使用できます.
cd src
.src/redis-cli
redis> set foo bar
OK
redis> get foo
"bar"これでredisのインストールに成功しました!
ここでは特に説明する必要があります.redisとtomcatが同じマシンにいない場合は、対応する構成が必要です.そうしないと、redisが接続を拒否します.
# redis redis.conf
vim /usr/redis/redis-4.0.10/redis.conf
# requirepass # ， （ ， redis ） ， redis
requirepass 123456
# bind 127.0.0.1， # ， redis
#bind IP
#
127.0.0.1:6379> auth 1234563クラスタ構成
3.1 nginx構成
1) nginx
cd /usr/nginx
2) nginx nginx.conf
vim conf/nginx.conf
http { ：
#Tomcat
upstream sky {
server 192.168.33.10:8080 max_fails=1 fail_timeout=10s;
server 192.168.33.10:8081 max_fails=1 fail_timeout=10s;
}
http { server { location / { ：
proxy_pass http://sky;
：:wq
3) nginx
./sbin/nginx -s reload説明、nginxの負荷等化方式はいくつかあり、それぞれポーリング方式(デフォルト)、weight重み付けポーリング、ip_hash方式、fair方式、url_hash方式.
Weight重み付けポーリング、ポーリング確率を指定し、weightとアクセス比率を比例させ、バックエンドサーバのパフォーマンスが不均一な場合に使用します.
upstream qwe{
server 10.0.0.77 weight=5;#
server 10.0.0.88 weight=10;#
}ip_hash方式では、各リクエストはipにアクセスするhash結果によって割り当てられ、このように各ゲストがバックエンドサーバに固定的にアクセスし、sessionの問題を解決することができる.
upstream qwe{
ip_hash;
server 10.0.0.77;
server 10.0.0.88;
}fair方式では,バックエンドサーバの応答時間に応じてリクエストを割り当て,応答時間の短い優先割当てを行う.Weight割り当てポリシーと似ています.
upstream qwe{
fair;
server 10.0.0.77;
server 10.0.0.88;
}url_hash方式では,urlにアクセスしたhash結果に応じて要求を割り当て,各urlを同じバックエンドサーバに指向させ,バックエンドサーバがキャッシュである場合に有効である.注意:upstreamにhash文を追加し、server文にweightなどの他のパラメータを書き込むことはできません.hash_methodはhashアルゴリズムを使用します.
upstream qwe{
hash $request_uri;
hash_method crc32;
server 10.0.0.77;
server 10.0.0.88;
}nginxについてconfプロファイルの詳細は、次のとおりです.
########### 。#################
#user administrator administrators; # ， nobody nobody。
#worker_processes 2; # ， 1
#pid /nginx/pid/nginx.pid; # nginx
error_log log/error.log debug; # ， 。 ，http ，server ， ：debug|info|notice|warn|error|crit|alert|emerg
worker_processes 2; #Nginx ， CPU
events {
accept_mutex on; # ， ， on
multi_accept on; # ， off
#use epoll; # ，select|poll|kqueue|epoll|resig|/dev/poll|eventport
worker_connections 1024; # ， 512
}
http {
include mime.types; #
default_type application/octet-stream; # ， text/plain
#access_log off; #
log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #
access_log log/access.log myFormat; #combined
sendfile on; # sendfile ， off， http ，server ，location 。
sendfile_max_chunk 100k; # ， 0， 。
keepalive_timeout 65; # ， 75s， http，server，location 。
# ， ，
upstream mysvr {
ip_hash; # ip hash ， ， session
#fair; # ， 。 weight 。
server 127.0.0.1:7878;
server 192.168.10.121:3333 backup; # ， 2 ， ， 。
# ：
#down， server 。
#backup， 。 backup ， backup ， 。
#max_fails， ， 1。 ， proxy_next_upstream 。
#fail_timeout， max_fails ， 。max_fails fail_timeout 。
#weight， ， ，weight 。 ， 1。
}
error_page 404 https://www.baidu.com; #
proxy_intercept_errors on; # 400 400， error_page ， on。 off。
server {
keepalive_requests 120; # 。
listen 4545; #
server_name 127.0.0.1; #
location ~*^.+$ { # url ， ，~ ，~* 。
#root path; #
#index vv.txt; #
proxy_pass http://mysvr; # mysvr
deny 127.0.0.1; # ip
allow 172.18.5.54; # ip
}
}
}3.2テスト
3.2.1テスト項目の作成
新規プロジェクト:プロジェクト名はすべてTestTomcat新規jspページ:名前はtestjsp.jsp
tomcat1=======
3.2.2発表項目
(1)テスト項目をtomcat 1サーバにパブリッシュする.(2)項目testjspを修正する.jspファイル
tomcat2=======
(3)変更した項目をtomcat 2サーバにパブリッシュする
3.2.3テストクラスタ
nginxエージェントサーバには、それぞれ異なるクライアントでアクセスします. http://192.168.17.132/TestTomcat/testjsp.jspアクセス結果、tomcat 2=========Wed Jun 29 13:25:03 CST 2011またはtomcat 1====Wed Jun 29 13:26:03 CST 2011
4セッション共有
なぜ以前apacheがクラスタを構築する際にtomcatが持参したセッションを直接コピーする方式でセッション共有を達成していたのか、ここではredisがセッションを格納する方式でセッション共有を達成していたのか.実は、ここではtomcatが持参したセッションコピー方式を直接使用することもできますが、この方式は中小規模システムにのみ適用され、少し大きいシステムでもこの方式を使用すると、ネットワーク嵐のリスクをもたらす可能性があります(各サーバでセッションを再作成し、セッションメッセージを放送しているため、システムが崩壊する可能性が高いという意味です).したがって,セッションをredisで格納することでセッション共有を達成するリスクはない.
4.1関連jarパッケージのダウンロード
(1)commons-poolをダウンロードし、ここではbinすなわちパッケージされたjarパッケージをダウンロードするだけでよい、commons-pool-1.6-bin.tar.gz中のcommons-pool-1.6.JAr(tomcat-redis-session-managerのバージョンは更新されていないため、現在はcommons-pool 1バージョンのみサポートされています).
(2)tomcat-redis-session-managerをダウンロードし、ここでダウンロードしたバージョン、tomcat-redis-session-manager-1.2-tomcat-7.jar.
(3)jedis-2.1.0をダウンロードする.JArは、javaのredisクライアントとして、commons-poolがバージョン1を使用しているため、ここでjedisのバージョンもあまり高くないように注意してください.そうしないと、commons-pool 2の対応するクラスが見つからないと報告されます.
最後に、この3つのjarを両方のtomcatのlibに配置します.
4.2関連構成
(1)tomcatプロファイルconf/contextを変更する.xml
# tomcat context.xml
vim /usr/tomcat/apache-tomcat-7.0.90_1/conf/context.xml
， ：
port="6379"
password=""
database="0"
maxInactiveInterval="60"
/> 説明、maxInactiveInterval="60"の設定は役に立たず、tomcatのsession失効間隔はconf/webを読む.xmlのsession-configノードで構成されているsession-timeoutプロパティ値は、分単位で検証しても無駄です.の
4.3テスト
4.3.1プロジェクトファイルの修正
[root@172-30-4-6 ~] cd /usr/tomcat/apache-tomcat-7.0.90_1/webapps/TestTomcat # web
[root@172-30-4-6 webapps] vim /TestTomcat/testjsp.jsp # testjsp.jsp
html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
tomcat1==============
[root@172-30-4-6 ~] cd /usr/tomcat/apache-tomcat-7.0.90_2/webapps/TestTomcat # tomcat2 web
[root@172-30-4-6 webapps] vim /TestTomcat/testjsp.jsp # testjsp.jsp
html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
tomcat2==============
4.3.2テスト
テストの結果、sessionは共有に成功したことが分かった.
アクセスhttp://192.168.17.132/TestTomcat/testjsp.jsp結果表示
tomcat1=======Wed Aug 08 20:12:43 CST 2018===12B141B8BEDD905A893937119506D70B.tomcat1==I am tomcat1==I am tomcat2
再更新アクセスhttp://192.168.17.132/TestTomcat/testjsp.jsp結果表示
tomcat2=======Wed Aug 08 20:12:48 CST 2018===12B141B8BEDD905A893937119506D70B.tomcat2==I am tomcat1==I am tomcat2
これでcentos 7システム上の単純なnginx+tomcat 7+redisのtomcatクラスタの構築が完了した.
5まとめ
総じて言えば、nginxでtomcatクラスタを構築するのはapacheで構築するよりずっと簡単で、しかもその高い同時性能と簡単な構成は、私が期待していることです.しかし、ここで注意しなければならないのは、redisによってsession共有を実現する場合、その3つのjarパッケージのバージョンが合わないと、分刻みでエラーが報告されることです.最後に、ファイアウォールポートのオープンについても言及します.第1に、nginxのtcpポート番号、デフォルト80です.第二に、tomcatとnginxが同じマシンにいない場合、各tomcatのtcpポート番号を開く必要があります.デフォルトは8080です.第三に、tomcatとredisが同じマシンにない場合、このredisのtcpポートを開く必要があり、デフォルト6379であると同時に、redisの対応する構成にも注意しなければならない.詳細は、本明細書2.3の末尾を参照してください.
プログラムでオブジェクトをRedisに入れる場合、そのオブジェクトはjavaを実現する必要がある.io.Serializableインタフェース、そうでないとエラーが報告され、オブジェクトに他のオブジェクトの参照がある場合、その参照オブジェクトもjavaを実現する必要がある.io.Serializableインタフェースはrequestを使用する.getSession().setAttribute()メソッドの場合は、この詳細に注意してください.