前言

相信大家一定遇到面试的时候被问到高并发的问题吧，不少同学没有这方面的实际经验，被问到是不是一脸懵逼，下面我就个人的经历给大家分享分享一下心得吧。

为什么总在说高并发？

在并发不高的场景下，不区分经验是否丰富的任何人都能完成基本的业务开发，而且不会产生任何性能问题，下游依赖、底层存储依赖都不会对你的系统产生影响，但是在并发很高的时候，一切都变了，可能由于高并发环境时下游抖了几ms、db由于高写入或者备库读压力过大而导致主备延迟了一下，你的系统或者业务都会产生故障。

如何积攒“经验”？

对于这个问题，我总结3点可落地：

1. 系统的设计优化：

   首先系统只有无状态的，才能不断横向扩展，才能支撑流量的变化，在业务层的高并发大多都需要不断扩容来支持，但是扩容也不是最根本的方式，如果系统不做优化，一开始扩容大概率是有效的，到一定阶段后就会发现情况开始恶化，因为底层的依赖竞争开始激烈，失败开始增多。优化的尽头往往是对下游依赖和底层数据层的优化，解决方案大多是常见的缓存分层、读写分离、分库分表、异步化等等，但是引入这些技术方案时，会带来一些副作用，接下来你需要解决和屏蔽这些副作用。

2.  业务逻辑的优化：

   当你只是在负责一个流量不大的系统时，是否就没有高并发的机会了呢？其实不然，你需要不断严格要求自己，让业务跑的更快，例如：将单次请求响应耗时从100ms优化到20ms；单机能力从100qps提高到500qps，同时cpu消耗上涨不明显；优化单次请求对缓存和db的放大系数降低，减少对缓存和db的压力。在这个过程中你将积累大量的实战经验，完成业务开发很简单，但是完成一个高效且具备高扩展性的业务开发却是很难的，往前多想几步，你会收获很多。

3. 压测验证：

   在业务体量没有高并发的情况下，只有自己人为创造流量来验证（不过前提是你的系统支持全链路压测，否则压测数据会污染线上真实环境，如果暂时不支持，那么恭喜你，你有机会做一次全链路压测改造了），通过验证在目标水位下的系统表现、机器表现，再继续重复前面两个过程，不断迭代，直到无法扣细节，提高性能；

    

如何展示自己的高并发经验？

只要在日常研发过程中严以律己，做好各项设计和优化，不随意写难易扩展和难易维护的代码，面试的时候就能聊下去。在面试时被问到高并发经验时不要慌，只要按照以下过程表达即可体现你的高并发设计能力：

1. 如何优化单请求耗时：这里你会阐述如何设计和改造系统架构，有可能涉及到jvm的参数优化、各种依赖是如何选型，过程中你积累了哪些选型和优化的方式；

2. 如何提高单机并发能力：这里你会阐述在你的业务中，单机并发能力受限于哪些关键点，这里主要的挑战点是单机的限制条件以及单机资源的竞争，你是如何设计克服的，过程中你积累了哪些设计原则；

3. 如何提高整体并发能力：这里你会阐述在集群环境下最重要的亮点，就是如何处理跨机器的资源竞争以及数据的一致性问题，这里将体现你整体业务架构设计能力；

总结

综上所述，面试时并不是要求你一定要有真实高并发的项目经验，项目经验只是为了验证你真的做过一些设计和优化，如果你能将高并发场景下的设计原则和可能遇到的问题场景和解法都表达清楚，那么我相信面试官也是认可的。