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

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

1 JWT是去中心化的，不需要任何后臺(tái)數(shù)據(jù)的共享，第三方認(rèn)證、跨數(shù)據(jù)中心認(rèn)證、微服務(wù)等，都適合采用JWT的方式，當(dāng)然，因?yàn)槭侨ブ行幕?#xff0c;不是實(shí)時(shí)驗(yàn)證，所以本質(zhì)上來說token的主動(dòng)過期是做不到的(要做到就會(huì)違背初衷)

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

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

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

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

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

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

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

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

輕松嗎？什么，還有問題

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

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

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

更多精彩問答，

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

進(jìn)入知乎 搜索添加Eleven

總結(jié)

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

如果覺得默认站点網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將默认站点推薦給好友。