Redis与session使用及说明

一、传统 Session：服务器内存中的用户状态容器

1. 本质与核心功能

Session（会话）是 Web 服务器（如 Tomcat）为解决 HTTP 协议 “无状态性” 而设计的 服务器端状态存储机制。其核心功能是：

• 为每个用户生成唯一标识（sessionId），关联用户的连续请求；
• 存储用户的临时状态信息（如登录状态、购物车数据、权限标识等），实现 “用户身份跟踪”。

2. 内部结构与核心属性

传统 Session（以 Java Web 的HttpSession为例）本质是 服务器内存中的一个 “键值对对象”，结构可拆解为：

3. 与 Tomcat 服务器的强绑定机制

传统 Session 的存储与管理完全依赖 单个 Web 服务器实例（如 Tomcat），具体表现为：

• 存储位置：Session 数据保存在当前 Tomcat 进程的内存中（非磁盘），属于 “进程内数据”。
• 管理主体：Tomcat 通过内置的SessionManager组件管理所有 Session，包括创建、查询、过期清理等（默认每 60 秒扫描一次过期 Session）。
• 隔离性：不同 Tomcat 实例的内存相互独立，A 服务器的 Session 无法被 B 服务器访问（内存隔离是分布式场景的核心痛点）。

4. 生命周期（以用户登录为例）

创建：用户首次访问需要状态跟踪的接口（如登录）时，Tomcat 生成sessionId，创建 Session 对象并存储用户信息。

传递：服务器通过 HTTP 响应头的Set-Cookie将sessionId发送给客户端，客户端后续请求通过 Cookie 自动携带sessionId。

活跃：用户持续操作时，Tomcat 通过sessionId找到对应 Session，更新lastAccessedTime（避免超时）。

过期 / 销毁：

• 超时：用户超过maxInactiveInterval未操作，Tomcat 自动销毁 Session；
• 主动销毁：调用session.invalidate()（如用户退出登录）；
• 服务器重启：内存中的 Session 全部丢失（无持久化）。

5. 局限性（分布式场景下）

传统 Session 在单机应用中可行，但在分布式部署（多服务器集群）或高并发场景中存在致命问题：

• 会话共享问题：用户请求被负载均衡分发到不同服务器时，新服务器无用户 Session，导致 “登录状态失效”（如用户在 Tomcat A 登录，下次请求到 Tomcat B 时被判定为未登录）。
• 内存限制：Session 存储在服务器内存，用户量增长会导致内存占用飙升，甚至引发 OOM（内存溢出）。
• 无持久化：服务器重启后 Session 全部丢失，用户需重新登录，体验极差。
• 扩展性差：无法通过增加服务器节点分担 Session 存储压力（每个节点仍需存储全量 Session）。

二、Redis：分布式环境下的 Session 存储方案

Redis 是一款 高性能的分布式内存数据库，支持多种数据结构，通过网络提供服务，天生适合替代传统 Session 存储。

1. Redis 的核心特性（为何适合存储 Session）

• 分布式访问：所有应用服务器（如 Tomcat 集群）可通过网络访问同一 Redis 实例（或集群），实现数据共享。
• 高效存储：基于内存操作，读写性能极高（单机 QPS 可达 10 万 +），满足高并发场景。
• 丰富数据结构：支持 String（字符串）、Hash（哈希）等结构，适配 Session 的键值对存储需求。
• 原生过期机制：支持为 Key 设置过期时间，自动清理无效 Session，无需手动维护。
• 持久化能力：通过 RDB（快照）或 AOF（日志）将数据持久化到磁盘，服务器重启后可恢复，避免数据丢失。

2. Redis 存储 Session 的结构设计

将 Session 数据迁移到 Redis 时，需设计合理的 Key 和 Value 结构，确保唯一性、可读性和高效性：

3. 工作流程（替代传统 Session 后）

1. 用户登录：用户提交账号密码，服务器验证通过后生成唯一token（替代sessionId），将用户信息存入 Redis（Key 为login:session:token，Value 为 Hash 结构），并设置过期时间。
2. 客户端存储：服务器将token返回给客户端（通常存入 Cookie 或 LocalStorage），客户端后续请求通过请求头（如Authorization: Bearer token）携带token。
3. 请求验证：应用服务器（如 Tomcat）接收到请求后，从请求中提取token，通过 Redis 查询对应的用户信息：
   • 若存在：延长 Key 的过期时间（如重置为 30 分钟），允许访问；
   • 若不存在（过期或未登录）：拦截请求，返回 “未登录” 提示。
4. 用户退出：删除 Redis 中对应的 Key（DEL login:session:token），实现 “登出” 效果。

4. 优势（对比传统 Session）

• 分布式共享：所有应用服务器通过 Redis 访问同一套 Session 数据，解决 “跨服务器登录状态失效” 问题。
• 内存扩展：Redis 可独立部署，支持集群（分片 + 哨兵），存储容量可横向扩展（不受单个应用服务器内存限制）。
• 持久化保障：RDB/AOF 机制确保 Session 数据在 Redis 重启后不丢失，用户无需重复登录。
• 高效过期管理：Redis 的过期 Key 清理机制（惰性删除 + 定期删除）比 Tomcat 的内存扫描更高效，减少资源消耗。

三、传统 Session 与 Redis 存储 Session 的核心对比

四、为何用 Redis 替代传统 Session（以黑马点评为例）

黑马点评作为高并发的分布式电商项目，需解决以下核心问题，而 Redis 恰好适配：

1. 分布式部署需求：项目需部署多台应用服务器（Tomcat 集群），传统 Session 的 “内存隔离” 会导致用户登录状态混乱，Redis 实现跨服务器会话共享。
2. 高并发场景：秒杀、促销等场景下用户请求量激增，Redis 的高性能（毫秒级响应）可支撑大量 Session 读写，避免传统 Session 的内存瓶颈。
3. 用户体验保障：Redis 持久化确保服务器重启后 Session 不丢失，用户无需重复登录；过期机制可灵活控制登录有效期（如 “7 天内免登录”）。
4. 业务扩展：Redis 的 Hash 结构便于存储用户多维度信息（如会员等级、优惠券数量），后续业务扩展时无需修改存储结构，兼容性更强。

总结

传统 Session 是 “单机内存级” 的状态存储，依赖单个应用服务器，适合简单单机场景；而 Redis 是 “分布式级” 的状态存储，通过网络共享数据，支持高并发、高可用和弹性扩展，是分布式项目（如黑马点评）中替代传统 Session 的最优解。

其核心逻辑是：用独立的分布式存储打破 Session 与服务器的强绑定，解决分布式场景下的会话一致性问题。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论