你真的搞懂高并发了吗？万字长文让你彻底理解透彻高并发！

高并发&＃xff0c;几乎是每个程序员都想拥有的经验。原因很简单&＃xff1a;随着流量变大&＃xff0c;会遇到各种各样的技术问题&＃xff0c;比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等&＃xff0c;这些问题能推动我们在技术深度上不断精进。在面试中&＃xff0c;高并发也是我们不可避免问到的一个点&＃xff0c;但是高并发你真的理解透彻了吗&＃xff1f;今天小编就跟大家来说一说高并发以及高并发大厂面试真题解析&＃xff01;

作为阅读福利&＃xff0c;小编也整理了高并发相关学习资料跟面试真题&＃xff0c;现在分享给阅读到本篇文章的Java程序员朋友们&＃xff0c;需要的可【点击此处】

在过往的面试中&＃xff0c;如果候选人做过高并发的项目&＃xff0c;我通常会让对方谈谈对于高并发的理解&＃xff0c;但是能系统性地回答好此问题的人并不多&＃xff0c;大概分成这样几类&＃xff1a;

1、对数据化的指标没有概念&＃xff1a;不清楚选择什么样的指标来衡量高并发系统&＃xff1f;分不清并发量和QPS&＃xff0c;甚至不知道自己系统的总用户量、活跃用户量&＃xff0c;平峰和高峰时的QPS和TPS等关键数据。

2、设计了一些方案&＃xff0c;但是细节掌握不透彻&＃xff1a;讲不出该方案要关注的技术点和可能带来的副作用。比如读性能有瓶颈会引入缓存&＃xff0c;但是忽视了缓存命中率、热点key、数据一致性等问题。

3、理解片面&＃xff0c;把高并发设计等同于性能优化&＃xff1a;大谈并发编程、多级缓存、异步化、水平扩容&＃xff0c;却忽视高可用设计、服务治理和运维保障。

4、掌握大方案&＃xff0c;却忽视最基本的东西&＃xff1a;能讲清楚垂直分层、水平分区、缓存等大思路&＃xff0c;却没意识去分析数据结构是否合理&＃xff0c;算法是否高效&＃xff0c;没想过从最根本的IO和计算两个维度去做细节优化。

这篇文章&＃xff0c;我想结合自己的高并发项目经验&＃xff0c;系统性地总结下高并发需要掌握的知识和实践思路&＃xff0c;希望对你有所帮助。内容分成以下3个部分&＃xff1a;

• 如何理解高并发&＃xff1f;
• 高并发系统设计的目标是什么&＃xff1f;
• 高并发的实践方案有哪些&＃xff1f;

高并发意味着大流量&＃xff0c;需要运用技术手段抵抗流量的冲击&＃xff0c;这些手段好比操作流量&＃xff0c;能让流量更平稳地被系统所处理&＃xff0c;带给用户更好的体验。

我们常见的高并发场景有&＃xff1a;淘宝的双11、春运时的抢票、微博大V的热点新闻等。除了这些典型事情&＃xff0c;每秒几十万请求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等&＃xff0c;都可以归为高并发。

很显然&＃xff0c;上面谈到的高并发场景&＃xff0c;并发量各不相同&＃xff0c;那到底多大并发才算高并发呢&＃xff1f;

1、不能只看数字&＃xff0c;要看具体的业务场景。不能说10W QPS的秒杀是高并发&＃xff0c;而1W QPS的信息流就不是高并发。信息流场景涉及复杂的推荐模型和各种人工策略&＃xff0c;它的业务逻辑可能比秒杀场景复杂10倍不止。因此&＃xff0c;不在同一个维度&＃xff0c;没有任何比较意义。

2、业务都是从0到1做起来的&＃xff0c;并发量和QPS只是参考指标&＃xff0c;最重要的是&＃xff1a;在业务量逐渐变成原来的10倍、100倍的过程中&＃xff0c;你是否用到了高并发的处理方法去演进你的系统&＃xff0c;从架构设计、编码实现、甚至产品方案等维度去预防和解决高并发引起的问题&＃xff1f;而不是一味的升级硬件、加机器做水平扩展。

此外&＃xff0c;各个高并发场景的业务特点完全不同&＃xff1a;有读多写少的信息流场景、有读多写多的交易场景&＃xff0c;那是否有通用的技术方案解决不同场景的高并发问题呢&＃xff1f;

我觉得大的思路可以借鉴&＃xff0c;别人的方案也可以参考&＃xff0c;但是真正落地过程中&＃xff0c;细节上还会有无数的坑。另外&＃xff0c;由于软硬件环境、技术栈、以及产品逻辑都没法做到完全一致&＃xff0c;这些都会导致同样的业务场景&＃xff0c;就算用相同的技术方案也会面临不同的问题&＃xff0c;这些坑还得一个个趟。

因此&＃xff0c;这篇文章我会将重点放在基础知识、通用思路、和我曾经实践过的有效经验上&＃xff0c;希望让你对高并发有更深的理解。

先搞清楚高并发系统设计的目标&＃xff0c;在此基础上再讨论设计方案和实践经验才有意义和针对性。

2.1 宏观目标

高并发绝不意味着只追求高性能&＃xff0c;这是很多人片面的理解。从宏观角度看&＃xff0c;高并发系统设计的目标有三个&＃xff1a;高性能、高可用&＃xff0c;以及高可扩展。

1、高性能&＃xff1a;性能体现了系统的并行处理能力&＃xff0c;在有限的硬件投入下&＃xff0c;提高性能意味着节省成本。同时&＃xff0c;性能也反映了用户体验&＃xff0c;响应时间分别是100毫秒和1秒&＃xff0c;给用户的感受是完全不同的。

2、高可用&＃xff1a;表示系统可以正常服务的时间。一个全年不停机、无故障&＃xff1b;另一个隔三差五出线上事故、宕机&＃xff0c;用户肯定选择前者。另外&＃xff0c;如果系统只能做到90%可用&＃xff0c;也会大大拖累业务。

3、高扩展&＃xff1a;表示系统的扩展能力&＃xff0c;流量高峰时能否在短时间内完成扩容&＃xff0c;更平稳地承接峰值流量&＃xff0c;比如双11活动、明星离婚等热点事件。

这3个目标是需要通盘考虑的&＃xff0c;因为它们互相关联、甚至也会相互影响。

比如说&＃xff1a;考虑系统的扩展能力&＃xff0c;你会将服务设计成无状态的&＃xff0c;这种集群设计保证了高扩展性&＃xff0c;其实也间接提升了系统的性能和可用性。

再比如说&＃xff1a;为了保证可用性&＃xff0c;通常会对服务接口进行超时设置&＃xff0c;以防大量线程阻塞在慢请求上造成系统雪崩&＃xff0c;那超时时间设置成多少合理呢&＃xff1f;一般&＃xff0c;我们会参考依赖服务的性能表现进行设置。

2.2 微观目标

再从微观角度来看&＃xff0c;高性能、高可用和高扩展又有哪些具体的指标来衡量&＃xff1f;为什么会选择这些指标呢&＃xff1f;

❇ 性能指标

通过性能指标可以度量目前存在的性能问题&＃xff0c;同时作为性能优化的评估依据。一般来说&＃xff0c;会采用一段时间内的接口响应时间作为指标。

1、平均响应时间&＃xff1a;最常用&＃xff0c;但是缺陷很明显&＃xff0c;对于慢请求不敏感。比如1万次请求&＃xff0c;其中9900次是1ms&＃xff0c;100次是100ms&＃xff0c;则平均响应时间为1.99ms&＃xff0c;虽然平均耗时仅增加了0.99ms&＃xff0c;但是1%请求的响应时间已经增加了100倍。

2、TP90、TP99等分位值&＃xff1a;将响应时间按照从小到大排序&＃xff0c;TP90表示排在第90分位的响应时间&＃xff0c; 分位值越大&＃xff0c;对慢请求越敏感。

3、吞吐量&＃xff1a;和响应时间呈反比&＃xff0c;比如响应时间是1ms&＃xff0c;则吞吐量为每秒1000次。

通常&＃xff0c;设定性能目标时会兼顾吞吐量和响应时间&＃xff0c;比如这样表述&＃xff1a;在每秒1万次请求下&＃xff0c;AVG控制在50ms以下&＃xff0c;TP99控制在100ms以下。对于高并发系统&＃xff0c;AVG和TP分位值必须同时要考虑。

另外&＃xff0c;从用户体验角度来看&＃xff0c;200毫秒被认为是第一个分界点&＃xff0c;用户感觉不到延迟&＃xff0c;1秒是第二个分界点&＃xff0c;用户能感受到延迟&＃xff0c;但是可以接受。

因此&＃xff0c;对于一个健康的高并发系统&＃xff0c;TP99应该控制在200毫秒以内&＃xff0c;TP999或者TP9999应该控制在1秒以内。

❇ 可用性指标

高可用性是指系统具有较高的无故障运行能力&＃xff0c;可用性 &＃61; 平均故障时间 / 系统总运行时间&＃xff0c;一般使用几个9来描述系统的可用性。

对于高并发系统来说&＃xff0c;最基本的要求是&＃xff1a;保证3个9或者4个9。原因很简单&＃xff0c;如果你只能做到2个9&＃xff0c;意味着有1%的故障时间&＃xff0c;像一些大公司每年动辄千亿以上的GMV或者收入&＃xff0c;1%就是10亿级别的业务影响。

❇ 可扩展性指标

面对突发流量&＃xff0c;不可能临时改造架构&＃xff0c;最快的方式就是增加机器来线性提高系统的处理能力。

对于业务集群或者基础组件来说&＃xff0c;扩展性 &＃61; 性能提升比例 / 机器增加比例&＃xff0c;理想的扩展能力是&＃xff1a;资源增加几倍&＃xff0c;性能提升几倍。通常来说&＃xff0c;扩展能力要维持在70%以上。

但是从高并发系统的整体架构角度来看&＃xff0c;扩展的目标不仅仅是把服务设计成无状态就行了&＃xff0c;因为当流量增加10倍&＃xff0c;业务服务可以快速扩容10倍&＃xff0c;但是数据库可能就成为了新的瓶颈。

像MySQL这种有状态的存储服务通常是扩展的技术难点&＃xff0c;如果架构上没提前做好规划&＃xff08;垂直和水平拆分&＃xff09;&＃xff0c;就会涉及到大量数据的迁移。

因此&＃xff0c;高扩展性需要考虑&＃xff1a;服务集群、数据库、缓存和消息队列等中间件、负载均衡、带宽、依赖的第三方等&＃xff0c;当并发达到某一个量级后&＃xff0c;上述每个因素都可能成为扩展的瓶颈点。

了解了高并发设计的3大目标后&＃xff0c;再系统性总结下高并发的设计方案&＃xff0c;会从以下两部分展开&＃xff1a;先总结下通用的设计方法&＃xff0c;然后再围绕高性能、高可用、高扩展分别给出具体的实践方案。

3.1 通用的设计方法

通用的设计方法主要是从「纵向」和「横向」两个维度出发&＃xff0c;俗称高并发处理的两板斧&＃xff1a;纵向扩展和横向扩展。

❇ 纵向扩展&＃xff08;scale-up&＃xff09;

它的目标是提升单机的处理能力&＃xff0c;方案又包括&＃xff1a;

1、提升单机的硬件性能&＃xff1a;通过增加内存、CPU核数、存储容量、或者将磁盘升级成SSD等堆硬件的方式来提升。

2、提升单机的软件性能&＃xff1a;使用缓存减少IO次数&＃xff0c;使用并发或者异步的方式增加吞吐量。

❇ 横向扩展&＃xff08;scale-out&＃xff09;

因为单机性能总会存在极限&＃xff0c;所以最终还需要引入横向扩展&＃xff0c;通过集群部署以进一步提高并发处理能力&＃xff0c;又包括以下2个方向&＃xff1a;

1、做好分层架构&＃xff1a;这是横向扩展的提前&＃xff0c;因为高并发系统往往业务复杂&＃xff0c;通过分层处理可以简化复杂问题&＃xff0c;更容易做到横向扩展。

上面这种图是互联网最常见的分层架构&＃xff0c;当然真实的高并发系统架构会在此基础上进一步完善。比如会做动静分离并引入CDN&＃xff0c;反向代理层可以是LVS&＃43;Nginx&＃xff0c;Web层可以是统一的API网关&＃xff0c;业务服务层可进一步按垂直业务做微服务化&＃xff0c;存储层可以是各种异构数据库。

2、各层进行水平扩展&＃xff1a;无状态水平扩容&＃xff0c;有状态做分片路由。业务集群通常能设计成无状态的&＃xff0c;而数据库和缓存往往是有状态的&＃xff0c;因此需要设计分区键做好存储分片&＃xff0c;当然也可以通过主从同步、读写分离的方案提升读性能。

3.2 具体的实践方案

下面再结合我的个人经验&＃xff0c;针对高性能、高可用、高扩展3个方面&＃xff0c;总结下可落地的实践方案。

❇ 高性能的实践方案

1、集群部署&＃xff0c;通过负载均衡减轻单机压力。

2、多级缓存&＃xff0c;包括静态数据使用CDN、本地缓存、分布式缓存等&＃xff0c;以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。

3、分库分表和索引优化&＃xff0c;以及借助搜索引擎解决复杂查询问题。

4、考虑NoSQL数据库的使用&＃xff0c;比如HBase、TiDB等&＃xff0c;但是团队必须熟悉这些组件&＃xff0c;且有较强的运维能力。

5、异步化&＃xff0c;将次要流程通过多线程、MQ、甚至延时任务进行异步处理。

6、限流&＃xff0c;需要先考虑业务是否允许限流&＃xff08;比如秒杀场景是允许的&＃xff09;&＃xff0c;包括前端限流、Nginx接入层的限流、服务端的限流。

7、对流量进行削峰填谷&＃xff0c;通过MQ承接流量。

8、并发处理&＃xff0c;通过多线程将串行逻辑并行化。

9、预计算&＃xff0c;比如抢红包场景&＃xff0c;可以提前计算好红包金额缓存起来&＃xff0c;发红包时直接使用即可。

10、缓存预热&＃xff0c;通过异步任务提前预热数据到本地缓存或者分布式缓存中。

11、减少IO次数&＃xff0c;比如数据库和缓存的批量读写、RPC的批量接口支持、或者通过冗余数据的方式干掉RPC调用。

12、减少IO时的数据包大小&＃xff0c;包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存key的大小、压缩缓存value等。

13、程序逻辑优化&＃xff0c;比如将大概率阻断执行流程的判断逻辑前置、For循环的计算逻辑优化&＃xff0c;或者采用更高效的算法。

14、各种池化技术的使用和池大小的设置&＃xff0c;包括HTTP请求池、线程池&＃xff08;考虑CPU密集型还是IO密集型设置核心参数&＃xff09;、数据库和Redis连接池等。

15、JVM优化&＃xff0c;包括新生代和老年代的大小、GC算法的选择等&＃xff0c;尽可能减少GC频率和耗时。

16、锁选择&＃xff0c;读多写少的场景用乐观锁&＃xff0c;或者考虑通过分段锁的方式减少锁冲突。

上述方案无外乎从计算和 IO 两个维度考虑所有可能的优化点&＃xff0c;需要有配套的监控系统实时了解当前的性能表现&＃xff0c;并支撑你进行性能瓶颈分析&＃xff0c;然后再遵循二八原则&＃xff0c;抓主要矛盾进行优化。

❇ 高可用的实践方案

1、对等节点的故障转移&＃xff0c;Nginx和服务治理框架均支持一个节点失败后访问另一个节点。

2、非对等节点的故障转移&＃xff0c;通过心跳检测并实施主备切换&＃xff08;比如redis的哨兵模式或者集群模式、MySQL的主从切换等&＃xff09;。

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

4、降级处理&＃xff1a;保证核心服务&＃xff0c;牺牲非核心服务&＃xff0c;必要时进行熔断&＃xff1b;或者核心链路出问题时&＃xff0c;有备选链路。

5、限流处理&＃xff1a;对超过系统处理能力的请求直接拒绝或者返回错误码。

6、MQ场景的消息可靠性保证&＃xff0c;包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。

7、灰度发布&＃xff0c;能支持按机器维度进行小流量部署&＃xff0c;观察系统日志和业务指标&＃xff0c;等运行平稳后再推全量。

8、监控报警&＃xff1a;全方位的监控体系&＃xff0c;包括最基础的CPU、内存、磁盘、网络的监控&＃xff0c;以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。

9、灾备演练&＃xff1a;类似当前的“混沌工程”&＃xff0c;对系统进行一些破坏性手段&＃xff0c;观察局部故障是否会引起可用性问题。

高可用的方案主要从冗余、取舍、系统运维3个方向考虑&＃xff0c;同时需要有配套的值班机制和故障处理流程&＃xff0c;当出现线上问题时&＃xff0c;可及时跟进处理。

❇ 高扩展的实践方案

1、合理的分层架构&＃xff1a;比如上面谈到的互联网最常见的分层架构&＃xff0c;另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层&＃xff08;但是需要评估性能&＃xff0c;会存在网络多一跳的情况&＃xff09;。

2、存储层的拆分&＃xff1a;按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分&＃xff08;分库分表&＃xff09;。

3、业务层的拆分&＃xff1a;最常见的是按照业务维度拆&＃xff08;比如电商场景的商品服务、订单服务等&＃xff09;&＃xff0c;也可以按照核心接口和非核心接口拆&＃xff0c;还可以按照请求源拆&＃xff08;比如To C和To B&＃xff0c;APP和H5&＃xff09;。

高并发确实是一个复杂且系统性的问题&＃xff0c;由于篇幅有限&＃xff0c;诸如分布式Trace、全链路压测、柔性事务都是要考虑的技术点。另外&＃xff0c;如果业务场景不同&＃xff0c;高并发的落地方案也会存在差异&＃xff0c;但是总体的设计思路和可借鉴的方案基本类似。

高并发设计同样要秉承架构设计的3个原则&＃xff1a;简单、合适和演进。“过早的优化是万恶之源”&＃xff0c;不能脱离业务的实际情况&＃xff0c;更不要过度设计&＃xff0c;合适的方案就是最完美的。

作为阅读福利&＃xff0c;小编也整理了高并发相关学习资料跟面试真题&＃xff0c;现在分享给阅读到本篇文章的Java程序员朋友们&＃xff0c;需要的可【点击此处】

由于内容较多&＃xff0c;小编就不全部展示了&＃xff0c;作为阅读福利&＃xff0c;小编把所有的高并发相关学习资料跟面试真题整理成了PDF文档&＃xff0c;现在分享给阅读到本篇文章的Java程序员朋友们&＃xff0c;需要的可【点击此处】即可获得