問：jwt與token+redis，哪種方案更好用？

其實JWT就是Json Web Token，就是Token的典型方式。題主的JWT和Token+Redis的區(qū)別，其實都是Token，只是JWT的可靠性保障是來源于加密算法(對稱加密和非對稱兩種)，而Token+Redis的方案是依靠的后臺數(shù)據(jù)存儲。這兩個本質(zhì)也就帶來了使用上的區(qū)別：

1 JWT是去中心化的，不需要任何后臺數(shù)據(jù)的共享，第三方認證、跨數(shù)據(jù)中心認證、微服務(wù)等，都適合采用JWT的方式，當(dāng)然，因為是去中心化的，不是實時驗證，所以本質(zhì)上來說token的主動過期是做不到的(要做到就會違背初衷)

2 Token+Redis是中心化的，要能識別token必須能訪問該Redis，除非是有特別需求，要求每次token都實時檢測，否則的話還是選擇JWT，畢竟是成熟通用的技術(shù)，溝通維護成本也低，對開發(fā)者也友好一些。

當(dāng)然，一定要聊細節(jié)，其實還有很多，其他很多回答也都非常精彩。對比兩種技術(shù)這種話題，抓住根本是關(guān)鍵，至于怎么選擇，根據(jù)項目實際情況來就好了~

問：電商網(wǎng)站中，50W-100W高并發(fā)，秒殺功能是怎么實現(xiàn)的？

秒殺的套路千千萬，反正物品肯定滿足不了需求，搶不到東西也是正常的，所以套路可以全鏈路安排！下面以100w并發(fā)為例：

1 瀏覽器端直接隨機過濾下，比如隨機數(shù)1到100，是11就通過，完全看臉，1/100的概率能成功提交請求，開搶3s后不再成功，這會兒并發(fā)只剩下1w了

2 Nginx的反向代理層，都可以相同思路過濾下，檢測下某個請求參數(shù)，留個1/10的概率通過，其他直接返回已搶光，并發(fā)能進入服務(wù)器的只有1000了

3 程序入口來個布隆過濾器，篩掉重復(fù)請求，到業(yè)務(wù)層了，直接基于Redis管理下庫存，每次請求就直接decr返回庫存現(xiàn)狀，1000的并發(fā)單機就能hold住

4 庫存等于0了，就在程序入口處攔截請求，后續(xù)請求也就不進業(yè)務(wù)處理環(huán)節(jié)了

輕松嗎？什么，還有問題

下單后放棄？沒關(guān)系，redis來個incr，入口處就又開始放請求進來了；

Redis掛了？來個集群嘛，1000并發(fā)能掛太難了，再說數(shù)據(jù)都在數(shù)據(jù)庫呢，出不了大事兒，直接返回秒殺結(jié)束就是

情況還有很多很多，都是可以解決的，思維發(fā)散就好，以上也只是一種簡單粗暴的設(shè)計方式，拋磚引玉下

更多精彩問答，

歡迎大家關(guān)注Eleven老師的知乎

進入知乎 搜索添加Eleven

總結(jié)

以上是生活随笔為你收集整理的jwt与token+redis，哪种方案更好用？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。