服务器高并发，几乎是每个程序员都想拥有的经验。原因很简单：随着流量变大，会遇到各种各样的技术问题，比如接口响应超时、ＣＰＵ ｌｏａｄ升高、ＧＣ频繁、死锁、大数据量存储等等，这些问题能推动我们在技术深度上不断精进。
在过往的面试中，如果候选人做过高并发的项目，我通常会让对方谈谈对于高并发的理解，但是能系统性地回答好此问题的人并不多，大概分成这样几类：
１、对数据化的指标没有概念：不清楚选择什么样的指标来衡量高并发系统？分不清并发量和ＱＰＳ，甚至不知道自己系统的总用户量、活跃用户量，平峰和高峰时的ＱＰＳ和ＴＰＳ等关键数据。
２、设计了一些方案，但是细节掌握不透彻：讲不出该方案要关注的技术点和可能带来的副作用。比如读性能有瓶颈会引入缓存，但是忽视了缓存命中率、热点ｋｅｙ、数据一致性等问题。
３、理解片面，把高并发设计等同于性能优化：大谈并发编程、多级缓存、异步化、水平扩容，却忽视高可用设计、服务治理和运维保障。
４、掌握大方案，却忽视最基本的东西：能讲清楚垂直分层、水平分区、缓存等大思路，却没意识去分析数据结构是否合理，算法是否高效，没想过从最根本的ＩＯ和计算两个维度去做细节优化。
这篇文章，我想结合自己的高并发项目经验，系统性地总结下高并发需要掌握的知识和实践思路，希望对你有所帮助。内容分成以下３个部分：
如何理解高并发？
高并发系统设计的目标是什么？
高并发的实践方案有哪些？
０１ 如何理解高并发？
高并发意味着大流量，需要运用技术手段抵抗流量的冲击，这些手段好比操作流量，能让流量更平稳地被系统所处理，带给用户更好的体验。
我们常见的高并发场景有：淘宝的双１１、春运时的抢票、微博大Ｖ的热点新闻等。除了这些典型事情，每秒几十万请求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等，都可以归为高并发。
很显然，上面谈到的高并发场景，并发量各不相同，那到底多大并发才算高并发呢？
１、不能只看数字，要看具体的业务场景。不能说１０Ｗ ＱＰＳ的秒杀是高并发，而１Ｗ ＱＰＳ的信息流就不是高并发。信息流场景涉及复杂的推荐模型和各种人工策略，它的业务逻辑可能比秒杀场景复杂１０倍不止。因此，不在同一个维度，没有任何比较意义。
２、业务都是从０到１做起来的，并发量和ＱＰＳ只是参考指标，最重要的是：在业务量逐渐变成原来的１０倍、１００倍的过程中，你是否用到了高并发的处理方法去演进你的系统，从架构设计、编码实现、甚至产品方案等维度去预防和解决高并发引起的问题？而不是一味的升级硬件、加机器做水平扩展。
此外，各个高并发场景的业务特点完全不同：有读多写少的信息流场景、有读多写多的交易场景，下期发布：那是否有通用的技术方案解决不同场景的高并发问题呢？
文章来源：高性能服务器开发 文中图片来源：百度图片
