CAS單點登入十二集群部署

通過前面一系列的文章介紹，關於cas的基本知識點大致介紹完了，今天講解一下cas中集群的部署。我們知道當訪問量越來越來多時，我們需要對cas服務的效能進行提公升，而通過集群的方式提高cas的服務效能是比較直接的。

在部署的服務中，通過使用nginx來實現負載均衡分發到cas具體的服務上，但是我們知道前端每次訪問時是隨機訪問分配的，所以就會出現session共享問題，同時在不同cas中的tgt分配的ticket也不同，因為預設ticket是儲存在記憶體中的。所以我們需要統一管理session和ticket來解決問題。

今天我們來講解一下cas的集群部署的使用，在開頭我們提到了session和ticket儲存管理的方式，在集群下目前使用redis方式，是比較流行和簡單的方式，所以今天我們採用這種方式來解決。

在前面的第五章，我們講解過service配置不同方式的持久化，這裡的session和ticket方式其實也大致類似，我們通過檢視官方文件，可以發現官方提供了多種不同ticket的持久化方式，包括：

一系列的操作方式，可以根據自己的需求選擇合適的方式即可，這裡我們採用redis配置。

首先引入具體的依賴：

org.apereo.cas cas-server-support-redis-ticket-registry

$

## # ticket registry配置 #cas.ticket.registry.redis.host=localhost cas.ticket.registry.redis.database=0 cas.ticket.registry.redis.port=6379 cas.ticket.registry.redis.password= cas.ticket.registry.redis.timeout=2000 cas.ticket.registry.redis.usessl=false cas.ticket.registry.redis.usepool=true cas.ticket.registry.redis.pool.max-active=20 cas.ticket.registry.redis.pool.maxidle=8 cas.ticket.registry.redis.pool.minidle=0 cas.ticket.registry.redis.pool.maxactive=8 cas.ticket.registry.redis.pool.maxwait=-1 cas.ticket.registry.redis.pool.numtestsperevictionrun=0 cas.ticket.registry.redis.pool.softminevictableidletimemillis=0 cas.ticket.registry.redis.pool.minevictableidletimemillis=0 cas.ticket.registry.redis.pool.lifo=true cas.ticket.registry.redis.pool.fairness=false

redis的位址和密碼更改給相應的配置即可，然後我們啟動cas服務。

當我們登入成功後，可以在redis相應的客戶端檢視到具體的資訊，如下：

同時當我們退出登入後，redis中的ticket也被銷毀掉了。

session的持久化和ticket類似，官方同時也為我們提供了多種方式可選。如下：

這裡我們選擇redis方式進行配置，同樣新增依賴。

org.apereo.cas

$

##
# session redis配置
#cas.webflow.autoconfigure=true
cas.webflow.alwayspauseredirect=false
cas.webflow.refresh=true
cas.webflow.redirectsamestate=false
cas.webflow.session.locktimeout=30
cas.webflow.session.compress=false
cas.webflow.session.maxconversations=5
spring.session.store-type=redis
spring.redis.host=localhost
spring.redis.password=
spring.redis.port=6379

同樣的將redis更改為相應的配置即可。重啟服務，可以發現redis中的session儲存在其中了。

現在我們測試一下集群環境下的cas是否可用，為了方便測試，我們關閉掉https，在tomcat中的server.xml配置了配置http的設定，這裡配置了8080和8081埠。

如果cas要使用http還需要配置，如下：

##
# 允許http配置
#cas.tgc.secure=false
cas.warningcookie.secure=false

重新啟動服務，現在我們啟動了2個cas服務來模擬集群情況，分別在8080和8081埠。

通過新增加密配置，如下：

cas.tgc.crypto.enabled=false

注意：使用redis進行session的快取的時候，起初沒有配置這個的時候(當然.signing.key和encryption.key也沒有配置)。發現進去無法進行共享session，這是因為cas每次啟動的時候會隨機生成這兩個key的值，這樣集群部署的時候就會出現這兩個值不一樣。當然除了配置false以外，還有一種方式就是將這兩個值賦予固定的值。

在nngix中主要配置upstream引數，預設按照輪詢排程的策略選擇組內伺服器處理請求。

在http模組下配置如下：

upstream cas

然後再在server模組中配置如下：

server 
# .....
}

然後我們啟動nginx服務，訪問http://localhost:81/，然後輸入資訊進行登陸。發現並不能成功登陸cas，如果我們更改nginx中的配置如下：

upstream cas

重啟nginx發現登入成功！！奇怪了為啥我們統一了session使用redis管理了，怎麼還需要配置ip_hash，那還不如不進行統一管理redis來管理session了。我們知道ip_hash是對每個請求按訪問的ip的hash結果分配，這樣每次客戶端ip固定訪問乙個後端伺服器，可以解決session的問題。

那是因為我們cas管理session沒起作用？我們嘗試更換http://localhost:8081或http://localhost:8080登入，重新整理其他頁面http://localhost:81發現登入成功！然後退出乙個cas服務，其他所以cas服務都退出了。那說明redis中的session起作用了，可為啥還是不行？

這個是因為cas每次登入需要重新整理多次才可以登入成功，也就是登入過程發起了多次訪問。所以當第一次訪問http://localhost:8081，第二次又跑到http://localhost:8080，所以在http://localhost:81登入總是失敗。

**例項：chapter11

CAS單點登入十二集群部署

cas 單點登入，集群部署遇到的問題總結

CAS單點登入單點登出退出登出（十二）

CAS單點登入

CAS單點登入 十二 集群部署

cas 單點登入，集群部署遇到的問題總結

CAS單點登入 單點登出 退出 登出（十二）

CAS單點登入

相關推薦

CAS單點登入十二集群部署

CAS單點登入單點登出退出登出（十二）