哈尔滨网站建设托管公司,wordpress略缩图图片变形怎么办,网站搭建代码大全,马鞍山建设工程监督站网站前言公司有一个 Web 管理系统#xff0c;使用 Tomcat 进行部署。由于是后台管理系统#xff0c;所有的网页都需要登录授权之后才能进行相应的操作。起初这个系统的用的人也不多#xff0c;为了节省资源#xff0c;这个系统仅仅只是单机部署。后来随着用的人越来越多#x…前言公司有一个 Web 管理系统使用 Tomcat 进行部署。由于是后台管理系统所有的网页都需要登录授权之后才能进行相应的操作。起初这个系统的用的人也不多为了节省资源这个系统仅仅只是单机部署。后来随着用的人越来越多单机已经有点扛不住了于是我决定再部署了一台机器。这时后端系统有两台服务于是我们使用 Nginx 作为反向代理整体架构图如下这个架构图想必大家应该比较熟悉现在主流的 Web 系统应该都是这么部署。经过一些调试之后在一个夜深人静的晚上将这套系统部署到了生产。本以为没有什么事的很稳的交给测试小姐姐开始测试。这一测出了大问题测试小姐姐反馈登录过后没过一会又需要登录操作好几次都是这样。检查了一下系统应用配置什么也没问题那到底哪里出了问题这个时候组长刚准备下班看到我们这里有问题于是过来了看了一下。简单了解的一下基本情况很快就找到了问题的原因然后在 Nginx 端修改了下配置重启解决了问题。分布式一致性 Session解决完问题组长坐下解释了问题原因分布式一致性 Session。原先我们登录之后将会把用户登录信息放在 Session 中用户每次操作首先先校验 Session 是否存在用户信息如果不存在将会强制让用户先去登录。原先架构的中我们只有一台应用系统所有操作都在一台 Tomcat 上这当然没有什么问题。但是现在我们部署了两台系统由于 Nginx 使用默认负载均衡策略轮询请求将会按照时间顺序逐一分发到后端应用上。也就是说刚开始我们在 Tomcat1 登录之后用户信息放在 Tomcat1 的 Session 里。过了一会请求又被 Nginx 分发到了 Tomcat2 上这时 Tomcat2 上 Session 里还没有用户信息于是又要登录。另外由于我们系统采用单点登录的方式Tomcat2 登录之后会将 Tomcat1 登录信息失效于是乎等到 Nginx 再把流量分发到 Tomcat1 时Session 中用户登录信息已经失效又要重新登录。知道了问题当然想知道解决办法了于是组长教了下分布式一致性 Session 四种解决办法小黑哥给大家整理了一下下面小黑哥将会以跟组长对话的形式讲解分布式一致性 Session 解决办法。Session 复制组长如果此时 Tomcat1 Session 存在用户信息而 Tomcat2 上没有存在。这时如果我们将 Tomcat1 的 Session 复制到 Tomcat2 上后面 Nginx 将请求转发到 Tomcat2 上由于 Tomcat2 存在 Session 这时就不需要再重新登录了。架构图如下Tomcat 的 Session 复制的配置网上有比较多的例子这里小黑就不再贴了感兴趣的同学可以自行搜索一下。小黑对的这种方式挺好啊。Tomcat 就支持这种方式我们只需要修改 Tomcat 配置就好我们应用代码都不用修改了。组长说的对但是这种方式还是有很多缺点。第一Session 复制传输需要占用内网带宽。第二我们的例子就只有两台机器这个复制性能还可以。但是假设我们有 N 台机器那么每次复制都要复制给 N-1 台机器如果机器很多可能会形成网络风暴复制性能也会呈指数级下降。第三 Tomcat 需要保存所有的 Session 数据这个方案的 Session 存储在内存中容易受到机器的总内存的限制。我们没办法通过加机器的方式水平扩展我们能做的方式就是加大机器内存。但是机器内存越大价格真的很贵所以不推荐使用这种方案。Session 前端存储小黑恩这个方案确实有点不靠谱~哎有了我们的 Session 里面其实就是存了用户的信息那我现在不存 Tomcat Session 里我把信息拿出来存到浏览器的 Cookie 中。这样每个用户浏览器存储自己的 Cookie 信息服务端就不需要存储这就解决了 Session 复制方案的缺陷了。接下来用户每次请求都把这个 Cookie 给我发过来我判断 Cookie 里面用户信息不就好了。架构图如下组长欣赏看了一下我对你这个方案确实可行。不过么如果用这种方案首先你要想好加密方案。用户信息可是我们的敏感数据不能让别人轻易的窃取或者篡改数据了。除了这个这个方案每次请求都要携带 Cookie 传输这会占用外网的带宽如果 Cookie 过大会增大网络的开销。另外我们存储的数据大小容易受到 Cookie 限制。所以这种还是不怎么常用不过也是一种思路。我比较推荐下面两种方案。Session 粘滞Sticky Sessions组长刚才应该看到了我只是对 Nginx 的配置做了一些修改然后这个问题就解决了吧。其实这是因为我修改 Nginx 默认的负载均衡策略使用 IP Hash 的方式。Nginx 会使用请求者的 IP 来做 Hash然后分发到一台机器上这样可以保证同一 IP 的请求都落在同一台 Tomcat 上。架构图如下上面这种方式我们使用 Nginx 四层负载均衡方式其实 Nginx 还可以做到七层负载均衡方式也就是使用 Http 协议中的一些业务属性来做 Hash常见的有 userId,loginId等等。架构图如下小黑这种方案看起来挺简单的我们只需要修改 Nginx 配置就好了应用端配置无需改动。只要请求来源 IP 足够的随机那么 IP HASH 之后两台应用上的流量将会足够随机。另外后面如果两台机器扛不住我们还可以水平扩展再加机器只要修改 Nginx 配置即可。组长你说的这几点都很正确不过你有没有想过像我们公司这种情况所有人的出口的 IP 都是一个。那么我们公司的所有请求只会到一台机器上那我们这种情况等于又变成单点了。另外如果 Tomcat 重启Session 由于是放置在内存内存中这一部分的 Session 将会丢失这就导致这部分用户将会重新登录。最后如果我们临时再加机器修改完 Nginx 配置重新启动之后Nginx 将会重新计算 Hash 分发请求。这种情况就会导致有一部分用户重新路由到一台新机器上由于没有 Session又需要重新登录了。不过么Tomcat 重启或者新加机器次数不会很多所以这个问题也不大用户体验稍差点。今天的我们这个问题解决方案就先使用这个。不过后面我们还是改成下面这种方式。后端集中存储组长上面几种的方式我们都是把 Session 存储在应用内存上应用机器只要重启Session 就会丢失。为了这个解决这个问题我们将 Session 单独存起来保存到 Redis 或者 MySQL 中。不过由于 Session 需要过期失效的特性不需要持久化保存所以这里我建议使用 Redis 来保存。这样架构就变成下方这样的我们使用这种方案上没有 Session 丢失的风险当然前提是 Redis 不能宕机。另外后期如果应用可以直接水平扩展。如果后面应用的请求量很大一台 Redis 扛不住了那我们可以其实可以做集群扩展根据缓存 Key 做路由。小黑对对这种方式好~组长你不要高兴的太早我们使用这个方案需要付出一定的代价的。首先我们每次请求都需要调用一次 Redis 这就增加一次网络的开销。另外引入 Redis我们需要对相应的代码做出修改这样复杂度就变高。所以说这个方案有利也有弊当然对于我们的场景来说利大于弊。小黑恩好像是这样的。组长:好了这么晚了问题解决了我们去撸个串我请客小黑老大 组长拍了拍小黑的脑袋我这一顿不是白吃哦下个星期你把现在方式修改一下修改成 Session 集中存储的方式。给你一个小提示可以使用 spring-session。小黑好吧吃人嘴短下周我研究下。总结最后总结一下当我们后端 Web 应用扩展到多台后我们就会碰到分布式一致性 Session 的问题主流解决方案有四种Session 复制利用 Tomcat 等 Web 容器同步复制Session 前端存储利用用户浏览器中 Cookie 保存 Session 信息Session 粘滞方案利用 Nginx 可以做四层 Hash 或七层 Hash 的特性保证用户的请求都落在同一台机器上Session 后端集中存储方案利用 Redis 集中存储 SessionWeb 应用重启或扩容Session 也无需丢失。上面四种方案优先推荐第四种。当然第四种方案需要一定的开发工作量前期还没改造的过程可以选择 第三种方案中间过渡。好了后面就要使用 Session 后端存储方案改造这个工程了后面小黑哥再跟大家分享一下 spring-session。作者楼下小黑哥链接https://www.cnblogs.com/goodAndyxublog/p/13327412.html#4634068来源博客园
