分析如何支撑高并发?

花了2个小时思考和码字,觉得错误的,可以摒弃;觉得正确的,可以采纳;觉得还有更好的,希望能给出建议。

首先我们要理解什么是“高并发”这个概念,“支撑”的概念主要是目的目标。很多小伙伴面试可能问到这个问题,一上来就说方法,用redis缓存,数据库优化,主从复制,分库分表,还有什么微服务...,相信讲完,面试官可能说“哦~”完了。只讲结果,没去分析原因,人家很肯定知道你在背答案。这也能理解,我们平时很难有机会碰到高并发的项目。只要我们思考过,分析过,一定有所收获。

什么是“高并发”,我们可以从事物都是具有两面性的特性出发。有高,就有低;有并发,也有没并发。 低的时候我们的系统是如何的?高的时候我们的系统是如何的?如果低和高一样的,那肯定完完了。“高并发”就是保证我们的系统高可用性,如同正常(无并发)访问我们的站点一样,提供优质可用服务。

分析“高并发”,我们就要知道目前离高并发的差距是什么?刚才提到优质可用服务,提到高可用系统。在高可用系统的同时,可以能带来很多问题,增加管理的复杂性。所以画出系统图来分析。

分析如何支撑高并发?

箭头 + :A 增强 B增强
箭头 - :A 增强 B减弱

所以高并发不是凭空来的,是我们的优质服务产生的,服务好带来的流量大,这就要求我们保证我们系统高可用性,这样才能带来更多流量。但是什么事情都有个上限,高可用可能带来更多的设备机器设施,增加了我们的管理上的复杂性等问题。但是这些都是保证高可用性支撑高并发要解决的问题和优化的地方。

管理方面涉及东西太多了,本身项目管理的范围就已经够大了。这里不展开了。我们从高可用系统来分析下怎么解决高并发问题。

我这里从4个维度来展开,把它们有效的组合在一起形成了架构,如图:

如何支撑高并发?

看到这张图,大家可以集中注意力,怎么组合搭配,想想大流量网站是如何搭配组合的?在组合有效的基础上再进行作出方案。如果已经有组合的情况下(LNMP)我们可以去画图思考如何做好优化和执行方案。同时在业务的持续演进的时候保证系统的是否能支撑高并发以及系统高可用性。这里只是从整体去观察分析。具体怎么实现,在社区里面有很多同学给出了答案,没有最好的,确实是可行的。

推荐阅读:
你的系统如何支撑高并发?

《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 13
zhaonan99

下次可以试试visio

1周前 评论

@zhaonan99 好的,谢谢建议!我尽快去练习使用。

1周前 评论

@勺颠颠 我们可以分析高并发带来什么问题,通过分析这些问题,我们才能去解决,这才是关键的。只考虑到技术,感觉还是太片面了。看看那些高并发的站点,背后碰到问题是怎么分析解决的,项目是怎么管理的,团队之间是怎么协作的...,能想到这些关系(看不见)才是重要的。

1周前 评论

@vasar 同意。 项目管理也是重要一环

1周前 评论

感觉啥也不说。不过要我个人说,高并发不是某个单方面能达到的,需要语言,软件,方法等的支持。

1周前 评论

工资才几k就,用户规模多少,有没有场景支持?天天撸crud,成功的公司就那么点,再吊的项目也是团队合作开发的,再吊的并发量也是团队一起做的,再吊的公司也是团队一起做的,并发量的支持还是建立在大规模用户的基础之上的,没有这些哪来的并发

1周前 评论

@mmmm 您好,由于每个人的经历不同,会导致感受和观点的也不同。我们不必去关注那些要素产生的结果。而是我们要转变我们的思想,我们的思维不要局限于结果,而是认清里面的各种关系。整体与部分是分割不了的。即对立又统一。工资才几k,没关系,你要想一想,工资30K的人是怎样的。公司也不会随便给一个人高工资。要往好的去想,有好的那还会有更好的。这样你就会有更明确的目标。不知道说得对不对,不对就摒弃,正确可以采纳,有更好的,可以相互交流。谢谢!

1周前 评论
直面苦痛的人生

现在的码农大部分都是混口饭吃,很难有几个会考虑那么多,而且很多小公司的项目根本就没有那么多用户量访问,所以很多都只是懂理念,真正做起来估计一窍不通!!!

1周前 评论

@直面苦痛的人生 人的一生应该是充满热情乐观积极向上的。我们虽然没有优势,但是我们可以自己造势。比如分析一下,自己本地模拟测试一下,和朋友讨论一下,网络搜索一下...方法很多,看你能否把这个理念行动起来,即使失败也是得到。往更好的方面想,你追求的就越多,而你要求就越严格。

1周前 评论
直面苦痛的人生 1周前
vasar (作者) (楼主) 1周前

处理高并发其实是很复杂的,高可用系统要很高,处理大流量怎么处理?加机器?系统抗住了,数据库呢,数据库也加机器,机器加了之后呢,主从复制? 数据库、缓存、业务系统、服务器、任务执行响应等等,任何一个环节都牵扯着太多的东西

1周前 评论

脱离框架谈并发高还是可以的。不过laravel在并发这一块其实不占优势的。加载的组件太多了,导致性能先天不足。不一味的追求理想的数据,利用好高配做一些服务器上的一些策略。其次没有场景的就不要想着并发多高了,这些都是成本的。laravel注重的优雅的写代码,相对java之类的性能太弱了

1周前 评论

@zulien 千万不要这样认为。要搞清楚为什么要用框架?框架可不是随便出现的,它是解决问题的。
下面的概念请认真理解清楚。

  • “设计模式 < 框架< 架构< 平台”: 从复用角度讲,设计模式是代码级复用、框架是模块级复用、架构是系统级复用、平台是企业应用级复用。
  • 模式:即pattern。其实就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度,那就是模式。大型程序使用
  • 框架:即framework。其实就是某种应用的半成品,就是一组组件,供你选用完成你自己的系统。简单说就是使用别人搭好的舞台,你来做表演。而且,框架一般是成熟的,不断升级的软件。
  • 架构:从大的层面来说,比如针对公司业务的B2C网站系统架构,里面可能会用到多种解决各方面问题的框架,关注的是技术整合、扩展、可维护性。换个角度,在框架中也会涉及到架构问题,比如开发NHibernate框架,也需要考虑如何进行设计。
  • 平台:平台的概念类似框架,但又结合的架构的考虑,它是更高层面上的“框架”,准确说是一种应用。它是针对企业用户,为解决企业业务需要而形成的产品。

怎么更具体的理解呢?

  • 类库是工具箱
  • 框架——一套通用解决方案——是书柜架子,可以装门,抽屉通用解决方案,针对不同场景使用。不好跨越(书架不可以睡人),更换框架就像换书架一样,迁移原有物品
  • 架构——高度抽象需求————就是房子的房型图,房间怎么用怎么装修,但是承重墙不能动,80平不会多,人多就住不下
  • 平台——所有可能事情集合————相当于小区,有所限制,有所提供服务

实用来说,平台没啥好选,没多少可选。架构考验人,设计不好就被虐,框架看团队偏好,一般选择熟悉的。库自己选顺手的即可

“laravel 注重的优雅的写代码,相对 java 之类的性能太弱了” ---- 你应该佩服laravel 作者,为什么设计这么好用的框架。设计出一个这么好的舞台,表演如何,就看你演技是否高超了。

3天前 评论

思考问题,记住要多用二维、三维甚至多维的方式(也就是说:是用“立体几何”的思维方式)。用一维的方式思考往往看到的是现象。

3天前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!