面试分析其实就是所谓的高并发。要想弄明白这个问题，就得从高并发的源头说起。为什么会出现高并发？为什么高并发如此牛逼？我说的简单，因为一开始系统是连接数据库的，但是要知道，当数据库支持每秒两三千个并发的时候，基本上就差不多结束了。所以说很多公司，刚开始做的时候，技术比较低。结果，他们的业务发展太快，有时系统会因为压力而失败。当然会挂，为什么不挂呢？如果你的数据库瞬间支持5000/8000甚至几万个并发/秒，那肯定会宕机，因为比如mysql根本无法处理这么高的并发。那么为什么高并发牛逼呢？是因为现在使用互联网的人越来越多，很多APP、网站、系统都承载着高并发请求。高峰期可能每秒有几千个并发请求，这很正常。如果是双十一之类的，每秒几万、几十万的并发交易都是有可能的。那么这么高的并发量，加上这么复杂的业务，怎么玩？真正厉害的一定是那些在复杂的业务系统中玩高并发架构的人，而你不会，那我告诉你这个问题应该怎么回答：可以分为以下6点：1.系统拆分2.缓存3.MQ4.分库分表5.读写分离6.ElasticSearch系统拆分把一个系统拆分成多个子系统，用dubbo来做。然后每个系统都连接一个数据库，所以只有一个库，但是现在有多个数据库，是不是也可以处理高并发。缓存缓存，必须使用缓存。大部分高并发场景都是**读多写少**，那么可以在数据库和缓存中都写一份，然后大量读取缓存。毕竟redis在单机上可以轻松跑上万并发。所以你可以考虑在你的项目中承载主要请求的那些读取场景下，如何使用缓存来抵抗高并发。MQMQ，必须使用MQ。可能你还会有高并发的写场景。比如在一个业务操作中，需要频繁的搞数据库几十次，增删改查，简直是疯了。那个高并发肯定会把你的系统挂掉。如果用redis来托管写，肯定不行。它是一个缓存，数据随时会被LRU。数据格式非常简单，没有事务支持。所以要用mysql就得用mysql。那你怎么办呢？使用MQ，把大量写请求倒入MQ，排队慢慢播放，等后期系统消费后再慢慢写，控制在mysql的范围内。所以你要考虑在你的项目中承载复杂编写业务逻辑的场景下，如何使用MQ异步编写，提高并发性。MQ单机抗几万并发也ok，这个我前面说了。分库分表，分库分表，可能到最后的数据库层面，还是免不了要抗住高并发的需求，好吧，那就把一个数据库拆分成多个库，多个库可以承载更高的并发;然后将一张表**拆分成多张表**，每张表的数据量保持少一点，以提高SQL运行的性能。读写分离读写分离，这意味着大多数时候数据库可能读多写少。没有必要将所有请求都集中在一个库中。可以设置主从架构，主库写，从库读。搞个读写分离。当阅读流量过大时，可以添加更多的从库。ElasticSearchElasticsearch，简称es。es是分布式的，可以随意扩展。分布式的本质是可以支持高并发的，因为它可以通过扩容和增加机器来承载更高的并发。那么一些比较简单的查询和统计操作都可以用es来承载，一些全文搜索操作也可以用es来承载。以上6点基本上是高并发系统必须要做的一些事情。大家可以结合前面提到的知识仔细考虑。到时候你就可以系统的讲解一下这一块，然后每一部分应该注意哪些问题，前面已经讲过了，你可以讲解一下，说明你在这方面有点积累。其实大部分公司真正看重的并不是你掌握了一些高并发相关的基础架构知识，架构中的一些技术，RocketMQ，Kafka，Redis，Elasticsearch，高并发。二流人才。对于一个几十万行代码的复杂分布式系统，一步步架构，高并发架构的设计和实践，这段经历是无价的。
