点击蓝字关注我们吧!
1 为什么面试官爱问这种面试题?
- 因为招聘中大家都有这个要求。
技术强的人,在互联网公司肯定负责过高并发模块,那夺取offer太简单了。可惜大部分初级工程师甚至高并发代码都没想过怎么写! 不是说只要用个redis缓存,用个mq异步削峰就搞定了!真实的要复杂很多倍。
面试官问你如何设计一个高并发系统,其实多半是因为知道你没干过高并发。看你简历也没啥特别的,所以就问问你,如何设计。就是想考察你是否有技术储备。
最好是招聘个真正有高并发经验的,但众所周知国内缺乏这种中高级开发。所以退而求其次,招个至少研究过的,也比招个啥想法也没有的好。
话不多说,开始干货输出,来看如何回答该问题!
2 服务拆分
将一个服务拆为多个服务。每个服务单独连一个数据库,这样原本只有一个库的,现在有多个数据库,最容易做到的抗高并发。即微服务架构。
3 缓存
高并发场景,大多读多写少,可以在数据库和缓存里都写一份,然后读时大量走缓存。
而Redis轻轻松松单机几万并发,所有系统都有缓存中间件。所以考虑在你的项目中,让承载主要请求的读场景,使用缓存来抗吧。
4 消息队列
可能还是会出现高并发写场景(秒杀场景)。那绝对搞挂你的系统,11.11都得卡,你要是用Redis承载写肯定不行,它是缓存,数据随时被LRU,数据格式还简单,没有事务支持。 所以该用MySQL还得用MySQL。咋办?
用MQ!大量的写请求灌入MQ,排队一个个慢慢来,后边系统消费后慢慢写,控制在MySQL的承载范围。 所以考虑你的项目里,那些写场景,用MQ异步写,提升并发性。MQ单机抗几万并发也ok。
5 分库分表
可能到最后的数据库层,还是免不了抗高并发。 那么就将一个数据库拆为多个库,多个库来抗更高并发。 将一个表拆分为多个表,每个表的数据量保持少一点,提高SQL性能。
6 读写分离
数据库层的承载可能也大多是读多写少,那就没必要所有请求都集中在一个库。 可以设计主从架构,主库写,从库读,实现读写分离。如果读流量太多,再加从库。
7 Elasticsearch
分布式,可扩容。一些较简单的查询、统计类的、全文搜索类的操作,可考虑使用ES承载。
8 总结
其实设计远不止说的这么简单,很多细节需要考虑: 哪些才需要分库分表,单库单表跟分库分表如何join,哪些数据才放进缓存…… 一旦做过一次,做好一次,以后都会非常吃香。