高并发方案最全详解(8大常见方案)

关注△mikechen△，十余年BAT架构经验倾囊相授！

大家好，我是mikechen睿哥。

高并发是大型架构的核心，下面我重点来详解常见8大高并发方案@mikechen

文章来源：mikechen.cc

分布式缓存

可以说，缓存是高并发的第一大利器。

缓存是将数据，存储在离用户更近或访问速度更快的介质上。

从而，以减少对后端数据库或服务的直接访问，从而提高响应速度并减轻后端负载。

比如：Redis 将所有数据存储在内存中，这使得它能够以纳秒级的速度进行读写操作，远超磁盘存储的数据库。

在高并发场景下，这意味着每个请求都能得到极快的响应，极大地提升了系统的吞吐量。

使用场景：用户信息、商品详情页、排行榜、配置数据…等

将访问频次高的读请求全部打在 Redis，减少数据库 QPS 压力 90%+。

负载均衡

负载均衡将大量并发请求均匀地分发到多台服务器上，避免单点过载，提高系统的整体吞吐量和可用性。

实现方式，主要就：硬件和软件。

硬件负载均衡器 (如F5, A10)： 性能高，功能丰富。

软件负载均衡器 (如Nginx, LVS, HAProxy)： 成本低，配置灵活。

微服务

在单体应用中，当某个模块出现性能瓶颈时，你通常只能将整个应用进行扩容。

而在微服务架构下，每个服务都可以独立部署在不同的服务器或容器上。

当某个服务，例如：处理商品详情的服务，在高并发下成为瓶颈时。

你可以只针对这个服务进行横向扩展，增加其运行实例的数量，而不需要影响其他服务。

并且，在单体应用中，通常只能使用一套技术栈。

但微服务架构允许你为不同的服务选择最适合它们的技术。

例如，处理实时数据流的服务可以使用 Kafka 和 Go 语言，而数据查询频繁的服务可以使用 Java 和更优化的数据库方案。

微服务架构虽然带来了诸多优势，但也要注意其复杂性增加、运维挑战提升等问题，需要借助如服务治理、分布式追踪、统一日志等配套工具来解决。

异步削峰

流量削峰是应对高并发的核心策略之一，其目标是将突发的高峰流量转化为相对平稳、可控的流量，从而避免系统在瞬间压力下崩溃。

这就像一个水库，在洪水来临时蓄水，然后以稳定的流速放水，保护下游地区。

将请求写入消息队列，由消费者异步消费，削峰填谷。

当瞬间请求量远超系统处理能力时，异步队列能像一个“蓄水池”，把多余的请求暂时储存起来，让系统平稳地处理。

这样能有效削平请求高峰，填补低谷，让系统负载更均衡。

CDN服务

将热点资源、页面缓存到CDN边缘节点，或将动态页预渲染成静态页面。

比如：阿里云 CDN / Cloudflare / Nginx + 模板引擎

适用场景：新闻首页、商品详情页、图片视频类静态资源…等等。

优点：

极大减轻源站压力；

靠近用户访问速度快；

缺点：

不适合频繁更新的数据。

服务限流

除此之外，还会涉及到：限流、熔断…等策略。

比如：限流，是防止系统被击穿的“保险丝”，当流量超出系统容量时，直接拒绝或延缓部分请求。

设定一个系统能够承受的最大并发数或单位时间内的请求数。

当请求量超过这个阈值时，超出的部分请求会被拒绝、排队或降级处理。

根本上防止过量的请求涌入系统，避免系统资源耗尽导致宕机。

可以对不同级别的用户或不同类型的请求设置不同的限流策略，保证核心业务的可用性。

服务降级

当系统压力过大或部分功能出现故障时，主动关闭一些非核心或次要功能，保障核心功能的可用性。

例如，双11时关闭评论功能，只保留购买。

服务熔断

类似于电路中的保险丝，当某个服务调用失败率达到阈值时。

熔断器会打开，阻止后续请求继续发送到故障服务，避免雪崩效应。

经过一段时间后，熔断器会进入半开状态，尝试发送少量请求，如果成功则闭合。

这些方案并非孤立存在，而是相互补充，共同构成了一个健壮的高并发系统架构。

以上

文章来源：mikechen.cc