©2020-2024 ioDraw All rights reserved,
Privacy Policy
<>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分布式，可扩容，分布式天然支撑高并发，因为可扩容加机器来抗更高并发。
一些比较简单的查询、统计类的操作，可以考虑用ES承载，还有一些全文搜索类的操作，也可以考虑用ES。
<>总结
真正你厉害的一点，不是在于弄明白一些技术，或者大概知道一个高并发系统应该长什么样。
实际上在真正的复杂的业务系统里，做高并发要远远比说的复杂几十倍到上百倍。
需要考虑，哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何join，哪些数据要放到缓存里去啊，放哪些数据再可以抗掉高并发的请求，你需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是务必复杂的。
一旦做过一次，做好了，在这个市场上就会非常的吃香。
公司真正看重的，不是说你掌握高并发相关的一些基本的架构知识，架构中的一些技术，RocketMQ、Kafka、Redis、Elasticsearch，高并发这一块，次一等的人才。
对一个有几十万行代码的复杂的分布式系统，一步一步架构、设计以及实践过高并发架构的人，这个经验是难能可贵的!