壮哉丶
概述
假设报考app是用5w rmb 向供应商采购，报名当天涌入海量考生，并发数飙升至30w+，导致系统宕机，拒绝服务，致使考生无法报名，那么5w rmb 能否支持30w+并发呢？
不过对于我们来说，不妨把问题上升一个角度：「如何在有限的资源里最大提升服务器并发能力」。假设你是一名技术负责人，你在面对一个并发量较大的项目时会如何设计和架构呢？
首先我们可以针对这个项目捋一下大体的思路，从上述描述中不难看出，该项目的瓶颈在于「并发写」而非「读」，因此从资源分配上我们可以向「写」倾斜，在此我将数据全部写入在redis中。除此之外，我们也需要尽量的将mysql的读操作迁移到redis上来，mysql所做的工作更倾向于一些常规非并发的读写操作。
服务器
当用户请求过来，由负载均衡器负载到各个服务器上
这是一张来自symfony的压测数据，使用的是1 cpu, 4 gb and php 7的配置。
上图的数据来自于swoole官网，在加上我们在实际业务逻辑的执行之后，可以发现，当我们在使用常驻内存的启动方式时，3台更低配服务器就能解决上述需要16台才能解决的问题。
数据库
其实许多人在接触后端有一定的阶段之后都会了解，现在的许多互联网项目的瓶颈更多的集中在数据库i/o这块，各个语言之间并没有特别大的差距。包括广被大家所诟病的php-fpm的启动方式，也可以使用swoole等方式来替代。因此，在这个项目中，会将更多的把精力集中于数据库这一块，可以尝试使用redis来解决，当然，在具体代码中，也需要提前准备好一定数量的数据连接池。 另外，也考虑mongodb虽然在同等配置下的写入速度要比mysql快得多，但是相比于redis，还是存在明显不足。
注册登录
注册和登录其实应该分成两块来讲，二者分别对应的是「写」和「读」。在高并发读写情况下，直接使用mysql，如你期待的那样，会爆。因此，我们在构建整个项目的过程中，可以将用户数据缓存到redis中。 「写」的问题：在用户数量不明确且并发量较大的情况下，我更倾向于用户数据不直接入库。我们可以设计一个开关或阈值，来设置用户的入库方式，当并发大的情况下可以通过mq来异步让用户入库，而平时则可以正常入库。
提交表单
因为该项目并非我们所常见的秒杀，且需要即时通知的，因此给我们项目的设计大大减少了难度。在提交表单的功能也跟注册类似，我们完全可以让数据异步入库，然后后台审核。
总结
其他的像cdn、mysql是否需要主从之类的就不再赘述了，视实际情况而定。从理论上，如果使用php-fpm的方式，大概需要19000元/月来解决项目的这个问题，而当使用swoole时，大概需要4500元/月，在这里并没有鼓吹swoole，想说明的是当我们在面对大并发项目时，尤其是业务逻辑相对复杂，我们使用常驻内存更能解决问题，而这与语言无关。 最后，需要说明的是，上述仅是理论阶段，至于实际数据如何都需要进一步检验。文章素材来源于网络，如果有写的不正确的地方，望指出。
以上就是详解php服务器如何在有限的资源里最大提升并发能力的详细内容，更多关于php服务器如何在有限的资源里最大提升并发能力的资料请关注其它相关文章！
