分析如何支撑高并发？

下次可以试试visio

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

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

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

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

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

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

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

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

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

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

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

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

怎么更具体的理解呢？

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

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

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

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

设备方面，最近阿里云看了个云函数FC不错，很弹性