大多数人面试的时候经常会被问到:你简历上有高负载高并发的经验,那到底你的系统是怎样设计的?
如果没有过相关的项目经验,大多数同学被问到这个问题压根儿没什么思路去回答,不知道从什么地方说起,其实,就算没有相关的经验,只要事先编好话术,搞清楚架构图,回答此类问题也还是可以滴水不漏的。
首先,在脑子里虚拟一个大用户量背景下的场景,如果我们手头有几台4核8g的服务器,假设一个平台用户量是500万。此时日活用户是50万,日访问量在600-700万左右,高峰期对系统每秒请求是500/s。然后对数据库的每秒请求数量是1500/s,这个时候会怎么样呢?如果系统内处理的是较为复杂的一些业务逻辑,是那种重业务逻辑的系统的话,是比较耗费CPU的。此时,4核8G的机器每秒请求达到500/s的时候,很可能你的机器CPU负载较高了。然后数据库层面,以上述的配置而言,其实基本上1500/s的高峰请求压力的话,还算可以接受。这个主要是要观察数据库所在机器的磁盘负载、网络负载、CPU负载、内存负载,按照我们的线上经验而言,那个配置的数据库在1500/s请求压力下是没问题的。所以此时需要做的一个事情,首先就是要支持你的系统集群化部署。可以在前面挂一个负载均衡层,把请求均匀打到系统层面,让系统可以用多台机器集群化支撑更高的并发压力。比如说这里假设给系统增加部署一台机器,那么每台机器就只有250/s的请求了。这样一来,两台机器的CPU负载都会明显降低,这个初步的“高并发”不就先抗住住了吗?要是连这个都不做,那单台机器负载越来越高的时候,极端情况下是可能出现机器上部署的系统无法有足够的资源响应请求了,然后出现请求卡死,甚至系统宕机之类的问题。所以,