时间追溯到2月份，一个历时20天的小项目上线了。
20天。能干点啥，你我都能懂吧，但是还是赶出来了
项目背景是一个类似企业分享直播的平台（结合第三方），根据客户需求，这次分享最多300人参加（线上=移动+PC），然后架构设计拟定为单体架构，不用过多优化，正常开发就可以。但是就在直播开始的前几分钟，后台出现了，数据库连接数过多，系统一会直接崩了。
之后迅速查看阿里云后台监控发现tcp连接居然有5000，小声（wocao）
说好的不到300人呢，你是不是在逗我。
之后迅速升级网站配置，重启服务器，之后还是崩溃？
因为阿里云的服务器（其他的服务器不知）有自我保护意识，到达一定的并发，将自启保护措施（类似），然后这就相当于我们升级分配置服务器将无法使用，之后调整服务器的配置就行优化
然后重启，趋于稳定，但是这已经是开播的10分钟之后，聊天室此时各种抱怨，怎么刚才进不来。。。。
最终直播结束，这也宣布这次直播服务失败（编写事故汇报），和客户撕逼
最终确认下次直播，人数将达到5000人，接下来就是各种优化
首先我们加了一个cdn，，然后压缩js+css，压缩图片
之后将首页做了页面静态化，之后升级服务器的带宽，压力测试5000并发，ok了
在之后就是优化直播页面，难点在于：实时更新在线人数（人气），动态加载用户信息，动态渲染页面
解决
（1）实时更新在线人数：使用websocket做长连接，减少每次握手带来的消耗，将数据存储在redis里面，每次请求直接从redis里面获取，之后根据关闭浏览器来减少redis人气数（非强一致性）
（2）动态加载用户信息
1）将登陆方式改成点击操作才登陆，这样就能减少一部分并发的可能性
2）将会用的信息存储在redis里面做队列存储
由于时间关系，我们选择了第一种方案，然后模拟测试，还算ok
（3）动态渲染页面：将一些实时的参数通过实时的ajax加载，然后其他非实时参数做静态缓存
第二次直播，顺利完成！！！
总结：
（1）服务器配置要跟得上
（2）判断是cpu计算密集型还是非密集型
（3）查看是否吃带宽，然后升级带宽
（4）尽量将流量限制在上游，让操作数据的业务尽量来的晚一些
（5）判断业务是否适合做页面静态化，这样大大提高并发
（6）如果在apache和nginx里面选择的话，nginx处理静态资源真的很强大，还是用nginx吧-非绝对，自己判断
最后加环境：PHP+Mysql+Nginx+Linux
祝大家5.1快乐
网友评论