jwt与token+redis，哪种方案更好用？

问：jwt与token+redis，哪种方案更好用？

其实JWT就是Json Web Token，就是Token的典型方式。题主的JWT和Token+Redis的区别，其实都是Token，只是JWT的可靠性保障是来源于加密算法(对称加密和非对称两种)，而Token+Redis的方案是依靠的后台数据存储。这两个本质也就带来了使用上的区别：

1 JWT是去中心化的，不需要任何后台数据的共享，第三方认证、跨数据中心认证、微服务等，都适合采用JWT的方式，当然，因为是去中心化的，不是实时验证，所以本质上来说token的主动过期是做不到的(要做到就会违背初衷)

2 Token+Redis是中心化的，要能识别token必须能访问该Redis，除非是有特别需求，要求每次token都实时检测，否则的话还是选择JWT，毕竟是成熟通用的技术，沟通维护成本也低，对开发者也友好一些。

当然，一定要聊细节，其实还有很多，其他很多回答也都非常精彩。对比两种技术这种话题，抓住根本是关键，至于怎么选择，根据项目实际情况来就好了~

问：电商网站中，50W-100W高并发，秒杀功能是怎么实现的？

秒杀的套路千千万，反正物品肯定满足不了需求，抢不到东西也是正常的，所以套路可以全链路安排！下面以100w并发为例：

1 浏览器端直接随机过滤下，比如随机数1到100，是11就通过，完全看脸，1/100的概率能成功提交请求，开抢3s后不再成功，这会儿并发只剩下1w了

2 Nginx的反向代理层，都可以相同思路过滤下，检测下某个请求参数，留个1/10的概率通过，其他直接返回已抢光，并发能进入服务器的只有1000了

3 程序入口来个布隆过滤器，筛掉重复请求，到业务层了，直接基于Redis管理下库存，每次请求就直接decr返回库存现状，1000的并发单机就能hold住

4 库存等于0了，就在程序入口处拦截请求，后续请求也就不进业务处理环节了

轻松吗？什么，还有问题

下单后放弃？没关系，redis来个incr，入口处就又开始放请求进来了；

Redis挂了？来个集群嘛，1000并发能挂太难了，再说数据都在数据库呢，出不了大事儿，直接返回秒杀结束就是

情况还有很多很多，都是可以解决的，思维发散就好，以上也只是一种简单粗暴的设计方式，抛砖引玉下

更多精彩问答，

欢迎大家关注Eleven老师的知乎

进入知乎 搜索添加Eleven