基於session的登陸權限控制及redis緩存引入

1、容器端session

　　一、當瀏覽器第一次訪問服務器時，使用request.getSession()方法，服務器會建立一個Session對象和具備JSESSIONID鍵值的cookie，成功返回後瀏覽器會獲得一個包含sessionId的Cookie。

　　二、瀏覽器再次訪問服務器時，會攜帶具備JSESSIONID屬性的cookie到服務器，再次使用request.getSession()方法時能夠經過sessionId找到session對象。

2、session用於權限驗證

　　一、在Rquest.getSession()得到的session對象中存入用戶權限標識、如已登陸標識、角色權限標號等。

　　二、再次登陸時經過cookie中的JSESSIONID得到session對象，若是成功得到，則查找當前對象中是否有已登陸標識、無則視爲未登陸狀態，阻止某些請求。

　　三、2過程當中有存在登陸標識的session對象再進一步根據角色權限信息判斷是否繼續當前請求。

3、容器端session問題

　　一、多臺服務器的狀況下共享問題，即第一次登陸時，請求被分到A服務器，那麼session對象僅保存在A服務器中，下次訪問到B服務器無session對象，會被當作未登陸狀態。

　　a)這裏負載均衡會根據哈希一致性原理將同一客戶端的請求分配到同一個服務器上，因此在正常狀況下，登陸在A服務器，存登陸信息的session在A服務器，下次訪問繼續請求到A服務器，這個能夠保證。

　　　　b）可是在非正常狀況下，服務器down掉，或者某些奇葩的緣由session丟失，用戶就會在訪問過程當中屢次被要求登陸，嚴重影響用戶體驗。

　　二、最終Session可能會是服務器性能影響的一個重要指標，若是單點的服務商用戶量比較大，且隨着業務的複雜度增長，每一個登陸的用戶都會寫入比較多的數據放入會話中(好比權限，通知，消息等）這樣服務器容器就須要開闢一塊很大的內存來存放這些衆多的用戶信息，並且用戶在客戶端不停的切換頁面查詢數據，後臺就會在不停的循環查詢存放全部會話的變量，會極大的影響服務器的效率和負載。

4、引入redis的目的

　　一、基本思路、在第一次登陸、使用request.getSession()得到session對象並設置後，將對應的信息已鍵值對的形式存入redis中（鍵：jsessioniid，值：session對象的json字符串），

　　二、爲減少服務器負擔，服務器端的session對象僅保留簡單的登陸標識，其餘共享信息，如權限、通知、消息保留在redis服務器中。、

　　三、再次訪問過程，登陸身份信息先拿cookie中的jsessionId去resdis中尋找，找不到的狀況下才去服務器中找對應的session對象，如存在對應的登陸標識，再將複雜的身份信息查詢後緩存回redis中。

　　四、服務器掛掉的狀況下，用戶並不須要從新登陸，redis中仍然保存着登陸信息。redis掛掉的狀況下，登陸機制也不會崩潰，服務器仍然保留着基本的登陸標識。