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，哪些数据才放进缓存…
一旦做过一次，做好一次，以后都会非常吃香。
