最近两个月我好像很忙的样子。忙着上班，忙着下班，忙着写代码，忙着吐槽，忙着思考人生。生活好像一下子丰满了很多，笔头也随之闲了下来。
写惯了只言片语，习惯了没事儿编点什么有的没的奇奇怪怪的故事，连自己都被感动了。想来还是被都市泡沫剧祸害许多，便再难以接受这庸俗的现实。

最近两个月有帮朋友处理一点事情。虽然好像每个人都很努力，但最后事情还是黄了。时间久了我怕会忘记，就趁着这键盘还敲得利索的时候，记录一点吧。

问题由来

大概两个月前也就是七月初的时候，这哥们突然在群里面问关于服务器方面的事情。大概听了一下情况，就是他公司正在运营的一个网站，是卖足球票的。大概就是每个月有那么一两次足球比赛，然后每次会有那么几千张票，然后每次都有那么不知道多少球迷资源当猴子来抢。
典型的抢购，奇怪的是中国足球踢得不咋地，这群人抢票倒是挺积极的。
描述的大概情况就是，一到抢购的时候服务器就瘫了，完全打不开，浏览器始终在转圈，但平时访问都挺快。

第一阶段

从大概听到的情况看来，应该是带宽遇到瓶颈了。所以让他到阿里云的管理后台去看了一下监控数据，果然如此。

不过10M的带宽，几乎被占满，所以出现始终转圈也就丝毫不奇怪了。
简单了解了一下情况，大概情况就是这个服务器跑的是Windows Server 2008，公网带宽10M，服务器软件是Nginx，网站基于PHP构建，数据库是Oracle。

直觉就是……这个配置挺奇怪的。  
一般跑PHP的用nginx+fpm跑，而这里用的服务器软件是nginx，怪就怪在居然在Windows Server 2008上跑Nginx。后来看到原来用的是Xampp这个套件在跑。
再就是居然数据库用的是Oracle，这种大型数据库至于用在这里么……
再回过头看网站本身，用的是ThinkPHP框架，所有程序文件加资源都混在一起。
最后测试了一下网站程序逻辑本身，感觉问题较大，流程不够流畅，很多情况下必须靠刷新页面才能获得最新的状态。并且很多页面看起来是完全静态的依赖ajax来调用接口，但依旧是PHP驱动的。

至此，大概问题就简单明了了。
一是公网带宽严重不足，加上静态资源没有分离，高峰期服务器带宽撑爆，而程序逻辑导致反复F5以及抢购带来的带宽压力急剧增加。
二是服务器跑的Nginx在Windows平台下，不是最优搭配，Nginx在Windows平台下性能可以用渣来形容。

到这里，我给他的几个建议如下。

• 分离静态资源到独立的域名，并使用CDN加速
• 提高公网带宽
• 服务器软件改为IIS+FastCGI，如果要求靠谱可以上两台应用服务器前端部署负载均衡
• 优化程序逻辑，尽量将页面静态化
• 高峰期如果量过于集中，可以考虑使用部署负载均衡

之所以推荐的是IIS+FastCGI而不是Nginx+LINUX，主要是考虑到配置和维护Linux需要专门的技术人员，而从这个网站的本身制作水准来说这朋友肯定是没有的。再者IIS7以上的FastCGI其实已经很快了，相比Linux而言我觉得在这个等级上应该不会成为PHP的瓶颈。
事实上所购置的阿里云的VPS也不是很高的配置，他把我的建议拿回去捣鼓了一阵子，说他的技术总监给的架构图是这样的。

这……看起来好像也没啥问题，就是这三台web服务器是怎么跟浏览器通信的没搞明白。

为了简化他的配置和维护，所以初期我给他的配置如下。

嗯……你看我给的规划里前端负载均衡（反向代理）依旧用的是Linux+Nginx，只不过后来实施的时候我给换成Windows Server 2012+IIS8.5+ARR了。
而且后来中间的缓存服务器没了，因为用不上，程序特么根本用不到缓存，因为他们根本没做任何缓存！  

就在这时，我发现这系统居然还有个管理后台，依然是PHP写的，依然跑在Windows上，只不过这次服务器软件换成了Apache……
好嘛。Apache on Windows。

除此以外我还提了一些建议，比如优化数据库，加缓存，前端页面静态化等等……
嗯，提完我就去睡觉了。

服务器搭建

后来整个服务器体系除了数据库还是我帮朋友搞的。在这之间就特痛苦其实。
因为一共三台服务器，一台配好域名解析和静态网站，搭建好ARR做负载均衡，另外两台机器搭建好IIS8+FastCGI，配置好了PHP，并且全部开通了FTP，扔给朋友去了。

没过多久朋友就来反馈了，说他的技术反应无法连接数据库，是PHP配置有问题。
为了证明是配置有问题，他的技术还擅自停掉了IIS+FastCGI，在服务器上跑起了upupw，说没问题。

一看到这么不通知直接开搞的就一肚子火。后来测试了很久还是没法正确连接数据库。这时他的技术反馈说，要用PHP5.5，不能用PHP5.6。
我这人有点强迫症，既然有5.6的为什么要用5.5，我就是这么犟。于是研究了很久
哎妈蛋，为了配Oracle的客户端环境可花了我不少时间来着。
最后终于配好了，但依然无法连接数据库。又查了很久，才发现PHP5.6的扩展DLL是12c版本的 php_oci8_12c.dll，而Oracle的InstantClient是 11版本，然而数据库是Oracle9，还是跑在Windows Server 2003上……

艾玛，说好的11G呢 ？那边的技术人员说当时用11G数据库有问题，研发总监当时搞的时候触发器有问题……所以就用9i了。
总之就是数据库版本太低，新版本客户端无法连接了，12G客户端可以连10到12的数据库。而PHP自带的Oracle扩展是10G起步的，PHP5.5的是11G……
所以我觉得最简单的方法，是升级数据库。

于是那边数据库升级到11了。
至此服务器问题解决。
之前没玩过Oracle，这小妖精挺折腾人的。  

数据库瓶颈

这时，遇到了第一个瓶颈：数据库太慢。
为了方便起见，用ab并发500测试，单台服务器每秒只能处理10-15个请求。

为什么说这是数据库的问题呢？因为后来测试了一个测试接口，单机每秒响应1800+请求。

ab有图为证。

按理说Oracle属于大型数据库啊，性能怎么会这么低，简直不可思议。但是我对Oracle完全不熟悉，估计朋友也根本不熟悉，连当时为啥用这个都不知道，估计他的技术人员也只是知道怎么装吧。
在简单看了一下系统配置后，立刻发现了问题。原来数据库配置里居然用的是数据库公网IP进行连接的……
这哪个同学配置的，原力太可怕 。
立刻让改成内网连接。

于是内网连接后，数据库性能上升了五倍。简单地说，就是每秒十几个请求……上升到……每秒五六十。

还是太慢，并且还有很多错误。

但是我对Oracle不熟，提不了啥建议。
于是我觉得最简单的方法，大概就是换掉数据库了……

这时，我给他最简单的建议就是，换成MySQL。
于是他说，好。
换成MySQL后，性能果然就上去了。

速度上升了六倍将近。后面对MySQL做了一些调整，这个数据进一步上升到了一千多。按照常规判断这个瓶颈应该还是在数据库端，但眼下好像没有时间去调整这个事儿了。

第一波高峰

就在此时，第一波高峰到来了。虽然做了这么多工作，网站也终于没有再打不开，但响应还是比较慢，出现的问题依旧较多，比如很多人反映验证码始终提示输入错误。
除此以外，后台监控到的访问出错率也是较高的。

总的来说，蹒跚度过。

先写到这里，后续的问题下次再说。

其实本章说的事儿还比较普通，之后的事儿才叫狗血呢……

感谢阅读本文，欢迎扫描下方二维码关注鱼的公众号（微信内长按识别哦）