如何实现一个高并发的系统
更新: 5/5/2025 字数: 0 字 时长: 0 分钟
所实话,真正的高并发系统就不是面试的时候一两句话能说清楚的,也不是上个Redis,Rocket就能解决的,所以一般问这种问题就说明面试官直到你没做过真正的企业级高并发项目,想问问你对高并发系统有没有研究过,让你开放式吟唱八股文
大致部分
没有触碰过真正的高并发项目,那就只能胡了,把能想到的和高并发相关的技术栈有条理的总结一遍然后交上去
- 系统拆分:通过才分为多个微服务分布式部署来提高性能
- 缓存:直接访问内存提高读效率
- MQ:削峰,异步
- 分库分表:提高数据库的并发承受能力
- 读写分离:提高数据库的并发承受能力
- ElasticSearch
系统拆分
将原本的系统拆分为多个微服务,然后使用Dubbo来进行通讯,这样就从原本的单体部署变成了分布式部署,使用的机子多了,性能自然就上来了,并发也就能抗住了
缓存
你都高并发了还能不上缓存?对于大多数的业务场景,读的要求远大于写,因此我们完全可以将部分热点数据放到缓存里面,让缓存来返回数据,万级的并发Redis还是能轻松抗住的
MQ
消息队列也是必不可少的一部分了,对于一个高并发的场景,我们必须要假设你的服务器再nb也没用,这时候就只能对接口做一些限制,使用MQ来对数据进行慢慢的消费,我管你这那的,先进MQ,然后MQ以一个固定的流速放出消息,这样就能将我们的系统压力放小
分库分表
到最后不还是得来数据库,你的数据库还是用的MySQL这种重量级的老家伙,你不分库不表能行吗,将一个表横向拆分进行扩容,使用Id取mod的形式来进行存放,每个表的数据少一点,这不就能抗住并发了嘛
读写分离
那必然得是要读写分离的,都说了读多写少,那就一个写库,一堆读库,钱都花在刀刃上,读流量多,那就读库多,以最大的性能堵住需求
ElasticSearch
ES天生分布式,随便扩容,天生就是为了抗住高并发而生的,统计(比如求论坛系统内总共有多少篇帖子),搜索一类的操作就叫交给ES来进行操作,这不简简单单