488
Nginx + Shiro + Ehcache 實現負載均衡集群(成績報告查詢係統)
項目介紹
最近在做一款產品，對外提供學生成績報告的查詢，支付，查看以及下載等一係列功能，這裏就簡稱成績報告查詢係統吧。
初步參賽人數十萬左右，可能會存在相對高的並發同時在線，所以開發階段就對負載均衡集群做了設計。
當然，涉及到負載均衡集群，就要考慮的Session存儲的問題，由於項目本身使用了Ehcache做本地緩存，Shiro對其做了很好的封裝，並且Ehcache也是支付分布式緩存同步的。所以，采用Ehcache做session存儲暫且是一種實施方案。
關於Ehcache分布式緩存見：
https://blog.52itstyle.com/archives/568/
項目架構
Spring MVC4 + Shiro-1.3.2 + Ehcache-2.10.0
運行環境
Nginx + Tomcat7(3台) + JDK1.7
項目架構圖
前端
前端服務器使用Nginx做負載均衡，開啟Gizp壓縮，並實現動靜分離，所有靜態文件(JS/CSS/PNG等)請求由Nginx處理。
#查詢係統配置
server {
listen 80;
server_name www.xxx.com xxx.com;
index index.jsp index.html;
location / {
proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_pass https://report;
}
location ~ .*.(css|js|png|jpg)$
{
proxy_pass https://report;
proxy_cache cache;
add_header Nginx-Cache $upstream_cache_status;#統計緩存命中
proxy_set_header Accept-Encoding 'gzip';#強製瀏覽器
expires 30d;
}
}
upstream report {
#ip_hash；
server 172.16.1.120:8080 weight=1 max_fails=2 fail_timeout=30s;
server 172.16.1.130:8080 weight=1 max_fails=2 fail_timeout=30s;
server 172.16.1.150:8080 weight=1 max_fails=2 fail_timeout=30s;
}
後端
後端部署3台Tomcat服務器，所有動態請求(JSP/Action等)交給Tomcat處理，同時配置Tomcat的工作模式為Nio，這裏大家可以自行百度Nio工作模式的優點。
實現方式
Nginx負載均衡模式本身支持加權輪詢和ip_hash的。
ip_hash
同一個用戶的請求將全部分配到一台服務，當然也就不存在session共享的問題。但是可能由於請求IP的不固定性，導致單個服務負載過大；如果其中一台宕掉，用戶狀態也不能轉移。
所以，如果是基於ip_hash的配置，Ehcache本地緩存和分布式緩存都可以實現。
加權輪詢
每一個用戶的每一次請求根據權重分配到不同的機器，這就涉及到了session共享的問題。打個比方，如果用戶登錄是後端服務器A並且保存了用戶信息，但是下一次請求可能就會跳轉到後端服務器B，可想而知，這時B是沒有用戶信息的，也就是說用戶還得跳轉到登錄頁麵。
這就涉及到分布式緩存的問題了，如果實現服務器ABC之間session同步的問題，圖中所示，由RMI組播方式實現Ehcache緩存的同步。所以，如果采用加權輪詢必須使用分布式緩存管理session。
項目實現
applicationContext-ehcache.xml 配置：
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="https://www.springframework.org/schema/beans"
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:context="https://www.springframework.org/schema/context"
xmlns:aop="https://www.springframework.org/schema/aop" xmlns:tx="https://www.springframework.org/schema/tx"
xsi:schemaLocation="https://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans-4.0.xsd
https://www.springframework.org/schema/aop https://www.springframework.org/schema/aop/spring-aop-4.0.xsd
https://www.springframework.org/schema/tx https://www.springframework.org/schema/tx/spring-tx-4.0.xsd
https://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context-4.0.xsd">
<description>Shiro EhCacheManager(單點最好使用此配置，集群下使用redisManager)</description>
<!-- 緩存配置-->
<bean >
<property name="configLocation" value="classpath:cache/ehcache-rmi.xml" />
</bean>
<!-- 緩存管理 -->
<bean >
<property name="cacheManager" ref="cacheManager"/>
</bean>
<!-- 會話DAO -->
<bean >
<property name="cacheManager" ref="shiroCacheManager" />
</bean>
</beans>
ehcache-rmi.xml 配置：
<?xml version="1.0" encoding="UTF-8"?>
<ehcache updateCheck="false" name="defaultCache">
<!-- 分布式緩存RMI同步(大規模集群、複雜環境慎用) -->
<diskStore path="java.io.tmpdir" />
<cacheManagerPeerProviderFactory
properties="peerDiscovery=automatic,multicastGroupAddress=230.0.0.1, multicastGroupPort=4446" />
<cacheManagerPeerListenerFactory />
<!-- 默認緩存配置. -->
<defaultCache maxEntriesLocalHeap="100" eternal="false" timeToIdleSeconds="300" timeToLiveSeconds="600"
overflowToDisk="true" maxEntriesLocalDisk="100000" >
<cacheEventListenerFactory
properties="replicatePuts=false,replicateUpdatesViaCopy=false"/>
</defaultCache>
<!-- 係統緩存 -->
<cache name="sysCache" maxEntriesLocalHeap="100" eternal="true" overflowToDisk="true">
<cacheEventListenerFactory />
</cache>
<!-- 係統活動會話緩存 -->
<cache name="shiro-activeSessionCache" maxEntriesLocalHeap="10000" overflowToDisk="true"
eternal="true" timeToLiveSeconds="0" timeToIdleSeconds="0"
diskPersistent="true" diskExpiryThreadIntervalSeconds="600">
<cacheEventListenerFactory
properties="replicateAsynchronously=true, replicatePuts=true, replicateUpdates=true,
replicateUpdatesViaCopy=false, replicateRemovals=true "/>
</cache>
</ehcache>
實現缺點
HCACHE的組播做得比較初級,功能隻是基本實現(比如簡單的一個HUB,接兩台單網卡的服務器,互相之間組播同步就沒問題),對一些複雜的環境(比如多台服務器,每台服務器上多地址,尤其是集群,存在一個集群地址帶多個物理機,每台物理機又帶多個虛擬站的子地址),就容易出現問題。
究其原因, 組播/廣播轉發是一個很複雜的過程. 簡單的說, 一個組播缺省隻能在一個網段內傳輸,不能跨網段。
更何況在一些雲計算的環境,集群的分布往往是跨網段的,甚至是跨地域的.這時更難以依賴這種初級的組播同步。
總之,分布式集群架構,建議使用Redis或者Memcache緩存實現。
下一篇文章繼續講 基於 Nginx + Shiro + Redis 實現負載均衡集群(成績報告查詢係統升級篇)
聲明：本文內容大體流程僅供參考，有些並未涉及到具體代碼實現。
最後更新：2017-04-01 17:13:51