分布式会话解决方案

小小大爆炸

于 2024-07-02 15:59:45 发布

阅读量701

点赞数 28

文章标签：分布式

本文链接：https://blog.csdn.net/2201_75341115/article/details/140129251

版权

会话的基本概念

为什么需要session

HTTP本身是无状态的，但是在很多的web应用场景下需要维护用户状态才能正常工作（是否登录），或者说提供便捷（记住密码，浏览历史），状态的保持就是一个很重要的功能

基于cookie的session机制

当浏览器第一次访问服务器时，服务器创建一个session对象(该对象有一个唯一的id,一般称之为sessionId),服务器会将sessionId以cookie的方式发送给浏览器。当浏览器再次访问服务器时，会将sessionId发送过来，服务器依据sessionId就可以找到对应的session对象。

session通俗的讲就是服务器识别用户的一段文本数据

会话的技术发展

粘性session----->session复制----->redis实现集中式的会话存储----->无状态的token实现会话：JWT token

①粘性session：

nginx根据用户的sessionid通过哈希算法对用户请求进行一个负载均衡，但是如果有一台服务器宕机或者重启，那么这台机器上的会话数据会全部丢失

②session复制：

利用web服务器的集群能力，将Session信息复制到其他节点。

缺点：
- 需要额外的网络带宽和存储资源来维护会话数据的复制和同步。
- 复制会导致更高的系统开销和延迟，尤其是在大规模集群中。

③redis实现集中式会话存储：

Redis是一个内存中的键值存储系统，可以用作集中式会话存储。在这种方案中，应用程序将用户的会话数据存储在Redis服务器中，而不是在本地文件系统或数据库中。
每个会话通常由一个唯一的session ID标识，这个ID作为键存储在Redis中，而会话数据作为值存储。通过这种方式，应用程序可以轻松地访问和更新会话数据。
高可用性与容错性：
- 使用Redis集群或主从复制模式可以实现高可用性，即使部分节点宕机，系统仍能继续提供服务。
- Redis的持久化机制可以防止数据丢失，保证会话数据的可靠性。

④无状态的token实现会话

拓展：传统的 pc 形式，都是登录之后，写入 cookie。前端再次请求的时候，带着 cookie 一个身份识别就可以完成认证。坏处是什么？小程序呀，app 呀，其实是没有 cookie 这个概念的。为了更好的扩展，我们就直接选择 token的模式。token 放入 header 来实现用户身份的识别与鉴权。

安全性：JWT使用数字签名来验证数据的完整性和真实性，因此具备较高的安全性。只有持有有效密钥的服务器才能签署（生成）和验证JWT，确保信息不被篡改或伪造。

跨域兼容性：JWT可以被跨域使用，适合在分布式系统中实现统一的身份验证和授权机制，例如单点登录（SSO）。

单点登录解决方案CAS

单点登录介绍

通过一对ID和密码实现不同系统的无缝登录功能，可以将用户管理中心化，避免每个系统都需要一套单独的账户配置和用户管理实现。目前广泛应用了LDAP和CAS协议

基于CAS实现的单点登录

名词解释：

TGT（Ticket Granting Ticket）：

TGT是CAS中用来验证用户身份的凭证。用户在首次登录时，CAS服务器会验证其用户名和密码，并颁发一个TGT给客户端（通常是浏览器）。
TGT本身并不包含用户的具体信息，而是一个包含了身份验证状态的票据，类似于一个令牌。
TGT通常是加密的，客户端可以使用它来获取服务票据（ST）而无需再次输入密码。

ST（Service Ticket）：

ST是CAS用来向服务提供身份验证的票据。客户端在获得TGT后，可以向CAS请求一个ST，并将其发送给要访问的服务。
服务可以向CAS验证该ST的有效性，CAS会返回该ST对应的用户信息或者认证失败信息。

用户请求受限资源，不包含受限资源的访问凭证，重定向到CAS服务中去获取，CAS服务验证用户身份信息，不包含TGT之后重定向到页面要求用户登录，用户输入登录信息完成登录之后生成对应的TGT和受限资源对应的ST，获取到令牌之后重定向到受限资源端，TGT写入cookie，并向CAS端确认ST信息，最后访问到受限资源

重定向到CAS服务：
- 当用户请求受限资源但没有有效的访问凭证时，受限资源端会重定向用户到CAS服务。
CAS服务验证用户身份：
- 用户被重定向到CAS服务后，CAS服务会验证用户的身份信息。这通常涉及用户输入用户名和密码进行身份验证。
生成TGT和ST：
- 如果用户的身份验证成功，CAS服务将生成两种票据：
  - TGT（Ticket Granting Ticket）：用于标识用户的身份验证状态，并存储在CAS服务器中。
  - ST（Service Ticket）：用于单个服务的访问凭证，会返回给用户的浏览器，通常作为URL参数返回。
重定向到受限资源端：
- CAS服务生成ST后，会将用户重定向回最初请求的受限资源端，同时将ST作为参数传递给受限资源端。
验证ST并访问资源：
- 受限资源端接收到用户带有ST的请求后，会向CAS服务验证ST的有效性。
- 如果ST有效，CAS服务会返回与之关联的用户信息或授权信息给受限资源端。
- 受限资源端在确认了ST有效后，允许用户访问请求的受限资源。
TGT写入Cookie：
- 成功访问受限资源后，受限资源端会将TGT写入用户的浏览器Cookie中。TGT通常加密并包含了用户的身份认证状态。
最终访问到受限资源：
- 用户成功获取ST并完成相关验证后，可以顺利访问到请求的受限资源。