高并发，简直是每个程序员都想领有的教训。起因很简略：随着流量变大，会遇到各种各样的技术问题，比方接口响应超时、CPU load 升高、GC 频繁、死锁、大数据量存储等等，这些问题能推动咱们在技术深度上一直精进。在面试中，高并发也是咱们不可避免问到的一个点，然而高并发你真的了解透彻了吗？明天小编就跟大家来说一说高并发以及高并发大厂面试真题解析！
作为浏览福利，小编也整顿了高并发相干学习材料跟面试真题，当初分享给浏览到本篇文章的 Java 程序员敌人们，须要的可【点击此处】
在过往的面试中，如果候选人做过高并发的我的项目，我通常会让对方谈谈对于高并发的了解，然而能系统性地答复好此问题的人并不多，大略分成这样几类：
1、对数据化的指标没有概念 ：不分明抉择什么样的指标来掂量高并发零碎？分不清并发量和 QPS，甚至不晓得本人零碎的总用户量、沉闷用户量，平峰和顶峰时的 QPS 和 TPS 等要害数据。
2、设计了一些计划，然而细节把握不透彻： 讲不出该计划要关注的技术点和可能带来的副作用。比方读性能有瓶颈会引入缓存，然而漠视了缓存命中率、热点 key、数据一致性等问题。
3、了解全面，把高并发设计等同于性能优化： 大谈并发编程、多级缓存、异步化、程度扩容，却漠视高可用设计、服务治理和运维保障。
4、把握大计划，却漠视最根本的货色： 能讲清楚垂直分层、程度分区、缓存等大思路，却没意识去剖析数据结构是否正当，算法是否高效，没想过从最基本的 IO 和计算两个维度去做细节优化。
这篇文章，我想联合本人的高并发我的项目教训，系统性地总结下高并发须要把握的常识和实际思路，心愿对你有所帮忙。内容分成以下 3 个局部：
- 如何了解高并发？
- 高并发零碎设计的指标是什么？
- 高并发的实际计划有哪些？
01 如何了解高并发？
高并发意味着大流量，须要使用技术手段抵制流量的冲击，这些伎俩好比操作流量，能让流量更安稳地被零碎所解决，带给用户更好的体验。
咱们常见的高并发场景有：淘宝的双 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 程序员敌人们，须要的可【点击此处】即可取得