您现在的位置是：首页>日常分享 日常分享
人为造成所谓的高并发？
楠梓爸爸
2024-06-21 20:33:26
【日常分享】
1460人已围观
简介需求还是伪需求？如图所示的突然需求(内心在想应该可以吧，但是为啥要这么做？)1. 抽奖参与报名的需要在现场报名倒计时内去进行？2. 现场预估人数1.5W-2W？3. 突然的需求支撑...只能去满足。思路梳理一般遇到这种情况该怎么应对？加服务器、增加带宽？但是这不能解决本就只有4核16G内存5MB带宽
需求还是伪需求？
如图所示的突然需求(内心在想应该可以吧，但是为啥要这么做？)
1. 抽奖参与报名的需要在现场报名倒计时内去进行？
2. 现场预估人数1.5W-2W？
3. 突然的需求支撑...只能去满足。
思路梳理
一般遇到这种情况该怎么应对？加服务器、增加带宽？但是这不能解决本就只有4核16G内存5MB带宽的小服务器的现实(没有多余的钱去做这个本身就预算不足).
1. 分析该项目是怎么个组成；
1.1 PHP服务
1.2 NGINX服务
1.3 MYSQL服务
2. NGINX是必须的只能优化下连接数和做部分静态文件缓存，但是访问量突然增大时无法解决带宽问题故只能PASS；
3. PHP服务优化超时及超长时间的进程及时断开加快处理速度，值得优化；
4. MYSQL服务是所有并发的最后壁垒，那就只能想办法变更业务表结构同时只需要进行单表处理，值得优化；
5. 基于以上那还是存在访问的静态资源文件太多带宽不够的问题，思来想去只有走CDN加速处理了，值得优化。
具体实现
1. 将所需的所有静态文件上传CDN进行加速处理；
2. 优化业务表结构做部分字段冗余；
3. 增加部分SQL存储中不变的数据进行缓存处理减少数据库频繁读写；
4. NGINX开启压缩将单个请求压缩到2K左右增加带宽可处理的流量；
实现结果
总结下终究是CDN抗下了所有瞬时流量，所以静态网站并且访问量巨大的情况下还得需要CDN这种神器才是可靠的解决方案。
很赞哦！ (0)
转发分享
网站公告
站点信息
- 服务器软件：nginx/1.18.0
- PHP 版本：7.3.33-16+ubuntu22.04.1+deb.sury.org+1
- 操作系统：Linux
- 内核版本：5.15.0-106-generic
- 系统架构：x86_64
- 脚本执行时间：0.0095秒
- 内存使用量：2.79MB
- 峰值内存使用量：2.87MB
- 文章统计：共3条