一、nginx Nginx （發音同 engine x）是一款輕量級的Web 伺服器／反向代理伺服器及電子郵件（IMAP/POP3）代理伺服器，併在一個BSD-like 協議下發行。 其特點是占有記憶體少，併發能力強，事實上nginx的併發能力確實在同類型的網頁伺服器中表現較好。目前中國大陸使用ngi ...
一、nginx
Nginx （發音同 engine x）是一款輕量級的Web 伺服器／反向代理伺服器及電子郵件（IMAP/POP3）代理伺服器，併在一個BSD-like 協議下發行。 其特點是占有記憶體少，併發能力強，事實上nginx的併發能力確實在同類型的網頁伺服器中表現較好。目前中國大陸使用nginx網站用戶有：新浪、網易、 騰訊,另外知名的微網志Plurk也使用nginx。
廢話不多說， 先上圖...
二、Tomcat
tomcat伺服器就不用多說了吧。我們可以準備2、3個tomcat伺服器進行測試。廢話不多說，準備環境走起...
三、環境準備
1、 jdk 1.8.0_102
2、nginx 1.12.0(在官網上下一個解壓就行，官網：http://nginx.org/)；
3、2個或多個tomcat 6.x 7.x 8.x 9.x 都可以（比如我準備的是3個一模一樣的8.x版本，只是配置文件改了而已，一會會詳細怎麼改 ，官網：http://tomcat.apache.org/）
四、nginx配置文件
路徑：\nginx-1.12.0\conf\nginx.conf
配置如下：
[html] view plain copy
- #Nginx所用用戶和組，window下不指定 #user niumd niumd; #工作的子進程數量（通常等於CPU數量或者2倍於CPU） worker_processes 2; #錯誤日誌存放路徑 #error_log logs/error.log; #error_log logs/error.log notice; error_log logs/error.log info; #指定pid存放文件 #pid logs/nginx.pid; events { #使用網路IO模型linux建議epoll，FreeBSD建議採用kqueue，window下不指定。 #use epoll; #允許最大連接數 worker_connections 2048; } http { include mime.types; default_type application/octet-stream; #定義日誌格式 log_format main '$remote_addr - $remote_user [$time_local] $request ' '"$status" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; #access_log off; access_log logs/access.log; client_header_timeout 3m; client_body_timeout 3m; send_timeout 3m; client_header_buffer_size 1k; large_client_header_buffers 4 4k; sendfile on; tcp_nopush on; tcp_nodelay on; #keepalive_timeout 75 20; #include gzip.conf; #負載均衡配置 upstream localhost { #根據ip計算將請求分配各那個後端tomcat，許多人誤認為可以解決session問題，其實並不能。 #同一機器在多網情況下，路由切換，ip可能不同 #ip_hash; #upstream的負載均衡，weight是權重，可以根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的幾率越大。 ip_hash; server localhost:18081; server localhost:18082; server localhost:18083; #nginx的upstream目前支持4種方式的分配 #1、輪詢（預設） #每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。 #2、weight #指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況。 #例如： #upstream bakend { # server 192.168.0.14 weight=10; # server 192.168.0.15 weight=10; #} #2、ip_hash #每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題。 #例如： #upstream bakend { # ip_hash; # server 192.168.0.14:88; # server 192.168.0.15:80; #} #3、fair（第三方） #按後端伺服器的響應時間來分配請求，響應時間短的優先分配。 #upstream backend { # server server1; # server server2; # fair; #} #4、url_hash（第三方） #按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為緩存時比較有效。 #例：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash演算法 #upstream backend { # server squid1:3128; # server squid2:3128; # hash $request_uri; # hash_method crc32; #} #tips: #upstream bakend{#定義負載均衡設備的Ip及設備狀態}{ # ip_hash; # server 127.0.0.1:9090 down; # server 127.0.0.1:8080 weight=2; # server 127.0.0.1:6060; # server 127.0.0.1:7070 backup; #} #在需要使用負載均衡的server中增加 proxy_pass http://bakend/; #每個設備的狀態設置為: #1.down表示單前的server暫時不參與負載 #2.weight為weight越大，負載的權重就越大。 #3.max_fails：允許請求失敗的次數預設為1.當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤 #4.fail_timeout:max_fails次失敗後，暫停的時間。 #5.backup： 其它所有的非backup機器down或者忙的時候，請求backup機器。所以這台機器壓力會最輕。 #nginx支持同時設置多組的負載均衡，用來給不用的server來使用。 #client_body_in_file_only設置為On 可以講client post過來的數據記錄到文件中用來做debug #client_body_temp_path設置記錄文件的目錄 可以設置最多3層目錄 #location對URL進行匹配.可以進行重定向或者進行新的代理 負載均衡 } server { listen 80; server_name localhost; location / { proxy_connect_timeout 3; proxy_send_timeout 30; proxy_read_timeout 30; proxy_pass http://localhost; } #css|js|ico|gif|jpg|jpeg|png|txt|html|htm|xml|swf|wav這些都是靜態文件，但應分辨，js、css可能經常會變，過期時間應小一些，圖片、html基本不變，過期時間可以設長一些 location ~* ^.+\.(ico|gif|jpg|jpeg|png|html|htm)$ { root html; access_log logs/access.log; expires -1s; } gzip on; gzip_comp_level 7; gzip_min_length 1100; #需要壓縮的最小長度 gzip_buffers 4 8k; gzip_types text/plain application/javascript text/css text/xml application/x-httpd-php; #指定需要壓縮的文件類型 output_buffers 1 32k; postpone_output 1460; #error_page 404 /404.html; # redirect server error pages to the static page /50x.html error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
五、Tomcat配置文件
apache-tomcat-8.5.16.1\conf\server.xml
...
<Server port="18006" shutdown="SHUTDOWN">
...
<Connector port="18081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
...
<Connector port="18009" protocol="AJP/1.3" redirectPort="8443" />
...
apache-tomcat-8.5.16.2\conf\server.xml
...
<Server port="18007" shutdown="SHUTDOWN">
...
<Connector port="18082" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
...
<Connector port="28009" protocol="AJP/1.3" redirectPort="8443" />
...
apache-tomcat-8.5.16.3\conf\server.xml
...
<Server port="18008" shutdown="SHUTDOWN">
...
<Connector port="18083" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
...
<Connector port="38009" protocol="AJP/1.3" redirectPort="8443" />
...
OK，需要配置的就配置好了，我們再做一件事，我們選用歡迎頁，為了區別歡迎頁，我們修改一下index.jsp頁面，apache-tomcat-8.5.16.1\webapps\ROOT\index.jsp，隨意區分一下就好。然後分別啟動nginx和三個tomcat（nginx.exe、startup.bat）
(因為編譯器不讓我放圖片，放一個網上找的，真的日狗，在網頁上複製圖片粘貼可以，更日血的是，自己寫一個簡單靜態頁面載入截圖不能複製圖片粘貼。。。)
因為我們在上面說了，改tomcat的歡迎頁，所以每次刷新的時候呢，三個歡迎頁就會輪流替換，在實際項目中也是一樣的原理，但是有一點不足，session共用問題，這麼做session是不共用的。也是不滿足高併發，這隻是一個演示的demo。
怎樣實現session共用呢？
查了一些資料，看了一些別人寫的文檔，總結如下，實現nginx session的共用
伺服器有多台，用nginx做負載均衡，這樣同一個IP訪問同一個頁面會被分配到不同的伺服器上，如果session不同步的話，就會出現很多問題，比如說最常見的登錄狀態，下麵提供了幾種方式來解決session共用的問題：
1、不使用session，換用cookie session是存放在伺服器端的，cookie是存放在客戶端的，我們可以把用戶訪問頁面產生的session放到cookie裡面，就是以cookie為中轉站。你訪問web伺服器A，產生了session然後把它放到cookie裡面，當你的請求被分配到B伺服器時，伺服器B先判斷伺服器有沒有這個session，如果沒有，再去看看客戶端的cookie裡面有沒有這個session，如果也沒有，說明session真的不存，如果cookie裡面有，就把cookie裡面的sessoin同步到伺服器B，這樣就可以實現session的同步了。
說明：這種方法實現起來簡單，方便，也不會加大資料庫的負擔，但是如果客戶端把cookie禁掉了的話，那麼session就無從同步了，這樣會給網站帶來損失；cookie的安全性不高，雖然它已經加了密，但是還是可以偽造的。
2、session存在資料庫（MySQL等）中 後臺可以配置將session保存在資料庫中，這種方法是把存放session的表和其他資料庫表放在一起，如果mysql也做了集群了話，每個mysql節點都要有這張表，並且這張session表的數據表要實時同步。
說明：用資料庫來同步session，會加大資料庫的IO，增加資料庫的負擔。而且資料庫讀寫速度較慢，不利於session的適時同步。
3、session存在memcache或者Redis中 memcache可以做分散式，配置文件中設置存儲方式為memcache，這樣會建立一個session集群，將session數據存儲在memcache中。
說明：以這種方式來同步session，不會加大資料庫的負擔，並且安全性比用cookie大大的提高，把session放到記憶體裡面，比從文件中讀取要快很多。但是memcache把記憶體分成很多種規格的存儲塊，有塊就有大小，這種方式也就決定了，memcache不能完全利用記憶體，會產生記憶體碎片，如果存儲塊不足，還會產生記憶體溢出。
4、nginx中的ip_hash技術能夠將某個ip的請求定向到同一臺後端，這樣一來這個ip下的某個客戶端和某個後端就能建立起穩固的session，ip_hash是在upstream配置中定義的：
[html] view plain copy- upstream localhost
- {
- server localhost:18006;
- server localhost:18007;
- ip_hash;
- }
- server
- {
- listen 80;
- location /
- {
- proxy_pass
- localhost;
- }
- }
ip_hash是容易理解的，但是因為僅僅能用ip這個因數來分配後端，因此ip_hash是有缺陷的，不能在一些情況下使用：
1.nginx不是最前端的伺服器。 ip_hash要求nginx一定是最前端的伺服器，否則nginx得不到正確ip，就不能根據ip作hash。譬如使用的是squid為最前端，那麼nginx取ip時只能得到squid的伺服器ip地址，用這個地址來作分流是肯定錯亂的。
2.nginx的後端還有其它方式的負載均衡。 假如nginx後端又有其它負載均衡，將請求又通過另外的方式分流了，那麼某個客戶端的請求肯定不能定位到同一臺session應用伺服器上。這麼算起來，nginx後端只能直接指嚮應用伺服器，或者再搭一個squid，然後指嚮應用伺服器。最好的辦法是用 location作一次分流，將需要session的部分請求通過ip_hash分流，剩下的走其它後端去。
5、upstream_hash 為瞭解決ip_hash的一些問題，可以使用upstream_hash這個第三方模塊，這個模塊多數情況下是用作url_hash的，但是並不妨礙將它用來做session共用。它的原理是這樣的：瀏覽器A去訪問nginx，nginx根據IP的hash去訪問某一個伺服器，至此，以後的每次訪問都會是這個伺服器在運作，所以才有的session同步，瀏覽器B、C、D...也去訪問nginx，nginx還會根據B、C、D的IP_hash訪問的伺服器可能還是原來的伺服器也有可能是新的伺服器。它們之後的訪問都會是各自第一次訪問你的伺服器，只有伺服器崩了，才會去別的伺服器，從而實現session共用。
至此window下nginx+tomcat負載均衡配置結束。
