网站如何应对高负载

最近面试了两家公司,虽然说他们产品研发团队不是怎么大,也在组建过程中,但估计leader是有点料的,总是抓住高负载的问题不放,本人才疏学浅,只能答一些表面的东西,最终基于各方面评价被pass。在此列一下自己关于这个问题的答案,希望大家有补充完善-_-

  1. 前端资源尽量减少请求量,只加载一个css文件和js文件,使用工具对css和js文件进行压缩;
  2. 服务器nginx配置前端资源缓存,与资源压缩(问我nginx了解多少,内部原理等,不好意思,只了解web站点的配置,只知道nginx接收到请求分配给php-fpm进程来处理业务的,又问我php-fpm接收到任务内部是怎么运行的,对不起,这个没研究过);
  3. 从业务代码层面上进行优化,优化算法;
  4. 对请求数据库的sql进行调优,可以通过慢查询进行检查;
  5. 对数据库进行优化,数据库字段及索引方面,分库分表(但是不建议,目前项目有这样使用,接手的时候别人设计的,带来很多后续问题不好解决);
  6. 使用缓存opcache,使用中间件memcache或redis(类型有几种,5种,都在什么场景下使用,嗯。。。。答不出来);
  7. 使用负载均衡(用过吗?学习的时候玩过,实际项目没用过,只是简单用阿里的负载均衡);
  8. 数据库集群,主主复制,主从复制,写主服务器,读从服务器(通过什么来进行同步的?binlog。用过吗?实际项目没有用过,只是学习的时候自己搭虚拟机玩过而已);
  9. mysql数据库承受多大的压力,答曰:这个看别人文章了解到是能够承受千万级别是没有问题的。测试过吗,答曰:这个还真没有测试过。

以上是我对面试遇到这个问题的回答总结,当然,面试的时候可以没有想得这么全面,回答的这么全面,欢迎大家来总结补充。

当然还有其他共同的问题,回头再来总结

  • 怎么理解MVC
  • 抽象类和接口的区别
  • 设计模式
雪花飘
本帖已被设为精华帖!
本帖由 Summer 于 6年前 加精
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 18
leo

高负载问题需要了解前提条件,不同类型的项目解决方案完全不同

6年前 评论

@leo 面试官其实就是要看你了解多少

6年前 评论
leo

@Winner 如果你在面试过程中能提出我说的问题,相信会加分不少

6年前 评论

Mysql 可以承受千万级,但读写性能下降得厉害。合理的监界点是10万,警戒线是100万。

假如数据量真的大到千万级,分库分表主从读写分离等等都可以有效缓解并且同时引入更多的复杂性,上SSD还能再提升些性能但会带来成本上升。这些都不是终极解决之道。

上千万的数据。考虑换 DBMS 吧。你可以考虑下 Postgresql 。不要让 Mysql 再受苦了。Mysql 宝宝很可怜的。

6年前 评论

@qufo 长知识了,请问你的这个数据是怎么来的,实际项目经验还是用apache的ab?了解一下就不会被面试官觉得我瞎说了,感谢科普!

6年前 评论
JaguarJack

@qufo 维基百科怎么讲?就是mysql分支

6年前 评论

@Winner web码农自己,高并发高可用这些知识,日常工作可能接触不到,一般门户网站才面临这种,我自己反正都是做内部系统比较多,偶尔做的门户网站,访问量少的可怜,那么并发这些东西,也只能自行学习了解了。

公司面试,如果他们项目真的面临负载问题当然没话说,
但有的时候,面试官只是在问些冷门问题考倒你压压价格,
还有的时候只是在秀自己,遇到过那种新公司项目一台低配服务器,一天十几个ip,问你负载问你集群

6年前 评论

@梦康 当然,这些高并发知识我们日常是很少遇到,即使有公司的项目遇到,那也是有专业的运维来管理,但这些知识我们又必须要了解来应对面试,比如普通的排序算法,虽然实际项目中没有用到,却经常会出现在我们面试前的笔试卷子上。

6年前 评论

@Winner 单纯实战经验而已,数据早已丢失。

6年前 评论

@吴彦文 这个没法讲,阿里还改造过 Mysql 呢。阿里的访问量是多少呀,维基万科也难以望其项背吧。

我们有能力改造 Mysql 么?

6年前 评论
JaguarJack

@qufo 我只是对你的回答不敢苟同,只是千万级别的数据, 居然就把mysql 剔除了!TB级别数据量, MySQL也有能力

6年前 评论

@吴彦文 倒不是剔除了,并不代表 Mysql 不能做。只是会花费比较高昂的代价,所以我们选择避开他。

在服务器上捅满内存,从内存虚拟一个硬盘,把 数据放在这个虚拟硬盘上,甚至 Mysql 应用也放在这个虚拟硬盘上。然后往里灌入2亿的数据,做好索引再查询,速度也杠杠的。性能问题其实还是 IO 问题。

2011年的时候真做过这事,当时的交易数据2个多亿条,与交易关联的各种流程记录文件加起来远超10亿。靠这个方案挺过了那个艰难的岁月,直至后面我们的应用系统大升级,丢掉了大部分数据。----只保留最近3年。

放内存上掉电怎么办?我们有 UPS 呀。 UPS 也不能保证不断电呀。所以我们还有从库呀。从库反而不参与查询,只管保存数据了。

2011年的时候哪个企业有那么大的数据?拿起身边的手机你就知道了。

6年前 评论
JaguarJack

@qufo 厉害厉害, 我还没经历过E级别的数据, 还是你们有经验。受教受教

6年前 评论

现在都2018年了, mysql都到8.0了, 读写性能早就翻了几个指数级别了, 麻烦多关注业界动态.

5年前 评论

直接怼过去:业务量这么大也不请个运维吗?是公司穷还是领导喜欢意淫。

2年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!