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中查詢用戶信息，如果有則繼續，沒有則登錄
淘寶的二級域名：
最后，廣告時間，咩哈哈 兒童進口爬行墊，床上用品，無毒綠色環保，媽媽的最佳選擇！
