天津建设交培训中心网站,表白视频制作软件app,免费自助建站系统下载,网络维护图片在一次正常的活动促销之后#xff0c;客服开始陆续反馈有用户反应在抢标的时候打不开网页或者APP#xff0c;在打开的时候标的就已经被抢光了#xff0c;刚开始没有特别的上心#xff0c;觉得抢标不就是这样吗#xff0c;抢小米手机的时候也不就这样吗#xff1f;随着活动… 在一次正常的活动促销之后客服开始陆续反馈有用户反应在抢标的时候打不开网页或者APP在打开的时候标的就已经被抢光了刚开始没有特别的上心觉得抢标不就是这样吗抢小米手机的时候也不就这样吗随着活动继续推进有更多的用户强烈抗议用户领了加息卷或者抵现卷之后抢不上标的认为是平台作假故意不让使用以达到节省资源。 分析过程 其实以前也会有陆续的用户反馈不减少给客户以小米抢手机为例子忽悠了过去这次用户反馈太过强烈才让我们重视了起来。我们前端一共三款产品app、官网、H5其中app使用量最大官网其次H5平时使用量极少但是做活动期间流量会暴增活动一般都是H5游戏居多H5也便于推广营销,前端的三款产品都是分别使用lvs负载到后端的两台web服务器中如下图这次用户反馈基本在web和app端所以重点观察这四台服务器。 首先怀疑网络带宽是否被涌满找到网络工程师通过工具来监控在抢标的时候带宽最高使用率只有70%左右随排除之再次怀疑web服务器是否抗不住了使用top命令查看官网负载的两台服务器在抢标的瞬间会飙到6-8左右抢标后也慢慢的恢复了正常app两台服务器高峰到10-12随后也恢复正常。 跟踪web服务器业务日志发现在数据库更新层报请求不到新的数据库连接或者数据库连接已经用完认为是数据库的最大连接数太小于是调整mysql数据库最大连接数为以往的3倍下次抢标的时候继续观察业务日志发现已经不报数据库链接的相关错误了但还是很多用户反馈抢标时候打不开页面。 继续跟踪web服务器在抢标时使用命令ps -ef|grep httpd|wc -l查看httpd得连接数有1千左右随机查看apache配置文件中设置的最大连接数为1024apache默认的最大连接数为256原来抢标期间连接数已经到达最大连接数很多用户在抢标的过程中已经获取不到http连接导致页面无响应或者app一直在等待中。于是调整apache配置文件中的最大连接数为1024*3。 在抢标过程中继续观察apache的连接数在抢标的时候仍然可以飙到2600-2800之间根据客服反馈仍然有很多用户反馈抢标的问题但比之前稍微好一点但是有零星的用户反馈已经抢到标的最后又给回退了。然后继续观察数据库服务器使用top命令和MySQLWorkbench查看mysql主库和从库的各项负载吓一跳如下图mysql服务器主库的各项指标均已经达到峰值而从库几乎没有太大压力。 跟踪代码发现三端的业务代码全部连接主库从库只有后台的查询业务在使用于是立刻启动改造将除过抢标过程中的查询外其它页面或者业务的所有查询改造为查询从库改造之后观察发现主库的压力明显减少从库的压力开始上来了。如下图 根据客服的反馈改造之后抢到标回退的问题几乎没有了抢标过程中页面打不开或者打开慢的问题有一定的缓解但仍有部分用户反馈此问题根据上面各项目分析结果得出 1 负载的两台服务器均已经达到处理的极限需要配置更多的服务器来负载。2 mysql主库的压力明显减少但是从库的压力却上去了需要将现在的一主一从已从改为一主多从的模式。3 彻底解决这些问题需要综合考虑平台的整体优化如业务优化去掉业务中热点、增加缓存、部分页面静态化可以使用雅虎和谷歌的前端优化规则网上也有很多的测试网站可以评测等等。 当时根据这些情况写了一份优化的报告,见下文 优化报告 1 背景 随着公司业务不断发展业务量和用户量的激增官网pv也从最初的xxx-xxx到现在的xxx-xxxxAPP活跃用户更是大幅增加因此也对平台目前的技术架构有了更大的挑战。特别是近期平台标源紧张的情况下满标的时间更是越来越短。服务器的压力也越来越大因此需要升级目前的系统架构以支持更大的用户量和业务量。 2 用户访问示意图 目前平台有三款产品面对用户平台官网、平台APP、平台小网页其中平台官网和平台APP的压力比较大。 3 存在的问题 用户抢标的时候问题集中在以下几个方面 1、网页或者APP打不开 2、网站或者APP打开慢 3、抢标过程中转账成功后因为服务器负责压力大更新失败再次退款 4、数据库连接数用完导致满标后添加投资记录失败回退标的进度 4、分析 通过对近期的服务器参数并发量以及系统日志等进行深入的分析得出 1、平台官网、平台APP抢标过程中服务器压力巨大其中平台APP问题更加突出抢标高峰期间单台APP服务器apache最大连接数已经接近2600接近apache最大的处理能力 2、数据库服务器压力巨大。数据库压力主要在两个时期比较突出 1当平台做活动的时候官网、小网页、APP访问量巨增导致数据查询量跟着巨增当到达数据库处理极限时就会表现出网站打开慢等问题 2当用户抢标的时候用户抢标的压力又分为两个阶段抢标前和抢标中。抢标前因为满标速度很快用户提前打开抢标页面不断刷新这样数据库的查询压力会不断增大如果抢标的用户量非常大会导致在抢标之前将数据库连接数用完抢标中单次购买大概会涉及15张左右表进行更改查询每个标的份额1000万大概每次会有100-200人左右购买完成满标以中间值150人计算在几秒的时间内需要对数据更新2000-3000次(仅仅是更新不包括查询 )产生大量并发可能会导致更新失败或者连接超时从而影响到用户投标和系统正常满标。 5 解决方案 1、web服务器解决方案 单个用户访问web服务的示意图 目前网站和平台APP均是采用了两台服务来做均衡负责每台服务器中安装了apache来做服务端接受处理每台apache最大可以处理大约2000条连接。因此理论上目前网站或者APP可以处理大于4000个用户请求。如果要支持同时1万的请求则需要5台apache服务器来支持,因此目前缺少6台web服务器。 升级服务器后的访问示意图 2、数据库解决方案 当前数据库的部署方案 1)主从分离解决主库80%的查询压力。目前平台官网、APP均连接mysql主库导致主库压力倍增把服务中的查询全部迁移到从数据库可以大量减轻主库的压力。 2)增加缓存服务器。当从库查询到达峰值的时候也会影响主从的同步从而影响交易因此对用户经常使用的查询进行缓存以达到减少数据库的请求压力。需要新增三台缓存服务器搭建redis集群。 3、其它优化 1官网首页静态化从cnzz统计来分析首页占比网站的整体访问量的15%左右对于首页不经常变动的数据通过静态化来处理提升官网打开的流畅度。 2apache服务器的优化开启gzip压缩配置合理的链接数等 3) 去掉投资过程中的更新热点标的进度表。每次投标成功或者失败都需要对标的进度表进行更新多线程更新的时候就会出现乐观锁等问题。去掉过程中的更新只在满标后将标的进度信息保存在标的进度表优化投资过程中对数据库的压力。 6 服务器升级方案 1、平台最大的压力来自于数据库需要将现在的一主一从改为一主四从。官网/app/小网页产生的大量查询由虚IP分发到三台从库后台管理查询走另外的一个从库。数据库需要新增三台服务器 数据库升级后的示意图 2、增加缓存减少数据的压力需要新增两台大内存的缓存服务器 3、需要新增三台web服务器分解用户访问请求 app需要新增两台服务器 在抢标过程中app服务器压力最大需要新增两台服务器配置完成后的示意图 官网需要新增一台服务器 官网在抢标过程也有一定的压力需要新增一条服务器完成后示意图如下 总合计之后需要购置8台服务器其中有两台要求有大内存64G以上 公众号回复“优化”可下载完整版word优化报告 备注所有优化方案投产后问题解决抢标无忧 作者纯洁的微笑出处http://www.ityouknow.com/版权归作者所有转载请注明出处 作者纯洁的微笑 出处www.ityouknow.com 本文版权归作者和博客园共有欢迎转载但未经作者同意必须保留此段声明且在文章页面明显位置给出原文连接否则保留追究法律责任的权利。 本文如对您有帮助还请多帮 【推荐】 下此文。 如果喜欢我的文章请关注我的公众号 分类: 系统架构 标签: 优化 本文转自纯洁的微笑博客博客园博客原文链接http://www.cnblogs.com/ityouknow/p/6369051.html如需转载请自行联系原作者
