如何获得高并发的项目经验？

02

淘系技术部-行业与智能运营架构组-仲春

“在面试时被问到高并发经验时不要慌，按照以下过 程表达即可体现你的高并发设计能力：优化单请求耗时、提高单机并发能力、提 高整体并发能力。”

个人认为，其实我们并不用去追求严格意义上的高并发经验，因为很多时候都没有这样的机会给到你，对于高并发的处理经验主要体现在日常的积累以及对自己的严格要求上。

   为什么总在说高并发？

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

  如何积攒“经验”？

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

• 系统的设计优化

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

• 业务逻辑的优化

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

• 压测验证

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

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

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

• 如何优化单请求耗时

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

• 如何提高单机并发能力

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

• 如何提高整体并发能力

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

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

“对于高并发系统设计，个人推荐可以自底向上的分成三个部分，首先是建立基础知识体系，其次是熟悉业界解决方案，最后是分布式系统设计。 ”

首先高并发的系统也不是最初就设计出来的， 一切解决方案都是来自于业务场景 。

大多是针对特定时期内的问题与挑战，一步一步演化出来的。即便是在有高并发场景的公司里的研发同学，如果不是去参与解决这些问题，往往也不能直接获得高并发的经验积累。所以没有场景的公司里面的研发同学，大家的起点其实是差不多的，完全不用虚，关键还是在于掌握其中的核心科技。

对于高并发系统设计，个人推荐可以自底向上的分成三个部分，首先是 建立基础知识体系 ，其次是 熟悉业界解决方案 ，最后是 分布式系统设计 。

知识体系的建立要更多的去关注底层，如算法、缓存、多线程、并发、JVM、OS、网络、分布式理论等，这些东西相对稳定，在这些底层技术的基础上的解决方案好像层出不穷，如各种缓存技术、各种消息队列、各种数据库。但是掌握了底层原理，再去看上层的解决方案就能有触类旁通的效果。对于最后的分布式系统设计，就是针对具体业务场景去应用相应的技术，组装成一套体系的方案。

对于知识的学习资料网上已经非常多，可以自行学习建立体系。自己公司没有具体的场景，就去各大公司的技术博客学习业界方案。业界方案的学习推荐更多的思考其中的原因（Why），这个才是系统设计的核心。

比如一个环节拿掉会对系统产生什么样的影响？换成另外一个技术会有什么不同？下面主要讲一下面试中对于系统设计的解答思路。