会话一致性架构设计实践

1.起源 1.什么是会话？ 服务器为每个用户创建一个会话并存储与用户相关的信息，以便多个请求可以针对同一上下文。 在Web开发中，Web-Server可以自动为访问同一浏览器的用户创建会话，并提供数据存储功能。最常见的就是在session中存储用户的登录信息和用户信息，以维护登录状态。 2.什么是会话一致性问题？ 只要用户不重启浏览器，每次发出http短连接请求，服务器理论上都可以定位到会话并维持会话。 当只有一台Web-Server提供服务时，每个http短连接请求都能正确路由到对应的存储Session的Web-Server（废话，因为只有一台）。 此时，Web服务器无法保证高可用性。当使用“冗余+故障转移”的多个Web服务器来确保高可用性时，每个http短连接请求可能无法路由到正确的会话。 如上图所示，假设用户包含登录信息的会话都记录在第一台Web服务器上，如果反向代理将请求路由到另一台Web服务器上，则可能找不到相关信息，导致用户需要重新登录。 如何在Web服务器高可用的情况下保证会话路由的一致性是今天要讨论的问题。 2. 会话同步方法 想法：多个Web服务器相互同步会话，以便每个Web服务器包含所有会话。 优点：web-server支持的功能，应用程序无需修改代码 不足的： 会话同步需要传输数据，占用内网带宽，且存在延迟。 所有网络服务器都包含所有会话数据。数据量受内存限制，无法水平扩展。 当有更多网络服务器时停止 3、客户端存储方式 思路：服务器存储所有用户的session，占用大量内存。您可以将会话存储在浏览器 cookie 中。每个客户端只需要存储一个用户的数据。 优点：服务器端不需要存储 缺点： 每个http请求都携带Session，会话占用外部网络带宽。 数据存储在末端并通过网络传输，存在泄露、篡改、被盗等安全风险。 会话中存储的数据大小受 cookie 限制 虽然“末端存储”的方案并不常用，但确实是一个想法。 3. 反向代理哈希一致性思路：为了保证高可用性，Web服务器有多台冗余服务器。反向代理层能否采取一些措施来确保同一用户的请求落在一台 Web 服务器上？ 方案一：四层代理哈希 反向代理层使用用户 IP 进行哈希处理，以确保具有相同 IP 的请求落在同一 Web 服务器上。 选项 2：七层代理哈希 反向代理利用http协议中的某些业务属性进行哈希处理，如sid、city_id、user_id等，可以更灵活地实现哈希策略，保证来自同一浏览器用户的请求落在同一个Web-server上。 优势： 只需要更改nginx配置，无需修改应用代码 负载均衡，只要hash属性统一，多个Web服务器的负载就均衡 可以支持web-server水平扩展（由于内存限制，无法使用会话同步方法） 不足的： 如果Web服务器重启，部分会话会丢失，造成业务影响，例如部分用户重新登录。 如果Web服务器水平扩展并且会话在rehash后重新分配，则某些用户将无法路由正确的会话。 会话一般都有有效期。这两个缺点可以认为相当于部分会话失败，一般问题不大。 关于四层哈希或者七层哈希，我个人推荐前者：让专业的软件做专业的事，反向代理负责转发。尽量不要引入应用层业务属性，除非迫不得已（比如有时候有很多机房，活动需要根据业务属性路由到不同机房的web-server）。 4.后端统一存储 想法：将会话存储在Web服务器后端、数据库或缓存的存储层中 优势： 无安全隐患 可以水平扩展，只需水平拆分数据库/缓存 当网络服务器重新启动或扩展时，不会出现会话丢失。 缺点：多增加了一次网络调用，需要修改应用代码。 关于db存储还是cache，我个人推荐后者：session读取的频率会很高，数据库压力会比较大。如果有会话高可用的需求，可以把缓存做高可用，但大多数情况下会话可能会丢失，一般不需要考虑高可用。 5. 总结 保证会话一致性的架构设计常用方法： Session同步方式：多个Web服务器相互同步数据 客户端存储方式：用户只存储自己的数据反向代理哈希一致性：可以进行四层哈希和七层哈希，以确保用户的请求到达网络服务器 后端统一存储：web-server重启扩容，session不会丢失。 对于方案3和方案4，我个人推荐后者： Web层和服务层的无状态是大规模分布式系统的设计原则之一。会话是有状态的，不应放置在 Web 层中。 让专业的软件做专业的事，网络服务器保存会话？让缓存来做这样的事情吧！ 【本文为51CTO专栏作家“58申健”原创稿件，转载请联系原作者】 点击此处查看该作者更多好文章