庆祝昨晚至今天早晨，并发量达到8万，人生中的第一个万级并发，也庆祝第一个自己做的应用在朋友圈被那么多人转发，而活动被不少增长大v拿去做黑客增长分析案例。在此记录自己对高并发出现时的优化处理经验。
在此前，并发平均在4000左右，配置是一台mysql、一台redis、一台主服（8g、4核）、两台从服（4g、2核），每天都过的安安稳稳，但是没有时间做好代码优化，代码优化没做好是处理不好高并发的原因之一。
昨晚突然爆发，并发量从4000飞涨到8万，服务器当然是跪了。
在一切的优化前，有一个重点就是，所有的慢日志在项目上线后都得打开，不然出问题时不好分析，其次是要在云服务商那里打开关键数据的报警。
一、首先还是从云服务商的监控入手，查看带宽、cpu、和内存、连接数等数据情况。
（1）带宽，在高并发时出现带宽问题，就应该立马升级带宽，升级带宽后检查是否有什么资源文件从业务服务器输出了，如果有就立马将资源的位置切换到别处去，不能放在业务服务器去输出。其次，优化带宽输出、nginx流量压缩要放在平日里做，资源文件切勿放在业务服务器中，图片可以放在七牛云那些cdn，更或者可以直接上传到新浪微博等，提取连接，这样可以省下不少带宽。在昨晚的高并发问题中，带宽流出特别夸张，带宽达到50m，这其中是因为接口输出的数据量不够精简，其次是nginx没有做好流量压缩，当然最最主要是访问量太太太大了。理应将每个接口优化到最大800b左右的量。
（2）CPU，进入服务器内查看占用CPU过高的进程，一般会是php-fpm占用过高，当业务逻辑写得不够好的时候php-fpm会加大CPU占用，如果是在负载均衡的情况下，其中一台CPU崩了，可以先将这台服务器的负载配比调低或者直接去掉，然后排查nginx的慢日志，PHP-FPM的慢日志，还有PHP的错误日志，查看是什么代码或者是nginx、php-fpm的配置数量不足，抑或是可以从中查看到数据库和redis慢查询的问题，至于nginx、php-fpm等服务器应用的配置记录在第二点。
待续。。
网友评论