昨日在知乎看到一个问题:如何用5W rmb支持34W并发?。
背景如下:
在《这垃圾APP,差点毁了70万高考生》一文中,艺术学院报考app是用5W rmb 向供应商采购,报名当天涌入海量考生,并发数飙升至34W,导致系统宕机,拒绝服务,导致考生无法报名,舆情哗然,那么5W rmb 能否支持34W并发呢?
虽然有很多能人志士各抒己见,但是我认为答的都不是特别全面。我们不妨把问题再上升一个角度:「如何在有限的资源里最大提升服务器并发能力」。假设你是一名技术负责人,你在面对一个并发量较大的项目时会如何设计和架构呢?
首先我们可以针对这个项目捋一下大体的思路,从上述描述中不难看出,该项目的瓶颈在于「并发写」而非「读」,因此从资源分配上我们可以向「写」倾斜,在此我将数据全部写入在Redis
中。除此之外,我们也需要尽量的将MySQL
的读操作迁移到Redis
上来,MySQL
所做的工作更倾向于一些常规非并发的读写操作。
以上是我对此项目所整理的技术架构图,接下来我会对此一一详细说明。
服务器
当用户请求过来,由负载均衡器负载到各个服务器上,需要说明的是,此处以我所熟悉的语言举例说明,至于使用其他语言处理是否会节省服务器资源(后面我会迭代一版Java
的压测报告),欢迎各位指导。
这是一张来自symfony的压测数据,使用的是1 CPU, 4 GB and PHP 7
的配置。算上我们自身的业务逻辑,我们在8 CPU, 32 GB
取24000QPS
的均值来计算,之所以能这样来计算是因为我们的I/O
逻辑都安排在Redis
中,而官方给出的Redis
的读写速度大概在200K/S。
此图的数据来自于swoole
官网,在加上我们在实际业务逻辑的执行之后,不难发现,当我们在使用常驻内存的启动方式时,3台更低配服务器就能解决上述需要16台才能解决的问题。
数据库
其实许多人在接触后端有一定的阶段之后都会了解,现在的许多互联网项目的瓶颈更多的集中在数据库I/O
这块,各个语言之间并没有特别大的差距。包括广被大家所诟病的PHP-FPM
的启动方式,也可以使用swoole
等方式来替代。因此,在这个项目中,我会更多的把精力集中于数据库这一块,我们可以尝试使用Redis
来解决,当然,在具体代码中,我们也需要提前准备好一定数量的数据连接池。
其实最开始在规划的时候我有考虑过MongoDB
,坦率地讲,在同等配置下,MondoDB
的写入速度要比MySQL
快得多,但是相比于Redis
,还是存在明显不足。
注册登录
其实注册和登录应该分成两块来讲,二者分别对应的是「写」和「读」。首先解决读的问题,看过那篇报道的文章,许多学生反馈完全登录不上去。在这么高的读写情况下,直接使用MySQL
不爆才怪。因此,我们在构建整个项目的过程中,可以将用户数据缓存到Redis
中。
其次,写的问题。在用户数量不明确且并发量较大的情况下,我更倾向于用户数据不直接入库。我们可以设计一个开关或阈值,来设置用户的入库方式,当并发大的情况下可以通过MQ
来异步让用户入库,而平时则可以正常入库。
提交表单
因为该项目并非我们所常见的秒杀,且需要即时通知的,因此给我们项目的设计大大减少了难度。在提交表单的功能也跟注册类似,我们完全可以让数据异步入库,然后后台审核。
总结
其他的像CDN
、MySQL
是否需要主从之类的就不再赘述了,视实际情况而定。从理论上,如果使用PHP-FPM
的方式,我们大概需要19000元/月来解决项目的这个问题,而当我们使用swoole
时,我们大概需要4500元/月,我在这里并没有鼓吹swoole
,我想说明的是当我们在面对大并发项目时,尤其是我们的业务逻辑相对复杂,我们使用常驻内存更能解决问题,而这与语言无关。
最后的最后,需要说明的是,上述仅仅只是理论阶段,至于实际数据如何还得进一步检验。如果有写的不正确的地方,还望不吝指点。
来源:https://hellonine.top/index.php/archives/104/
友情提示:垃圾评论一律封号...