JWT为何比Session数据更具可扩展性？关于密钥存储的疑问

你的疑问切中了Session和JWT在服务器端存储需求的核心差异，下面拆解关键原因：

• 存储量级与增长模式不同
  Session需要为每个用户存储独立的会话数据（比如用户ID、权限、过期时间等），用户量越大，集中存储的数据量线性增长，存储成本和读写压力也随之飙升。而JWT的验证密钥是全局通用的（比如对称加密的一个密钥字符串，或者非对称加密的一对公/私钥），不管用户量多少，只需要存储极少的密钥资源，完全不存在随用户量增长的存储压力。

• 访问模式的性能差异
  使用Session时，每次用户请求都要去集中存储（比如Redis、数据库）查询会话数据，属于高频读写操作，当服务实例扩容到几十上百个时，集中存储很容易成为性能瓶颈。而JWT的密钥通常是服务实例启动时就加载到本地内存，验证令牌时直接本地计算验签，不需要每次请求都访问集中存储，彻底消除了这一瓶颈，服务实例可以无限横向扩展，不需要依赖共享存储的同步能力。

• 管理复杂度差异
  Session的集中存储需要解决多实例间的数据同步、一致性、分片扩容等问题，比如Redis集群的维护、Session复制的开销。而JWT的密钥是全局配置项，所有服务实例使用同一套密钥，就算需要轮换密钥，只需要全局统一更新一次即可，操作成本极低，不需要维护复杂的会话数据存储集群。

简单来说，JWT的扩展性优势本质是把会话状态从服务器端转移到了客户端，服务器只需要持有验证身份的密钥，而不需要保存每个用户的会话信息——这和Session需要维护大量用户级会话数据的模式完全不同，密钥的存储需求和管理成本和会话数据不在一个量级。

内容的提问来源于stack exchange，提问作者bridgemnc