在一次正常的活动促销之后，客服开始陆续反馈有用户反应在抢标的时候打不开网页或者 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 服务器主库的各项指标均已经达到峰值，而从库几乎没有太大压力。

跟踪代码发现，三端的业务代码全部连接主库，从库只有后台的查询业务在使用，于是立刻启动改造。