有人問，遠光天鵲作為乙個資料整合產品，是怎麼實現會話共享的？
其實我們實現會話共享有很多種方案。
在分布式集群應用中通常通過配置會話保持等設定來保證使用者持續訪問，這樣配置具有簡單快捷的優點，但可能會出現應用負載分配不均的情況，從而導致某些節點繁忙，某些節點閒置，而且穩定性有待考量。今天我們來介紹遠光天鵲的另一種實現方案：使用redis儲存來實現session共享。
spring session是spring家族中的乙個子專案，spring session提供了用於管理使用者會話資訊的api和實現。它把servlet容器實現的httpsession替換為spring-session，專注於解決 session管理問題，session資訊儲存在redis中，可簡單快速且無縫的整合到我們的應用中。
首先，要在web.xml配置過濾器。
springsessionrepositoryfilter
org.springframework.web.filter.delegatingfilterproxy
springsessionrepositoryfilter
/*然後，根據文件實現redis相關配置資訊載入。
以上是根據sping官方幫助文件操作來使用redis實現session 共享，但有時候生產環境沒有redis或者redis配置錯誤怎麼辦，這時又要使用此前的舊方案進行會話保持，但是很顯然目前做的這些事只能使用redis 來儲存session，這就需要我們進行一些改造來滿足沒有redis的環境還能正常啟動的需求。
來看下spring session的原理：
可以看出關鍵點在delagatingfilterproxy這個入口，閱讀delegatingfilterproxy的原始碼，發現這個類名副其實，就是乙個委託過濾器**，目的是通過配置過濾器的名稱查詢真正實現功能的filter，然後完成該filter的功能。找不到過濾器時就會直接丟擲異常導致整個應用啟動失敗。如果有沒有redis環境，那遠光天鵲資料整合平台豈不是使用不了？顯然這樣實現是不合理的。
來，我們將原來的**進行改造，設定乙個@componentscan掃瞄redis配置所在的包，通過自定義excludefilter來控制是否掃瞄redis相關的配置bean,excludefilter內的邏輯則是嘗試讀取redis配置，沒有配置redis或者嘗試連線redis失敗則不會建立redis配置的相關bean，也就不會建立sessionrepositoryfilter。
繼承delegatingfilterproxy，重寫initdelegate和invokedelegate方法，未找到sessionrepositoryfilter時進入過濾器鏈的下乙個過濾器邏輯。
這樣我們的遠光天鵲就完美的實現在有redis的情況下使用redis做session共享，和沒有redis的情況下可以使用其他的會話共享方案（不至於無法啟動），遠光天鵲使用redis做會話共享就是這麼簡單。
session共享redis儲存設計與實現
session的實現原理簡介 背景 1.由於http協議是無狀態的，服務端如何識別客戶端請求呢，只能依靠http報文中新增部分頭字段來實現請求識別 如何在請求body或這引數中設定會員引數，伺服器端會話就與自定義的會員識別繫結到一起 2.基於瀏覽器的web應用，請求都是有瀏覽器發起的，貌似也不能手動...
使用redis作為session的儲存方式
1 準備 a.安裝好redis 啟動指令碼如下 redis server redis.windows.conf 雙擊開啟redis cli.exe，用自帶的客戶端工具進行測試 127.0.0.1 6379 set aaa xyz ok 127.0.0.1 6379 get aaa xyz 127.0...
tamcat多個應用實現session共享
由於專案需要乙個應用訪問另乙個應用進行許可權驗證，所以研究了一下session共享，session共享能夠使得乙個應用系統訪問另乙個應用系統。在乙個tomcat中部署兩個應用，設定crosscontext true，讓兩個應用可以在tomcat中交叉使用上下文環境。server.xml 然後用其中乙...