记一次流量暴增造成的“生产事故”优化经历！(2)

将除在抢标过程中的查询外，其他页面或者业务的所有查询改造为查询从库，改造之后观察，发现主库的压力明显减少，从库的压力开始上来了。如下图：

根据客服的反馈，改造之后抢到标回退的问题几乎没有了，抢标过程中页面打不开或者打开慢的问题有一定的缓解但仍有部分用户反馈此问题。

根据上面各项目分析得出结果：

• 负载的两台服务器均已经达到处理的极限，需要配置更多的服务器来负载。

• MySQL 主库的压力明显减少，但是从库的压力却上去了，需要将现在的一主一从一从改为一主多从的模式。

• 彻底解决这些问题，需要综合考虑平台的整体优化，如：业务优化（去掉业务中热点）、增加缓存、部分页面静态化（可以使用雅虎和谷歌的前端优化规则，网上也有很多的测试网站可以评测）等等。

当时根据这些情况写了一份优化的报告，见下文：

优化报告

背景

随着公司业务不断发展，业务量和用户量的激增，官网 PV 也从最初的 xxx-xxx 到现在的 xxx-xxxx，APP 活跃用户更是大幅增加。

因此对平台目前的技术架构提出了更大的挑战，特别是近期平台标源紧张的情况下，满标的时间更是越来越短，服务器的压力也越来越大。因此需要升级目前的系统架构，以支持更大的用户量和业务量。

用户访问示意图

目前平台面向用户的有三款产品面：平台官网、平台 APP 和平台小网页，其中平台官网和平台 APP 的压力比较大。

存在的问题

用户抢标的时候问题集中在以下几个方面：

• 网页或者 APP 打不开。

• 网站或者 APP 打开慢。

• 抢标过程中转账成功后，因为服务器负责压力大更新失败，再次退款。

• 数据库连接数用完，导致满标后添加投资记录失败，回退标的进度。

分析

通过对近期的服务器参数、并发量，以及系统日志等进行深入的分析得出：

• 平台官网、平台 APP 抢标过程中服务器压力巨大，平台 APP 问题更加突出，抢标高峰期间单台 APP 服务器 Apache 最大连接数已经接近 2600，接近 Apache 最大的处理能力。

• 数据库服务器压力巨大。

数据库压力主要在两个时期比较突出：

• 当平台做活动的时候，官网、小网页、APP 访问量巨增，导致数据查询量跟着巨增，当到达数据库处理极限时，就会表现出网站打开慢等问题。

• 当用户抢标的时候，用户抢标的压力又分为两个阶段：抢标前和抢标中。

抢标前，因为满标速度很快，用户提前打开抢标页面不断刷新，这样数据库的查询压力会不断增大，如果抢标的用户量非常大，会导致在抢标之前将数据库连接数用完。

（编辑：ASP站长网）