SSO，Single Sign On，也就是單點登入，保證一個賬戶在多個系統上實現單一使用者的登入

現在隨著網站的壯大，很多服務會進行拆分，會做SOA服務，會使用dubbo做微服務，或者簡單的小型分散式，

這樣在服務與服務之間，或者系統與系統之間都是通過HTTP或者restful來進行通訊的，

在以往的單系統應用中，我們都是把user存入session中的，需要用到的時候隨時取，如果取不到就跳轉到登入註冊頁面，非常簡單的原理

但是在現如今的分散式應用中，如何保證session同步呢？

比如訂單服務是在 order.jd.com

購物車服務在 cart.jd.com

那麼這2個二級域名下的使用者資訊如何實現同步呢？

解決方案：

1. tomcat有一個session同步方案，就是一個傳播機制，打個比方有A B C 3臺tomcat，這3臺tomcat的user資訊都在session中並且保持一致，如果其中一臺的user資訊變化了，那麼就會傳播至另外兩臺，則實現同步，這樣做沒問題，但是僅僅只是在做tomcat叢集的時候tomcat很少的時候會用，一旦叢集增大，有100臺，那麼就互相傳播吧，傳播是需要效能損耗的，那麼整個網站的效能就會被拉低，你的網站在你的網路風暴中就會暈死

2. nginx 非粘性session，說穿了就是一個session繫結傳播，起初user的session在tomcatA上，tomcatA宕機了，那麼session會把所有的資訊傳播到tomcatB，以此實現session共享，但是這也有個問題，就是傳播的時候需要等待，快的時候1分鐘左右，慢的時候要5分鐘，使用者的耐性有限，所以也不能這麼做

3. 自己研發一套session高效能共享系統，我見過有這麼做的公司，但是需要時間人力成本，所以不建議，如果你是BAT，隨意~

4. SSO解決方案，目前比較流行的方案，自行開發一套單點登入系統，比如就使用 sso.jd.com，可以在這個二級域名下進行登入和註冊，登入和註冊都是以restful形式，為了可以同時提供給cms以及手機端的支援

登陸後把使用者的相關資訊存入redis，redis設定好過期時間，key為一個token，使用uuid，uuid生成後需要存入cookie中，失效時間隨意定，但是再登入後需要重置redis和cookie中的失效時間

京東的實現：

sso的登入系統

sso的註冊系統（京東是兩套都分開了，這樣布個叢集怎麼也得至少4臺嘛）

首頁

商品(商品詳情應該都是生成的靜態頁面)

交易系統

這些都實現了sso，在soa各個系統中user可以隨意走

攔截器配置：

在需要user資訊的時候肯定需要使用到攔截器，如果獲取不到user資訊，那麼就跳轉到登入頁面，但是需要注意的是需要把原頁面作為redirectUrl暫時儲存，登陸成功後需要跳轉

獲取user的時候就是從cookie中讀取token，呼叫sso服務從redis中查詢使用者資訊，如果有則繼續，沒有則登入

淘寶的二級域名：