簡述
通常的Token在服務(wù)器端的實現(xiàn)方式有這幾個：
- 用SessionID實現(xiàn)Token的功能
- 生成Token存在數(shù)據(jù)庫(關(guān)系型數(shù)據(jù)庫)
- 生成Token存在Redis(非關(guān)系型數(shù)據(jù)庫)
- 使用Json Web Token (JWT)
下面分析一下各個存儲方式的優(yōu)缺點
Session
對于每個會話，服務(wù)器會生成Session保存在服務(wù)器上，而對應(yīng)的SessionID自動通過HTTP頭中的Set-Cookie返回保存在瀏覽器等客戶端中，每次請求客戶端都會帶上SessionID，然后服務(wù)器通過SessionID找到Session判斷用戶狀態(tài)。
優(yōu)點：
- 操作簡單，一般小項目使用起來完全沒問題
缺點：
- Session文件可能需要共享。當(dāng)需要多個服務(wù)器做負(fù)載均衡時麻煩就來了，由于Session以文件方式存儲在服務(wù)器硬盤中，就會出現(xiàn)只有一個服務(wù)器存在會話Session文件，而其他服務(wù)器沒有該會話的Session文件的情況。
(解決該問題可以參考https://www.cnblogs.com/wangtao_20/p/3395518.html) - 一些客戶端不會自動保存和發(fā)送SessionID，如小程序，需要手動在請求頭Set-Cookie中加上
生成Token并存在數(shù)據(jù)庫(關(guān)系型數(shù)據(jù)庫)
如字面意思，就是手動生成Token串存在數(shù)據(jù)庫中，將Token返回客戶端并且每次客戶端請求都帶上這個Token。
優(yōu)點：
- 由于Token在數(shù)據(jù)庫中而不像Session存在本地，方便管理與多服務(wù)器支持。
缺點：
- 驗證效率問題。每次驗證用戶狀態(tài)都要走數(shù)據(jù)庫，增加了數(shù)據(jù)庫的負(fù)擔(dān)，不過在用戶量不是特別龐大的情況下沒問題（畢竟大部分用戶請求都要經(jīng)過數(shù)據(jù)庫，順便驗證一下問題不大）
生成Token并存在Redis(非關(guān)系型數(shù)據(jù)庫)
也是手動生成Token，但這次是存在Redis中而不是關(guān)系數(shù)據(jù)庫中。
優(yōu)點：
- 由于Token在Redis中而不像Session存在本地，方便管理與多服務(wù)器支持。
- 由于Redis跑在內(nèi)存中，驗證效率快上很多
缺點：
- Redis的快的優(yōu)點也導(dǎo)致了它的缺點，Redis跑在內(nèi)存中，一旦Redis服務(wù)器崩了，此時一些數(shù)據(jù)就會丟失
使用Json Web Token (JWT)
簡單來說JWT就是通過可逆加密算法，生成一串包含用戶、過期時間等關(guān)鍵信息的Token，每次請求服務(wù)器拿到這個Token解密出來就能得到用戶信息，從而判斷用戶狀態(tài)。
優(yōu)點：
- 無論哪個服務(wù)器解出來的Token信息都一樣，而且不需要做任何查詢數(shù)據(jù)庫操作，省掉了數(shù)據(jù)庫/Redis的開銷
缺點：
- 無法主動更新Token的有效性，只要用戶傳回來的Token沒有過期，服務(wù)器就會認(rèn)為這個用戶操作是有效的。比如一下這個場景：某用戶被封禁，此時該用戶所有操作都應(yīng)該被禁止，但是由于之前發(fā)給用戶的JWT Token還沒有過期，服務(wù)器仍然認(rèn)為該用戶操作合法。有一個解決方案是維護(hù)一張JWT黑名單表，只有沒在表上的用戶的JWT是有效的。但是隨之而來又有一個問題便是這個JWT黑名單表存在哪里。存在服務(wù)器，那么又要搞多服務(wù)器同步。存在關(guān)系數(shù)據(jù)庫，那么查數(shù)據(jù)庫效率又低。存在Redis，則又回到了Token丟失問題。。
- 其實解析JWT Token也是消耗服務(wù)器CPU的
總結(jié)
個人意見是大型項目可以使用Token+Redis/Token+數(shù)據(jù)庫，這個Token可以是自己生成，也可以是JWT Token，只不過驗證還是走Redis/數(shù)據(jù)庫。對于要求不高的項目，Session/JWT也是可以勝任的。
