假设申请app使用5W元向供应商采购，报名当天大量考生涌入，并发数飙升至30W+，导致系统宕机，拒绝服务，考生报名失败，那么5W元能支持30W+的并发吗？？但对于我们来说，不妨换个角度提出问题：“如何在有限的资源下，最大化服务器的并发能力”。假设你是技术负责人，你会如何设计和架构一个大并发量的项目？首先，我们可以给这个项目一个大概的概念。从上面的描述中不难看出，这个项目的瓶颈在于“写并发”而不是“读”。因此，我们在资源配置上可以向“写”倾斜。这里我把所有的数据都写在Redis中。此外，我们还需要尽可能将MySQL的读操作迁移到Redis。MySQL所做的工作更倾向于一些常规的非并发读写操作。当用户请求时，服务器由负载均衡器加载到每个服务器。我的php学习交流社区“点击”管理整理了一些资料。BAT等一线大厂进阶知识体系齐备（相关学习资料和面试笔试题）且不限于：分布式架构、高扩展、高性能、高并发、服务器性能调优、TP6、laravel、YII2、Redis、Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等进阶干货需要的知识点都可以免费分享给大家。这是来自symfony的压测数据，使用1个CPU，4GB，PHP7的配置。上图数据来自swoole官网。添加我们实际的业务逻辑执行后可以发现，当我们使用常驻内存启动方式时，3台低配服务器就可以解决上述16台服务器的需求。解决了问题。其实很多人接触后端一段时间后，就会对数据库有所了解。现在很多互联网项目的瓶颈都比较集中在数据库I/O上，语言之间并没有特别大的差距。包括大家广为诟病的PHP-FPM的启动方式，也可以换成swoole等方式。所以在这个项目中，更多的精力会集中在数据库上，可以尝试使用Redis来解决。当然，在具体的代码中，还需要提前准备好一定数量的数据连接池。此外，还考虑到虽然在相同配置下MongoDB的写入速度比MySQL快很多，但与Redis相比还是有明显的短板。注册和登录注册和登录其实应该分为两部分，分别对应“写”和“读”。在高并发读写的情况下，直接使用MySQL会如你所料的那样爆炸。因此，我们可以在构建整个项目的过程中，将用户数据缓存在Redis中。“写”问题：当用户数不清楚，并发量大的时候，我宁愿不直接存储用户数据。我们可以设计一个开关或者阈值来设置用户的入库方式。当并发量大的时候，我们可以异步让用户通过MQ入库，而普通入库可以正常进行。提交表单因为这个项目不是常见的闪购，需要即时通知，所以大大降低了我们项目设计的难度。提交表单的功能也类似于注册。我们完全可以异步存储数据，然后在后台查看。综上所述，其他的像CDN，MySQL，需要master-slave等等，就不细说了，看实际情况。理论上，如果使用PHP-FPM方式，解决项目这个问题需要19000元/月左右，而使用swoole时，需要4500元/月左右。这里不提倡swoole。我想说明的是，当我们面对大型并发项目时，尤其是业务逻辑比较复杂的时候，使用常驻内存可以更好的解决问题，这与语言无关。最后需要说明的是，以上只是理论阶段，至于实际数据还需要进一步测试。文章素材来源于网络。如果有不对的地方，请指出。★PHP互联网架构师成长指南+行业解题大纲（持续更新中）★面试10家公司，拿到9份offer，2020年PHP面试题★如果你喜欢我的文章，想和更多资深开发者交流学习，获得更多技术各大厂商面谈相关咨询指导，欢迎加入我们的群——点击这里。
