在一次正常的活动促销之后，客服开端连续反应有用户反应在抢标的时分打不开网页或许 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 的衔接数有 1000 支配，随机检查 Apache 配置文件中设置的**衔接数为 1024（Apache 默许的**衔接数为 256）。
原本抢标期间衔接数现已抵达**衔接数，许多用户在抢标的进程中现已获取不到 http 衔接导致页面无呼应或许 APP 一直在等待中。所以调整 Apache 配置文件中的**衔接数为 1024*3。
在抢标进程中持续不雅观观观观调查，Apache 的衔接数在抢标的时分依然能够飙到 2600-2800 之间，，依照客服反应，依然有许多用户反应抢标的问题，但比之前略微好一点，可是有零散的用户反应现已抢到标的，最终又给回退了。
然后持续不雅观观观观调查数据库就事器，运用 top 指令和 MySQL Workbench 检查 MySQL 主库和从库的各项负载吓一跳（如下图），MySQL 就事器主库的各项目标均现已抵达峰值，而从库几乎没有太大压力。
记一次流量暴增形成的“出产事端”优化阅历！
盯梢代码发现，三端的事务代码悉数衔接主库，从库只要后台的查询事务在运用，所以马上发动改造。
