优化经历

优化报告

1 背景

随着公司业务不断发展，业务量和用户量的激增，官网pv也从最初的xxx-xxx到现在的xxx-xxxx，APP活跃用户更是大幅增加；因此也对平台目前的技术架构有了更大的挑战。特别是近期平台标源紧张的情况下，满标的时间更是越来越短。服务器的压力也越来越大；因此需要升级目前的系统架构，以支持更大的用户量和业务量。

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%左右，对于首页不经常变动的数据通过静态化来处理，提升官网打开的流畅度。

2）apache服务器的优化，开启gzip压缩，配置合理的链接数等

3) 去掉投资过程中的更新热点：标的进度表。每次投标成功或者失败都需要对标的进度表进行更新，多线程更新的时候就会出现乐观锁等问题。去掉过程中的更新，只在满标后将标的进度信息保存在标的进度表，优化投资过程中对数据库的压力。

6 服务器升级方案

1、平台最大的压力来自于数据库，需要将现在的一主一从，改为一主四从。官网/app/小网页产生的大量查询，由虚IP分发到三台从库，后台管理查询走另外的一个从库。数据库需要新增三台服务器
数据库升级后的示意图

2、增加缓存减少数据的压力，需要新增两台大内存的缓存服务器

3、需要新增三台web服务器分解用户访问请求

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

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

总合计之后需要购置8台服务器，其中有两台要求有大内存（64G以上）