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

“

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

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

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

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

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

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

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

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

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

优化报告

背景

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

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

用户访问示意图

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

存在的问题

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

• 网页或者 APP 打不开。

• 网站或者 APP 打开慢。

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

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

分析

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

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

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

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

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

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

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

  抢标中，单次购买大概会涉及 15 张左右表进行更改查询，每个标的份额 1000 万大概每次会有 100-200 人左右购买完成满标，以中间值 150 人计算，在几秒的时间内需要对数据更新 2000-3000 次(仅仅是更新，不包括查询 )，产生大量并发，可能会导致更新失败或者连接超时，从而影响到用户投标和系统正常满标。

解决方案

Web 服务器解决方案

单个用户访问 Web 服务的示意图，如下：

目前网站和平台 APP 均是采用了两台服务来做均衡负载，每台服务器中安装了 Apache 来做服务端接受处理，每台 Apache 最大可以处理大约 2000 条连接。因此理论上目前网站或者 APP 可以处理大于 4000 个用户请求。

如果要支持同时 10000 的请求，则需要 5 台 Apache 服务器来支持,因此目前缺少 6 台 Web 服务器。

升级服务器后的访问示意图，如下：

数据库解决方案

当前数据库的部署方案，如下图：

• 主从分离解决主库 80% 的查询压力。目前平台官网、APP 均连接 MySQL 主库导致主库压力倍增，把服务中的查询全部迁移到从数据库可以大量减轻主库的压力。

• 增加缓存服务器。当从库查询到达峰值的时候，也会影响主从的同步，从而影响交易，因此对用户经常使用的查询进行缓存以达到减少数据库的请求压力，需要新增三台缓存服务器搭建 Redis 集群。

其他优化

• 官网首页静态化，从 cnzz 统计来分析，首页占比网站的整体访问量的 15% 左右，对于首页不经常变动的数据通过静态化来处理，提升官网打开的流畅度。

• Apache 服务器的优化，开启 gzip 压缩，配置合理的链接数等。

• 去掉投资过程中的更新热点：标的进度表。每次投标成功或者失败都需要对标的进度表进行更新，多线程更新的时候就会出现乐观锁等问题。

  去掉过程中的更新，只在满标后将标的进度信息保存在标的进度表，优化投资过程中对数据库的压力。

服务器升级方案

平台最大的压力来自于数据库，需要将现在的一主一从，改为一主四从。官网/APP/小网页产生的大量查询，由虚 IP 分发到三台从库，后台管理查询走另外的一个从库。

数据库需要新增三台服务器，数据库升级后的示意图如下：

通过增加缓存可以减少数据库的压力，除了需要新增两台大内存的缓存服务器，还需要新增三台 Web 服务器分解用户访问请求。

APP 需要新增两台服务器

在抢标过程中 APP 服务器压力最大，需要新增两台服务器，配置完成后的示意图如下：

官网需要新增一台服务器

官网在抢标过程也有一定的压力，需要新增一条服务器，完成后示意图如下：

总合计之后需要购置 8 台服务器，其中有两台要求有大内存（64 G以上），所有优化方案投产后，问题解决，抢标无忧！

作者：张强（纯洁的微笑）

编辑：陶家龙、孙淑娟

出处：http://www.ityouknow.com/ 

张强，曾经先后在互联网金融、第三方支付公司担任高级 Java 工程师、架构师、技术经理、技术负责人等职务。在互联网金融工作期间，从零参与公司技术平台建设，组织平台进行过四次大架构升级。目前在一家第三方支付公司做架构师，负责支付公司大数据平台建设。

精彩文章推荐：