不用Redis也能登录？试试这些另类方法，别再死守缓存了

（引用来源：知乎专栏“架构师之路”、个人博客“码农小胖的日常”、开源项目Discourse社区讨论）

咱们今天聊点实在的,一说起用户登录，尤其是那种要记住登录状态、保持会话的，十个程序员里有九个半会脱口而出：用Redis啊！Redis确实又快又好用，像个万能钥匙，但你想过没有，要是项目初期没钱买Redis服务，或者就是个访问量不大的个人小网站，又或者单纯就是不想引入另一个依赖，怕系统变复杂，难道就没办法实现登录了吗？当然不是！今天咱们就抛开Redis，看看还有哪些“土法炼钢”但确实管用的另类方法。

就用数据库，简单粗暴最直接

（引用来源：个人博客“码农小胖的日常”中提到的小型项目实战）

别笑,这方法最实在，用户登录成功，你不是要生成一个代表他身份的令牌（比如叫session_id或token）吗？Redis的做法是把这个令牌和用户信息存在内存里，那不用Redis，我直接往数据库里加一张表，就叫user_sessions，行不行？太行了！

这张表就几个字段：自增ID、用户ID、生成的令牌字符串、过期时间，用户登录成功，你就往这张表里插一条记录，之后每次用户带着令牌来访问，你就去这张表里查一下，看看这个令牌存不存在、有没有过期，如果都对得上，就说明用户是登录状态。

• 优点：实现起来超级简单，跟你业务逻辑用的同一个数据库，不用折腾别的服务，依赖少，出问题了也容易排查，对于一天就几百几千访问量的小网站，数据库完全扛得住，根本感觉不到压力。
• 缺点：确实不如Redis快，因为每次都要走一次数据库查询，如果访问量真的大起来了，频繁读写这张表可能会成为瓶颈，而且你得自己写个定时任务，定期去清理那些已经过期的令牌，不然表会越来越大。

让令牌自己“说话”——JWT

（引用来源：开源项目Discourse社区关于无状态会话的讨论）

这个方法就高级一点了,它根本不需要在服务器端“任何会话信息，JWT（JSON Web Token）是一个标准，它能生成一种特殊的令牌，这个令牌本身就像一张加密的“身份证”，里面就直接编码了用户ID、令牌有效期等信息。

登录成功后,服务器生成一个JWT令牌发给浏览器，浏览器之后每次请求都在HTTP头里带上这个令牌，服务器收到后，不需要去数据库或者任何地方查这个令牌对不对，它只需要用密钥验证一下这个令牌的“签名”是否有效、有没有过期，如果验证通过，就直接相信令牌里包含的用户信息。

• 优点：服务器彻底“无状态”了，特别适合做分布式部署，因为任何一台服务器只要持有密钥都能验证令牌，不需要共享会话数据，性能也好，省去了每次查询会话存储的步骤。
• 缺点：令牌一旦发出去，服务器没法主动让它失效（比如你想强制某个用户下线就不好办），只能等它自己过期，而且令牌里不宜存放敏感信息，因为内容虽然是加密的，但本质上是可解码的（只是不能篡改）。

老派但稳定的服务器会话Session

（引用来源：知乎专栏“架构师之路”中对传统技术的回顾）

在Redis这类内存数据库流行之前,大家是怎么做的？用的是Web服务器自带的会话管理功能，比如PHP的$_SESSION，Java里的HttpSession，它的原理是，服务器在内存里开辟一块空间存放每个用户的会话数据，同时给浏览器一个名为JSESSIONID（Java为例）的Cookie，浏览器带着这个Cookie来，服务器就能找到对应的内存数据。

• 优点：成熟稳定，语言或框架通常原生支持，开箱即用，非常方便。
• 缺点：默认情况下会话数据是存在单台服务器的内存里的，如果你只有一台服务器，没问题，但一旦做了负载均衡，用户下一次请求可能被分配到另一台服务器上，那台服务器内存里就没有他的会话数据了，登录状态就丢了，虽然可以通过配置“会话粘滞”或“会话复制”来解决，但又增加了复杂性。

剑走偏锋的客户端存储

（引用来源：一些前端技术博客关于替代方案的探讨）

还有一种思路,就是把一些状态直接存在客户端（浏览器），登录成功后，你不是把用户ID、昵称这些信息加密后直接存到Cookie里吗？或者用浏览器的Local Storage存更复杂的数据，每次请求，浏览器自动带上Cookie，或者前端主动从Local Storage读取数据拼接到请求里。

• 优点：极大减轻服务器压力，服务器完全不用管会话存储。
• 缺点：安全性是最大问题，存在客户端的数据有被用户篡改的风险（尽管可以加密签名，但复杂度高），而且Cookie有大小限制，Local Storage的数据需要前端手动处理，这种方法一般只适用于对安全性要求不高的场景，或者作为辅助手段。

总结一下

所以你看,离开了Redis，登录这座山照样能爬，选择哪种方法，完全看你的菜谱（项目需求）：

• 要是做个毕业设计、个人博客，用数据库存会话最省心。
• 要是想搞前后端分离、做移动端API，JWT是时髦又高效的选择。
• 要是传统的单体应用，并且确定短期内不会扩展成多台服务器，用语言自带的服务器会话也没毛病。
• 至于客户端存储，玩玩可以，真要用于核心登录，得十二分小心。

Redis是个好工具,但绝不是唯一的工具，了解这些“备胎”方法，不仅能让你在资源受限时游刃有余，更能帮你理解登录机制的本质，别再死守缓存了，根据实际情况，选择最合适的那把钥匙吧！