基于分布式系统、同公司内、同一个 redis 作为存储，这个是目前主要的用法，去找开源框架都是这个逻辑；对外开放等使用参考 OAuth 2.0
能够标识出用户是谁，安全性相对高一些，就是好的方案。
Cookie
Set 和 Get：
- 服务端控制 Set： 服务器可以通过 HTTP 响应头中的
Set-Cookie字段来设置 Cookie。如果浏览器没有找到相应的 Cookie，服务器通常会设置一个默认的 Cookie。——通过服务端渲染，返回给前端的代码也可以拼接上前端主动setCookie也行 - 浏览器处理： 浏览器接收到
Set-Cookie后会自动存储和管理这些 Cookie。当浏览器再次向同一服务器发送请求时，它会自动将所有相关 Cookie 附加到请求头中。
Session
会话 ID：
- 服务器为每个用户创建一个唯一的会话 ID，并将其存储在服务器端（如redis、Db等）。
- 会话 ID 通常会被包装在一个名为
sessionid的 Cookie 中，这样浏览器在每次请求时都会自动携带这个 ID。 - 服务器通过会话 ID 来识别用户，并获取与该用户相关的会话数据。
JWT（JSON Web Token）
用户信息加密字符串：
- JWT 是一种用于在网络应用间传递声明的开放标准（RFC 7519）。它由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。
- JWT 的载荷部分可以包含用户的身份信息和其他相关数据。这些数据在服务器端进行加密处理后生成 JWT 字符串。
- 由于 JWT 是自包含的，因此可以减少对数据库的查询。但是，JWT 不易于实现下线处理，因为一旦签发，它将在其过期时间之前一直有效。为了解决这个问题，通常会在服务器端（如 Redis）存储一份 JWT 的副本，并设置相应的过期时间。当需要强制用户下线时，只需删除 Redis 中的对应记录即可。
Token（跟 SessionId 差不多）
服务端生成和 Redis 存储：
- Token 是一种用于身份验证的字符串，通常由服务器生成并返回给客户端。
- 与 JWT 不同，Token 可以是任何格式和长度的字符串，只要它能够唯一标识用户即可。
- 为了提高安全性和可扩展性，可以将 Token 存储在 Redis 等内存数据库中。这样，当用户登录或刷新 Token 时，服务器只需更新 Redis 中的记录即可。
- 在请求处理过程中，服务器可以通过检查 Redis 中是否存在对应的 Token 来验证用户的身份。同时，Redis 的高性能和分布式特性也使得 Token 验证过程更加高效和可靠。
总结
- Session 和 Cookie 在分布式环境下的处理：
- 传统的单体应用中，session 数据通常存储在服务器端。但在分布式系统中，为了支持水平扩展和数据共享，可以将 session 数据存储在像 Redis 这样的集中式存储中。
- JWT 与 Redis 的结合使用：
- JWT（JSON Web Tokens）本身包含所有认证信息，不需要服务器查询数据库验证，但其过期管理和注销机制较弱。为了解决这些问题，通常在 Redis 中货数据存储 JWT 的黑名单来管理过期时间和下线操作。——这就很没意思（快和token一个月i死了）
- Token 的管理和免登录功能：
- Token后端一般存储在 Redis 中进行统一管理。对于需要实现长时间免登录的功能，可以通过设置一个长期有效的 cookie（例如30天有效期），token 脱离了 cookie 的安全校验，跨域更加方便
jwt web 场景下意义就不是很大了，选择用 token 有些情况下也是会和 cookie 一起搭配使用了；
)
