1.傳統系統登錄
user ----> server1
即用戶user在服務server1上輸入登錄名、密碼等信息；server1完成用戶信息校驗，並將對應信息寫入server1的session中。
問題：分佈式系統，微服務架構中，在server1中完成登錄，但是訪問server2時仍需登錄。
2.分佈式架構模型下的登錄問題剖析
常見的如圖，將一個項目，分爲多個server，部署在不同的服務器。如wucenter，部署在3個服務器上，即server1 、server2 、server3等。通常會使用Nginx進行負載均衡，默認爲便利的方式，例本次請求分發至server1，下次分發至server2 ，下下次分發至server3。當用戶在server1完成登錄操作後，下次請求getPhone操作，此時請求被分發至server2，在傳統登錄模型中，由於server2中不含有在server1登錄後保存的session信息，此時仍需登錄。
3.處理方案
a. iphash的處理方案：
即在Nginx中，將請求來訪的Ip和對應的server進行綁定，從而保證同一ip地址的請求均是在同一個服務器下，避免了分發不同請求時的session問題。
問題：server1宕機時導致大量的請求失敗，會存在大量的請求被分發至同一服務器導致負載均衡失效。
b.session同步的處理方案
即當用戶在server1完成登錄後，會通過服務器的http請求將session下發至其他的所有的server中。
問題：同一session在各個服務器上保存導致內存佔用問題，網絡通訊延時導致的server2中的session獲取不及時問題
c.redis方式
即通過key-value的方式，在server1完成登錄後，將用戶信息以value的形式，保存在redis中。同時將key發送至客戶端的cookie中。客戶端下次發送請求時，Negix分發到的server，通過cookie中獲取key，進而從redis中獲取對應的用戶信息的操作。
優點：安全
核心問題：key的生成以及發送問題。
以淘寶-天貓爲例剖析redis實現的分佈式登錄問題
1.用戶在淘寶發起登錄請求，輸入賬戶名密碼；
2.淘寶驗證通過後，將對應的用戶信息封裝爲value，併產生一個key，將key-value存儲到一個store系統中；
3.淘寶將對應的key通過cookie發送到客戶端；
4.用戶下次從天貓獲取數據時，http請求會攜帶對應的cookie信息，發送請求到天貓；
5.天貓解析對應的cookie，獲取到對應的key，從store系統獲取對應的用戶信息，進而執行其他操作；獲取失敗則返回登錄頁面，使用戶重新登錄。
cookie的相關操作
1.如果在Cookie中設置了"HttpOnly"屬性，那麼通過JavaScript腳本將無法讀取到Cookie信息，這樣能有效的防止XSS攻擊，讓網站應用更加安全。
2.cookie的相關方法
setName(String name) 修改Session ID的名稱，默認爲"JSESSIONID" setDomain(String domain) 設置當前Cookie所處於的域 setPath(String path) 設置當前Cookie所處於的相對路徑 setHttpOnly(boolean httpOnly) 設置是否支持HttpOnly屬性 setSecure(boolean secure) 若使用HTTPS安全連接,則需要設置其屬性爲true setMaxAge(int maxAge) 設置存活時間，單位爲秒