首先 , 我们大多数知道的都是Token(JWT) , 和 session AND cookie 的两种保持登录态的方式。最原生的他们， 也就JWT 还能更上时代一点 , session在分布式, 基本上只有 在项目里吃灰, 但,session也可以变为适用于分布式,。
1 。 我们都知道Redis 不仅可以用于作为缓存 和 分布式锁 之外， 其实 ， 它还可以用户记录登录态。SpringSession。
我记得好像是 原本的session 在浏览器的 domin中默认都是 localhost+你项目的端口号，localhost域名下的其他端口号，好像都是不行的， 比如从8080的session 到8081 session也会失效（重新生成了），就更别提 自己其他的域名，100%CORS警告，同源策略error，所以， 我们裤采用redis 来保持记录登录态；通过yml配置
先添加依赖 ：
<!-- https://mvnrepository.com/artifact/org.springframework.session/spring-session-data-redis -->
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
<version>2.6.4</version>
</dependency>session:
store-type: redis2 。 此外，我们还可以通过Hash来保持 一致性 ， 在分布式 中，主要就是你的 session 只是一堆服务器中一个产生的 ， 所以 这个session也只有在这个服务器中使用， 既然 ， session不能做到跨域 ， 那么我们可以让session 不进行跨域， “在哪产生，就在哪消费”，那就需要保持session 和 服务器之间的关系了。 我们通过nginx 将这session 发送给对应Hash code 的那台里
3. 还有比较笨的方法 就是 多一个服务器，就复制session到这个服务器 ， 小企业，还能这么用 ， 大企业一定不用这么傻的方式的
4 。 将session 存入 cookie 中 ，但这明显就是最傻的方式 ， 浏览器不仅可以删除cookie登录信息， 更是可以篡改 你的cookie（给你项目赛个小的病毒） ， 而且 cookie在浏览器的长度是有限的 （好像一般是4K）
我最推荐的还是前三种方法 ， 至少， 在我的项目 做技术选型时 ， 这些都是考虑过的 ， 毕竟， 如果， 你是想和其他人产生差异化， 并且 ， 想保持自己独立的思考 ， 我的建议是（也是对我自己说的）不要盲目随大流，做自己。言归正传，为什么 我要考虑这些方式呢？JWT虽好，但他肯定也还是 没有redis操控内存快的，（但，我不是富哥，redis服务器太贵了）
三者 比较
### 1. JWT (JSON Web Tokens)
JWT 是一种无状态的认证机制，用户身份验证成功后，服务器会生成一个包含用户信息的 token 并发送给客户端。客户端将此 token 存储在本地（如 cookie 或 localStorage），并在每次请求时将其放在 HTTP 头部（Authorization 字段）中。
**优点**：
- 无状态：不需要在服务器端存储 session 数据，减轻了服务器的负担。
- 跨域支持：因为 token 是由客户端持有的，所以支持跨域请求。
- 可扩展性强：适用于微服务架构。
**缺点**：
- 安全性：如果 token 泄露，攻击者可以利用它进行访问，因此需要使用 HTTPS 来保护 token 的安全。
- 时效性：token 过期后需要刷新，这通常通过 refresh token 来完成。
- 无法撤销：一旦 token 发出，在其过期前无法撤销，除非使用额外逻辑。
### 2. Redis 存储 Session
在这种方法中，用户身份验证成功后，服务器会在 Redis 中创建一个 session，并将 session ID 存储在客户端的 cookie 中。每次客户端发起请求时，都会携带 session ID，服务器则从 Redis 中获取相应的 session 数据。
**优点**：
- 高性能：Redis 是内存数据库，访问速度快。
- 分布式支持：Redis 支持集群部署，适合分布式环境。
- 灵活性：可以在服务器端实施更复杂的 session 控制逻辑。
**缺点**：
- 依赖 Redis：Redis 故障会影响 session 的有效性。
- 服务器端逻辑：需要在服务器端实现 session 的创建、更新、删除等逻辑。
### 3. Hash 一致性 + Nginx
这种方法通常用于分布式环境下的一致性哈希算法，通过计算用户的唯一标识（如 IP 地址或用户名）来决定其 session 的存放位置。Nginx 作为反向代理服务器可以根据哈希结果将请求转发到正确的后端服务器上。
**优点**：
- 负载均衡：可以通过哈希算法将请求均匀分配到不同的后端服务器。
- 一致性：相同用户的请求会被路由到相同的后端服务器，从而保持 session 的一致性。
**缺点**：
- 复杂度：实现相对复杂，需要维护哈希环。
- 扩展困难：当后端服务器增加或减少时，可能导致数据迁移。
### 总结
选择哪种方式取决于您的具体应用场景和技术栈。JWT 适用于无状态的服务，Redis 存储 session 则更适合有状态的应用，而一致性哈希 + Nginx 可能更适合需要高度一致性和负载均衡的场景。在实际应用中，也可能根据业务需求混合使用这些技术。（唉 ， 真的奇怪， csdn默认不是markdown格式， 切换成markdown编辑，也还是感觉味不正，差点味道）
