高并发，简直是每个程序员都想领有的教训。起因很简略：随着流量变大，会遇到各种各样的技术问题，比方接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些问题能推动咱们在技术深度上一直精进。在面试中，高并发也是咱们不可避免问到的一个点，然而高并发你真的了解透彻了吗？明天小编就跟大家来说一说高并发以及高并发大厂面试真题解析！

作为浏览福利，小编也整顿了高并发相干学习材料跟面试真题，当初分享给浏览到本篇文章的Java程序员敌人们，须要的可【点击此处】

在过往的面试中，如果候选人做过高并发的我的项目，我通常会让对方谈谈对于高并发的了解，然而能系统性地答复好此问题的人并不多，大略分成这样几类：

1、对数据化的指标没有概念：不分明抉择什么样的指标来掂量高并发零碎？分不清并发量和QPS，甚至不晓得本人零碎的总用户量、沉闷用户量，平峰和顶峰时的QPS和TPS等要害数据。

2、设计了一些计划，然而细节把握不透彻：讲不出该计划要关注的技术点和可能带来的副作用。比方读性能有瓶颈会引入缓存，然而漠视了缓存命中率、热点key、数据一致性等问题。

3、了解全面，把高并发设计等同于性能优化：大谈并发编程、多级缓存、异步化、程度扩容，却漠视高可用设计、服务治理和运维保障。

4、把握大计划，却漠视最根本的货色：能讲清楚垂直分层、程度分区、缓存等大思路，却没意识去剖析数据结构是否正当，算法是否高效，没想过从最基本的IO和计算两个维度去做细节优化。

这篇文章，我想联合本人的高并发我的项目教训，系统性地总结下高并发须要把握的常识和实际思路，心愿对你有所帮忙。内容分成以下3个局部：

• 如何了解高并发？
• 高并发零碎设计的指标是什么？
• 高并发的实际计划有哪些？

01 如何了解高并发？

高并发意味着大流量，须要使用技术手段抵制流量的冲击，这些伎俩好

来源gao!daima.com搞$代!码网

比操作流量，能让流量更安稳地被零碎所解决，带给用户更好的体验。

咱们常见的高并发场景有：淘宝的双11、春运时的抢票、微博大V的热点新闻等。除了这些典型事件，每秒几十万申请的秒杀零碎、每天千万级的订单零碎、每天亿级日活的信息流零碎等，都能够归为高并发。

很显然，下面谈到的高并发场景，并发量各不相同，那到底多大并发才算高并发呢？

1、不能只看数字，要看具体的业务场景。不能说10W QPS的秒杀是高并发，而1W QPS的信息流就不是高并发。信息流场景波及简单的举荐模型和各种人工策略，它的业务逻辑可能比秒杀场景简单10倍不止。因而，不在同一个维度，没有任何比拟意义。

2、业务都是从0到1做起来的，并发量和QPS只是参考指标，最重要的是：在业务量逐步变成原来的10倍、100倍的过程中，你是否用到了高并发的解决办法去演进你的零碎，从架构设计、编码实现、甚至产品计划等维度去预防和解决高并发引起的问题？而不是一味的降级硬件、加机器做程度扩大。

此外，各个高并发场景的业务特点齐全不同：有读多写少的信息流场景、有读多写多的交易场景，那是否有通用的技术计划解决不同场景的高并发问题呢？

我感觉大的思路能够借鉴，他人的计划也能够参考，然而真正落地过程中，细节上还会有有数的坑。另外，因为软硬件环境、技术栈、以及产品逻辑都没法做到完全一致，这些都会导致同样的业务场景，就算用雷同的技术计划也会面临不同的问题，这些坑还得一个个趟。

因而，这篇文章我会将重点放在基础知识、通用思路、和我已经实际过的无效教训上，心愿让你对高并发有更深的了解。

02 高并发零碎设计的指标是什么？

先搞清楚高并发零碎设计的指标，在此基础上再探讨设计方案和实践经验才有意义和针对性。

2.1 宏观指标

高并发绝不意味着只谋求高性能，这是很多人全面的了解。从宏观角度看，高并发零碎设计的指标有三个：高性能、高可用，以及高可扩大。

1、高性能：性能体现了零碎的并行处理能力，在无限的硬件投入下，进步性能意味着节省成本。同时，性能也反映了用户体验，响应工夫别离是100毫秒和1秒，给用户的感触是齐全不同的。

2、高可用：示意零碎能够失常服务的工夫。一个全年不停机、无故障；另一个隔三差五出线上事变、宕机，用户必定抉择前者。另外，如果零碎只能做到90%可用，也会大大连累业务。

3、高扩大：示意零碎的扩大能力，流量顶峰时是否在短时间内实现扩容，更安稳地承接峰值流量，比方双11流动、明星离婚等热点事件。

​

这3个指标是须要通盘考虑的，因为它们相互关联、甚至也会相互影响。

比如说：思考零碎的扩大能力，你会将服务设计成无状态的，这种集群设计保障了高扩展性，其实也间接晋升了零碎的性能和可用性。

再比如说：为了保障可用性，通常会对服务接口进行超时设置，以防大量线程阻塞在慢申请上造成零碎雪崩，那超时工夫设置成多少正当呢？个别，咱们会参考依赖服务的性能体现进行设置。

2.2 宏观指标

再从宏观角度来看，高性能、高可用和高扩大又有哪些具体的指标来掂量？为什么会抉择这些指标呢？

❇ 性能指标

通过性能指标能够度量目前存在的性能问题，同时作为性能优化的评估根据。一般来说，会采纳一段时间内的接口响应工夫作为指标。

1、均匀响应工夫：最罕用，然而缺点很显著，对于慢申请不敏感。比方1万次申请，其中9900次是1ms，100次是100ms，则均匀响应工夫为1.99ms，尽管均匀耗时仅减少了0.99ms，然而1%申请的响应工夫曾经减少了100倍。

2、TP90、TP99等分位值：将响应工夫依照从小到大排序，TP90示意排在第90分位的响应工夫， 分位值越大，对慢申请越敏感。

​

3、吞吐量：和响应工夫呈正比，比方响应工夫是1ms，则吞吐量为每秒1000次。

通常，设定性能指标时会兼顾吞吐量和响应工夫，比方这样表述：在每秒1万次申请下，AVG管制在50ms以下，TP99管制在100ms以下。对于高并发零碎，AVG和TP分位值必须同时要思考。

另外，从用户体验角度来看，200毫秒被认为是第一个分界点，用户感觉不到提早，1秒是第二个分界点，用户能感触到提早，然而能够承受。

因而，对于一个衰弱的高并发零碎，TP99应该管制在200毫秒以内，TP999或者TP9999应该管制在1秒以内。

❇ 可用性指标

高可用性是指零碎具备较高的无故障运行能力，可用性 = 均匀故障工夫 / 零碎总运行工夫，个别应用几个9来形容零碎的可用性。

​

对于高并发零碎来说，最根本的要求是：保障3个9或者4个9。起因很简略，如果你只能做到2个9，意味着有1%的故障工夫，像一些大公司每年动辄千亿以上的GMV或者支出，1%就是10亿级别的业务影响。

❇ 可扩展性指标

面对突发流量，不可能长期革新架构，最快的形式就是减少机器来线性进步零碎的解决能力。

对于业务集群或者根底组件来说，扩展性 = 性能晋升比例 / 机器减少比例，现实的扩大能力是：资源减少几倍，性能晋升几倍。通常来说，扩大能力要维持在70%以上。

然而从高并发零碎的整体架构角度来看，扩大的指标不仅仅是把服务设计成无状态就行了，因为当流量减少10倍，业务服务能够疾速扩容10倍，然而数据库可能就成为了新的瓶颈。

像MySQL这种有状态的存储服务通常是扩大的技术难点，如果架构上没提前做好布局（垂直和程度拆分），就会波及到大量数据的迁徙。

因而，高扩展性须要思考：服务集群、数据库、缓存和音讯队列等中间件、负载平衡、带宽、依赖的第三方等，当并发达到某一个量级后，上述每个因素都可能成为扩大的瓶颈点。

03 高并发的实际计划有哪些？

理解了高并发设计的3大指标后，再系统性总结下高并发的设计方案，会从以下两局部开展：先总结下通用的设计办法，而后再围绕高性能、高可用、高扩大别离给出具体的实际计划。

3.1 通用的设计办法

通用的设计办法次要是从「纵向」和「横向」两个维度登程，俗称高并发解决的两板斧：纵向扩大和横向扩大。

❇ 纵向扩大（scale-up）

它的指标是晋升单机的解决能力，计划又包含：

1、晋升单机的硬件性能：通过减少内存、CPU核数、存储容量、或者将磁盘升级成SSD等堆硬件的形式来晋升。

2、晋升单机的软件性能：应用缓存缩小IO次数，应用并发或者异步的形式减少吞吐量。

❇ 横向扩大（scale-out）

因为单机性能总会存在极限，所以最终还须要引入横向扩大，通过集群部署以进一步提高并发解决能力，又包含以下2个方向：

1、做好分层架构：这是横向扩大的提前，因为高并发零碎往往业务简单，通过分层解决能够简化简单问题，更容易做到横向扩大。

​

下面这种图是互联网最常见的分层架构，当然实在的高并发零碎架构会在此基础上进一步欠缺。比方会做动静拆散并引入CDN，反向代理层能够是LVS+Nginx，Web层能够是对立的API网关，业务服务层可进一步按垂直业务做微服务化，存储层能够是各种异构数据库。

2、各层进行程度扩大：无状态程度扩容，有状态做分片路由。业务集群通常能设计成无状态的，而数据库和缓存往往是有状态的，因而须要设计分区键做好存储分片，当然也能够通过主从同步、读写拆散的计划晋升读性能。

3.2 具体的实际计划

上面再联合我的集体教训，针对高性能、高可用、高扩大3个方面，总结下可落地的实际计划。

❇ 高性能的实际计划

1、集群部署，通过负载平衡加重单机压力。

2、多级缓存，包含静态数据应用CDN、本地缓存、分布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的解决。

3、分库分表和索引优化，以及借助搜索引擎解决简单查问问题。

4、思考NoSQL数据库的应用，比方HBase、TiDB等，然而团队必须相熟这些组件，且有较强的运维能力。

5、异步化，将主要流程通过多线程、MQ、甚至延时工作进行异步解决。

6、限流，须要先思考业务是否容许限流（比方秒杀场景是容许的），包含前端限流、Nginx接入层的限流、服务端的限流。

7、对流量进行削峰填谷，通过MQ承接流量。

8、并发解决，通过多线程将串行逻辑并行化。

9、预计算，比方抢红包场景，能够提前计算好红包金额缓存起来，发红包时间接应用即可。

10、缓存预热，通过异步工作提前预热数据到本地缓存或者分布式缓存中。

11、缩小IO次数，比方数据库和缓存的批量读写、RPC的批量接口反对、或者通过冗余数据的形式干掉RPC调用。

12、缩小IO时的数据包大小，包含采纳轻量级的通信协议、适合的数据结构、去掉接口中的多余字段、缩小缓存key的大小、压缩缓存value等。

13、程序逻辑优化，比方将大概率阻断执行流程的判断逻辑前置、For循环的计算逻辑优化，或者采纳更高效的算法。

14、各种池化技术的应用和池大小的设置，包含HTTP申请池、线程池（思考CPU密集型还是IO密集型设置外围参数）、数据库和Redis连接池等。

15、JVM优化，包含新生代和老年代的大小、GC算法的抉择等，尽可能减少GC频率和耗时。

16、锁抉择，读多写少的场景用乐观锁，或者思考通过分段锁的形式缩小锁抵触。

上述计划无外乎从计算和 IO 两个维度思考所有可能的优化点，须要有配套的监控零碎实时理解以后的性能体现，并撑持你进行性能瓶颈剖析，而后再遵循二八准则，抓主要矛盾进行优化。

❇ 高可用的实际计划

1、对等节点的故障转移，Nginx和服务治理框架均反对一个节点失败后拜访另一个节点。

2、非对等节点的故障转移，通过心跳检测并施行主备切换（比方redis的哨兵模式或者集群模式、MySQL的主从切换等）。

3、接口层面的超时设置、重试策略和幂等设计。

4、降级解决：保障外围服务，就义非核心服务，必要时进行熔断；或者外围链路出问题时，有备选链路。

5、限流解决：对超过零碎解决能力的申请间接回绝或者返回错误码。

6、MQ场景的音讯可靠性保障，包含producer端的重试机制、broker侧的长久化、consumer端的ack机制等。

7、灰度公布，能反对按机器维度进行小流量部署，察看系统日志和业务指标，等运行安稳后再推全量。

8、监控报警：全方位的监控体系，包含最根底的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。

9、灾备演练：相似以后的“混沌工程”，对系统进行一些破坏性伎俩，察看部分故障是否会引起可用性问题。

高可用的计划次要从冗余、取舍、零碎运维3个方向思考，同时须要有配套的值班机制和故障解决流程，当呈现线上问题时，可及时跟进解决。

❇ 高扩大的实际计划

1、正当的分层架构：比方下面谈到的互联网最常见的分层架构，另外还能进一步依照数据拜访层、业务逻辑层对微服务做更细粒度的分层（然而须要评估性能，会存在网络多一跳的状况）。

2、存储层的拆分：依照业务维度做垂直拆分、依照数据特色维度进一步做程度拆分（分库分表）。

3、业务层的拆分：最常见的是依照业务维度拆（比方电商场景的商品服务、订单服务等），也能够依照外围接口和非核心接口拆，还能够依照申请源拆（比方To C和To B，APP和H5）。

最初的话

高并发的确是一个简单且系统性的问题，因为篇幅无限，诸如分布式Trace、全链路压测、柔性事务都是要思考的技术点。另外，如果业务场景不同，高并发的落地计划也会存在差别，然而总体的设计思路和可借鉴的计划根本相似。

高并发设计同样要秉承架构设计的3个准则：简略、适合和演进。“过早的优化是万恶之源”，不能脱离业务的理论状况，更不要适度设计，适合的计划就是最完满的。

作为浏览福利，小编也整顿了高并发相干学习材料跟面试真题，当初分享给浏览到本篇文章的Java程序员敌人们，须要的可【点击此处】

高并发面试真题 

​

​ 

​ 

​

​

​ 

因为内容较多，小编就不全副展现了，作为浏览福利，小编把所有的高并发相干学习材料跟面试真题整顿成了PDF文档，当初分享给浏览到本篇文章的Java程序员敌人们，须要的可【点击此处】即可取得

​

喜欢 (0)赏

[搞代码]

分享 (0)