mysql查詢時間失效，session共享有什么方案么？

session同步（復制）l 優點(1) web-server（Tomcat）原生支持，只需要修改配置文件l 缺點(1) session同步需要數據傳輸，占用大量網絡帶寬，降低了服務器群的業務處理能力(2) 任意一臺web-server保存的數據都是所有web-server的session總和，受到內存限制無法水平擴展更多的web-server。

(3) 大型分布式集群情況下，由于所有web-server都全量保存數據，所以此方案不可取。

Session 復制原理的解釋:

網絡中有三種通訊模式:

(1) 單播

(2) 廣播

(3) 組播:地址 224.0.0.0 ~ 224.0.0.255 為用戶可用的組播地址

session數據存儲在客戶端cookiel 優點(1) 服務器不需存儲session，用戶保存自己的session信息到cookie中。節省服務端資源l 缺點(1) 都是缺點，這只是一種思路。n 具體如下：(1) 每次http請求，攜帶用戶在cookie中的完整信息，浪費網絡帶寬(2) session數據放在cookie中，cookie有長度限制4K，不能保存大量信息(3) session數據放在cookie中，存在泄漏、篡改、竊取等安全隱患(4) 這種方式不會使用。 反向代理hash一致性原理：利用反向代理使得同一個用戶的請求落在一臺固定的服務器上，不要發生服務器切換即可，服務器之前內存session中的數據還是在的；可以有兩種實現；3.1）、四層代理ip_hash原理：反向代理層使用用戶ip來做hash，以保證同一個ip的請求落在同一個web-server上3.2）、七層代理根據http協議任意業務字段自定義hash原理：反向代理使用http協議中的某些業務屬性來做hash，例如sid，city_id，user_id等，能夠更加靈活的實施hash策略，以保證同一個瀏覽器用戶的請求落在同一個web-server上3.3）、優缺點優點：只需要改nginx配置，不需要修改應用代碼負載均衡，只要hash屬性的值分布是均勻的，多臺web-server的負載是均衡的可以支持web-server水平擴展（session同步法是不行的，受內存限制）缺點session還是存在web-server中的，所以web-server重啟可能導致部分session丟失，影響業務，如部分用戶需要重新登錄如果web-server水平擴展，rehash后session重新分布，也會有一部分用戶路由不到正確的session但是以上缺點問題也不是很大，因為session本來都是有有效期的。所以這兩種反向代理的方式可以使用后端統一存儲session數據原理：將session存儲在web-server后端的存儲層，數據庫或者緩存；但是由于session是頻繁讀取的數據而且有過期時間，所以我們一般存在Redis緩存中，而不是MySQL等dbl 優點：n 沒有安全隱患n 可以水平擴展，數據庫/緩存水平切分即可n web-server重啟或者擴容都不會有session丟失l 不足n 增加了一次網絡調用，并且需要修改應用代碼；如將所有的getSession方法替換為從Redis查數據的方式 總結l 保證session一致性的架構設計常見方法：n session同步法：多臺web-server相互同步數據n 客戶端存儲法：一個用戶只存儲自己的session數據到cookie中n 反向代理hash一致性：u 做，保證一個用戶的請求落在一臺web-servern 后端統一存儲：web-server重啟和擴容，session也不會丟失l 我們最終選擇使用“后端統一存儲這種方式”SpringSession是基于“后端統一存儲”這種方式來管理session的； 只需配置一個Filter，SpringSession在Filter中使用裝飾者模式和適配器模式包裝原生request。SpringSession可以選擇使用JDBC、Redis、Hazelcast、MongoDB等方式存儲sessionSpringSession也可以定制請求頭中帶sessionid或者cookie中帶sessionid我們選擇使用Redis存儲session 為什么要使用Spring-session1、傳統方式session問題在傳統單機web應用中，一般使用tomcat/jetty等web容器時，用戶的session都是由容器管理。瀏覽器使用cookie中記錄sessionid，每次發送請求的時候會帶上這個sessionid，web容器根據sessionid找到當時在服務存儲信息時使用的那個Map，以此判斷用戶是否存在會話session。注意：最大的問題是，session存儲在web容器中，被單臺服務器容器管理。在分布式情況下，這會導致什么？當然，如果我們一直玩單機版的應用，不用關心這個問題，但是隨著業務逐漸增大，分布式應用和集群是趨勢。

解決session不一致有很多方案，但多配置復雜或者有明顯的缺點。有了SpringSession，所有的session由SpringSession創建維護，無需我們修改任何代碼，就能在集群環境下使用原生的session方式編程，無侵入、簡單配置和Spring應用無縫整合、對接各種session存儲方案；