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

解决方案

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 需要新增两台服务器

（编辑：ASP站长网）