在討論session跨域共享問題之前，我們首先要了解session做了什麼，沒做到什麼

1. HTTP是無狀態的，也就是說伺服器不知道誰訪問過他，但是有時候，又需要我們去保留這個狀態比如說使用者的登入資訊，如果每次訪問都要登陸，這個使用者體驗實在是太糟糕了，session就解決了這個問題，他把使用者登陸資訊維護在服務端，會生成一個JSessionID給客戶端，客戶端下次訪問的時候就帶著這個JSessionID，服務端根據這個ID去查詢使用者資訊。
2. 當然，session的缺點也很明顯，session是存在伺服器的記憶體中的，如果session過多會影響伺服器的效能。因為session只在一臺伺服器裡，當有多臺伺服器的時候，訪問別的伺服器肯定會失敗。

明確了session所做的事以及它的缺陷之後，解決session存在的問題就容易多了，下面我簡要說一下5種解決方案

• Session Sticky
• Session複製
• Session集中儲存
• Cookie
• Token

Session Sticky :是指讓同一客戶端的請求，落在同一臺伺服器上，因為不會落在別的伺服器上，所以自然就不會出現跨域問題。但是這個方案的缺點非常的明顯，就是不管比採用什麼演算法，使用者的請求落在哪一臺伺服器上都是由使用者來決定的，可能會造成單點壓力，並且如果一臺伺服器出問題，可能會造成一片區域的人無法訪問

Session複製 ：是指伺服器之間互相同步session資訊

Session集中儲存：是指把Session集中儲存在一個第三方的伺服器中，可以是Redis,可以是資料庫或是其它什麼東西。當需要訪問的時候，都去這個伺服器去查。這樣做也有不小的缺點，首先是單點問題，如果這個伺服器宕機，那麼所有的服務都是不可用的，所以這裡必須做叢集，會浪費伺服器資源。還有一點是，每次驗證都需要來這個伺服器來查，會憑白增加一次

Cookie ：狀態資訊不再儲存在服務端，而是儲存在客戶端，客戶端每次訪問伺服器的時候，把這個資訊帶給伺服器。但是Cookie也有不少問題，最被人關注的就是安全問題，因為資訊是儲存在客戶端的，就比較容易被人盜取、篡改，當然這些安全問題都是有解決方案的，這不是限制Cookie的主要原因，真正限制Cookie的原因是很多裝置**不支援**Cookie

Token :和Cookie類似，Token也是由客戶端來維持狀態的，資訊儲存在客戶端內，具有平臺無關性。Token實質上是服務端給客戶端的一個字串，上面包含著一些驗證資訊，相當於一個身份令牌，你拿著這個令牌就能得到他的服務。相比較於Cookie，Token更加的靈活，可以在任何地方生成，基於Token的許可權系統是非常容易實現的

當然，解決方案並不只上面5種，我只是列舉了幾個有代表性的。

方案是用來解決問題的，上面的這些方案沒有好不好的說法，只有合不合適的說法，合適的才是最好的。