怎么解决redis中分布式session不一致性

这篇文章主要讲解了“怎么解决redis中分布式session不一致性”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么解决redis中分布式session不一致性”吧！一、Session有什么作用？Session 是客户端与服务器通讯会话跟踪技术，服务器与客户端保持整个通讯的会话基本信息。【相关推荐：Redis视频教程】客户端在第一次访问服务端的时候，服务端会响应一个sessionId并且将它存入到本地cookie中，在之后的访问会将cookie中的sessionId放入到请求头中去访问服务器，如果通过这个sessionId没有找到对应的数据,那么服务器会创建一个新的sessionId并且响应给客户端。二、分布式Session有什么问题？单服务器web应用中，session信息只需存在该服务器中，这是我们前几年最常接触的方式但是近几年随着分布式系统的流行，单系统已经不能满足日益增长的百万级用户的需求，集群方式部署服务器已在很多公司运用起来当高并发量的请求到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器，这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session数据的情况，于是session的共享就成了一个问题。三、服务做集群一般是怎么样做的？SpringBoot项目，那么只要改下端口号启动几个，然后用nginx统一做反向代理。SpringCloud微服务项目，那么这个时候，可以使用ribbon本地负载均衡。四、nginx负载均衡和ribbon负载均衡的区别nginx做负载均衡是服务器端的负载均衡，统一访问一个地址，根据负载均衡算法访问决定访问那一个服务器。ribbon负载均衡，这是本地负载均衡（客户端负载均衡），把提供服务的客户端地址都缓存记录下来，根据本地的算法实现负载均衡。五、Session一致性解决方案1. session复制（同步）思路：多个服务端之间相互同步session，这样每个服务端之间都包含全部的session优点：服务端支持的功能，应用程序不需要修改代码缺点：session的同步需要数据传输，占内网带宽，有时延所有服务端都包含所有session数据，数据量受内存限制，无法水平扩展2. 客户端存储法 思路：服务端存储所有用户的session，内存占用较大，可以将session存储到浏览器cookie中，每个端只要存储一个用户的数据了优点：服务端不需要存储缺点：每次http请求都携带session，占外网带宽数据存储在端上，并在网络传输，存在泄漏、篡改、窃取等安全隐患session存储的数据大小和域名cookie个数都受限制的免费主机域名注：该免费主机域名方案虽然不常用，但确实是一种思路。3. 反向代理hash一致性思路：服务端为了保证高可用，有多台冗余，反向代理层能不能做一些事情，让同一个用户的请求保证落在一台服务端上呢？反向代理层使用用户的ip来做hash，以保证同一个ip的请求落在同一个服务端上反向代理使用http协议中的某些业务属性来做hash，例如sid，city_id，user_id等，能够更加灵活的实施hash策略，以保证同一个浏览器用户的请求落在同一个服务器上优点：只需要改nginx配置，不需要修改应用代码负载均衡，只要hash属性是均匀的，多台服务端的负载是均衡的可以支持服务端水平扩展（session同步法是不行的，受内存限制）缺点：如果服务端重启，一部分session会丢失，产生业务影响，例如部分用户重新登录如果服务端水平扩展，rehash后session重新分布，也会有一部分用户路由不到正确的sessionsession一般是有有效期的，所有不足中的两点，可以认为等同于部分session失效，一般问题不大。对于四层hash还是七层hash，个人推荐前者：让专业的软件做专业的事情，反向代理就负责转发，尽量不要引入应用层业务属性，除非不得不这么做（例如，有时候多机房多活需要按照业务属性路由到不同机房的服务器）。四层、七层负载均衡的区别4. 后端统一集中存储优点：没有安全隐患可以水平扩展，数据库/缓存水平切分即可服务端重启或者扩容都不会有session丢失不足：增加了一次网络调用，并且需要修改应用代码对于db存储还是cache，个人推荐后者：session读取的频率会很高，数据库压力会比较大。如果有session高可用需求，cache可以做高可用，但大部分情况下session可以丢失，一般也不需要考虑高可用。总结保证session一致性的架构设计常见方法：session同步法：多台服务端相互同步数据客户端存储法 一个用户只存储自己的数据反向代理hash一致性 四层hash和七层hash都可以做，保证一个用户的请求落在一台服务端上后端统一存储 服务端重启和扩容，session也不会丢失（推荐后端cache统一存储）六、案例实战：SpringSession+redis解决分布式session不一致性问题步骤1：加入SpringSession、redis的依赖包步骤2：配置文件步骤3： 配置拦截器HandlerInterceptorpreHandle：在业务处理器处理请求之前被调用。预处理，可以进行编码、安全控制、权限校验等处理；postHandle：在业务处理器处理请求执行完成后，生成视图之前执行。后处理（调用了Service并返回ModelAndView，但未进行页面渲染），有机会修改ModelAndViewafterCompletion：在DispatcherServlet完全处理完请求后被调用，可用于清理资源等。返回处理（已经渲染了页面）步骤4： 控制器步骤5： 实体类步骤6：访问测试先登录：http://127.0.0.1:8080/user/login?username=user1&password=user1再查询http://127.0.0.1:8080/user/find/user1七、剖析SpringSession的redis原理步骤1：分析SpringSession的redis数据结构共同点：3个key都是以spring:session:开头的，代表了SpringSession的redis数据。查询类型步骤2：分析SpringSession的redis过期策略对于过期数据，一般有三种删除策略：定时删除，即在设置键的过期时间的同时，创建一个定时器， 当键的过期时间到来时，立即删除。惰性删除，即在访问键的时候，判断键是否过期，过期则删除，否则返回该键值。定期删除，即每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。redis删除过期数据采用的是懒性删除+定期删除组合策略，也就是数据过期了并不会及时被删除。但由于redis是单线程，并且redis对删除过期的key优先级很低；如果有大量的过期key，就会出现key已经过期但是未删除。为了实现 session 过期的及时性，spring session 采用了定时删除+惰性删除的策略。定时删除1635412980000 是时间戳，等于 2021-10-28 17:23:00，即是该可以在这个时刻过期springsession 定时（1分钟）轮询，删除spring:session:expirations:[?] 的过期成员元素，例如：spring:session:expirations:1635413520000springsesion 定时检测超时的key的值，根据值删除seesion，例如key：spring:session:expirations:1635413520000，值为（sessionId）：d3434f61-4d0a-4687-9070-610bd7790f3b的seesion惰性删除访问 spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b的时候，判断key是否过期，过期则删除，否则返回改进的值。例如 访问spring:session:sessions:expires:d3434f61-4d0a-4687-9070-610bd7790f3b的时候，判断 ttl 是否过期，过期就直接删除感谢各位的阅读，以上就是“怎么解决redis中分布式session不一致性”的内容了，经过本文的学习后，相信大家对怎么解决redis中分布式session不一致性这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是云技术，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: mongodb如何清理collection中大量数据

小编给大家分享一下mongodb如何清理collection中大量数据，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！ 1 shell中for循环清理 每次去连接一下mo免费主机域名n…