互联网行业迅速发展，用户量剧增，系统面临巨大的并发请求压力。

软件系统有三个追求：高性能、高并发、高可用，俗称三高。三者既有区别也有联系，门门道道很多，全面讨论需要三天三夜，本篇讨论高并发。

性能下降、资源竞争和稳定性问题等。

高并发是指系统或应用程序在同一时间段内接收到大量并发请求的能力。具体来说，高并发环境下系统需要能够同时处理大量的请求，而不会出现性能问题或响应延迟。

• 大量请求：高并发场景下，系统需要同时处理大量的请求，这些请求可能来自于不同的用户或客户端。

• 同时访问：这些请求几乎同时到达系统，需要在短时间内进行处理和响应。

• 资源竞争：由于大量请求同时到达，系统的资源（如CPU、内存、网络带宽等）可能会面临竞争和争夺。

• 响应时间要求高：高并发场景通常对系统的响应速度有较高的要求，用户期望能够快速获取响应结果。

高并发场景广泛应用于热门网站、电商平台、社交媒体等互联网应用中。例如，在电商平台上有大量用户同时浏览、搜索商品，提交订单等操作；社交媒体平台上有大量用户同时发布、点赞、评论等操作。这些场景需要系统能够同时处理大量请求，并保证系统的性能、可用性和用户体验。

在网站或APP的开发中，缓存机制是一个不可或缺的环节，可以提高网站或APP的访问速度，降低数据库压力。在高并发环境下，缓存机制的作用更加明显，不仅可以有效减轻数据库的负载，还可以提高系统的稳定性和性能，从而给用户带来更好的体验。

缓存的工作原理是先从缓存中获取数据，如果有数据则直接返回给用户，如果没有数据则从慢速设备上读取实际数据并且将数据放入缓存。

1）浏览器缓存

简介：浏览器缓存是指将网页中的资源（如HTML、CSS、JavaScript、图像等）存储在用户的浏览器内部，以便在后续请求同一资源时可以直接从本地缓存中获取，而无需再次从服务器下载。

适用场景：浏览器缓存适用于那些静态内容变化较少的网页和静态资源，可以显著提升网站性能和用户体验，并减少服务器的负载。

常见用法：

使用浏览器缓存可以通过设置响应头中的Expires和Cache-Control字段来控制缓存的行为。

注意事项

浏览器缓存存储实时性不敏感的数据，如商品框架、商家评分、评价和广告词。它有过期时间，并通过响应头进行控制。实时性要求高的数据不适合使用浏览器缓存。

2）客户端缓存

简介：客户端缓存是将数据存储在浏览器中，以提高访问速度和减少服务器请求。

适用场景：在大促期间，为了防止服务端承受瞬间的高流量压力，可以提前将一些素材（如js/css/image等）下发到客户端进行缓存，避免在大促期间再次请求这些素材。此外，还可以将一些兜底数据或样式文件存放在客户端缓存中，以确保在服务端异常或网络异常的情况下，保持app的正常运行。

3）CDN缓存

简介：

CDN（Content Delivery Network）是建立在承载网之上的分布式网络，由分布在不同区域的边缘节点服务器组成。

CDN缓存通常用于存放静态页面数据、活动页面、图片等数据。它有两种缓存机制：推送机制（将数据主动推送到CDN节点）和拉取机制（首次访问时从源服务器获取数据并存储在CDN节点）。

适用场景：CDN缓存可以提高网站访问速度，适用于网站访问量大、访问速度慢、数据变化不频繁的场景。

常用工具以及用法

常见的CDN缓存工具包括Cloudflare、Akamai、Fastly和AWS CloudFront等。这些工具提供了全球分布的CDN网络，以加速内容传输和提升性能。它们提供了控制台和API，用于配置CDN缓存规则、管理缓存内容、刷新和更新缓存等。

4）反向代理缓存

简介：反向代理缓存是指在反向代理服务器上对请求的响应进行缓存，以提高服务的性能和用户体验。它将经常请求的静态内容缓存在代理服务器上，当有用户请求同样的内容时，代理服务器会直接返回缓存的响应，而无需再次向源服务器请求。

适用场景：适用于访问外部服务速度比较慢，但是数据变化不频繁的场景。

常用工具以及用法

5）本地缓存

简介：本地缓存是将数据或资源存储在客户端的存储介质中，如硬盘、内存或数据库。它可以是临时的，只在应用程序运行期间有效，或者可以是持久的，即在不同的应用程序会话中保持有效。

适用场景：本地缓存适用于频繁访问数据、离线访问、减少带宽消耗和提升用户体验的场景。

常用工具以及用法：一般分为磁盘缓存、CPU缓存、应用缓存。

6）分布式缓存

简介：分布式缓存是将缓存数据分散存储在多台服务器上的缓存解决方案。

适用场景：高并发读取、数据共享和协同处理、提供弹性和可扩展性、降低后端请求次数等场景。

常用工具以及用法

1）缓存穿透

关键词：强调缓存和数据库都没有数据+并发访问

缓存穿透是指数据库和缓存都没有的数据，每次都要经过缓存去访问数据库，大量的请求有可能导致DB宕机。

应对策略

2）缓存击穿

关键词：强调单个热点Key过期+并发访问

缓存击穿是指数据库有，缓存没有的热点数据，大量请求访问这个缓存不存在的数据，最后请求打到DB可能导致DB宕机。

应对策略

3）缓存雪崩

关键词：强调批量Key过期+并发访问

缓存雪崩指的是在同一时段大量的缓存键（key）同时失效，导致大量请求打到数据库，最后请求打到DB可能导致DB宕机。

应对策略

4）缓存一致性

缓存一致性指的是缓存与DB之间的数据一致性，我们需要通过各种手段来防止缓存与DB不一致，我们要保证缓存与DB的数据一致或者数据最终一致。

应对策略

针对缓存一致性问题，可以从不同的层次来应对：

监控和报警：

综合使用以上层次的策略，可以有效地应对缓存一致性问题，保证数据的一致性和系统的稳定性。不同层次的策略可以相互配合，形成一个完善的缓存一致性解决方案。

5）其他

缓存的好处我们非常受益，用户的每一次请求都伴随着无数缓存的诞生，但是缓存同时也给我们带来了不小的挑战，比如在上面提到的一些疑难课题：缓存穿透、缓存击穿、缓存雪崩和缓存一致性。

除此之外，我们还会涉及到其他的一些缓存难题，如：缓存倾斜、缓存阻塞、缓存慢查询、缓存主从一致性问题、缓存高可用、缓存故障发现与故障恢复、集群扩容收缩、大Key热Key……

6）小结

以上是对浏览器缓存、客户端缓存、CDN缓存、反向代理缓存、本地缓存和分布式缓存的横向对比，包括介绍、解决方案/工具、优点和缺点以及适用场景的详细信息。根据具体需求和系统架构，选择适合的缓存类型和方案，以提高系统性能、减轻服务器负载、改善用户体验和保证数据一致性。

再强大的系统，也怕流量短事件内集中爆发，就像银行怕挤兑一样，所以，高并发另一个必不可少的模块就是限流。

限流是一种通过控制请求的速率或数量来保护系统免受过载的技术。流控的精髓是限制单位时间内的请求量，最大程度保障系统的可靠性及可用性。

限流是在高并发环境下，为了保护系统的稳定性和可用性而引入的一种策略。通过限制并发请求的数量或频率，可以防止系统被过多的请求压垮或耗尽资源。

常见的流控算法包括：固定窗口、滑动窗口、漏桶、令牌桶、滑动日志等算法。

1）固定窗口算法（计数器）

简介：固定窗口限流算法（Fixed Window Rate Limiting Algorithm）是一种最简单的限流算法，其原理是在固定时间窗口(单位时间)内限制请求的数量。

原理：

固定窗口是最简单的流控算法。即，给定时间窗口，维护一个计数器用于统计访问次数，并实现以下规则：

适用场景：

实现方式

public class FixedWindowRateLimiter {    private static int counter = 0;  // 统计请求数    private static long lastAcquireTime = 0L;    private static final long windowUnit = 1000L; // 假设固定时间窗口是1000ms    private static final int threshold = 10; // 窗口阀值是10
    public synchronized boolean tryAcquire() {        long currentTime = System.currentTimeMillis();  // 获取系统当前时间        if (currentTime - lastAcquireTime > windowUnit) {  // 检查是否在时间窗口内            counter = 0;  // 计数器清零            lastAcquireTime = currentTime;  // 开启新的时间窗口        }        if (counter < threshold) {  // 小于阀值            counter++;  // 计数器加1            return true;  // 获取请求成功        }        return false;  // 超过阀值，无法获取请求    }}

代码说明：

使用了一个静态的counter变量来记录请求数量，lastAcquireTime变量记录上一次获取请求的时间戳。windowUnit表示固定时间窗口的长度，threshold则表示在时间窗口内的请求数阀值。

tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

优劣分析

优点：

缺点：

比如：假设限流阀值为5个请求，单位时间窗口是1s，如果我们在单位时间内的前0.8-1s和1-1.2s，分别并发5个请求。虽然都没有超过阀值，但是如果算0.8-1.2s内的，则并发数高达10，已经超过单位时间1s不超过5阀值的定义了。

简介：

为了解决临界突变问题，可以引入滑动窗口。即：把大的时间窗口拆分成若干粒度更细的子窗口，每个子窗口独立统计，按子窗口时间滑动，统一限流。

当滑动窗口的格子周期划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

原理：

将单位时间周期分为n个小周期，分别记录每个小周期内接口的访问次数，并且根据时间滑动删除过期的小周期。它可以解决固定窗口临界值的问题。

假设单位时间还是1s，滑动窗口算法把它划分为5个小周期，也就是滑动窗口（单位时间）被划分为5个小格子。每格表示0.2s。每过0.2s，时间窗口就会往右滑动一格。然后呢，每个小周期，都有自己独立的计数器，如果请求是0.83s到达的，0.8~1.0s对应的计数器就会加1。

假设我们1s内的限流阀值还是5个请求，0.8~1.0s内（比如0.9s的时候）来了5个请求，落在黄色格子里。

时间过了1.0s这个点之后，又来5个请求，落在紫色格子里。如果是固定窗口算法，是不会被限流的，但是滑动窗口的话，每过一个小周期，它会右移一个小格。过了1.0s这个点后，会右移一小格，当前的单位时间段是0.2~1.2s，这个区域的请求已经超过限定的5了，已触发限流啦，实际上，紫色格子的请求都被拒绝。

实现方式

import java.util.LinkedList;import java.util.Queue;
public class SlidingWindowRateLimiter {    private Queue<Long> timestamps; // 存储请求的时间戳队列    private int windowSize; // 窗口大小，即时间窗口内允许的请求数量    private long windowDuration; // 窗口持续时间，单位：毫秒    public SlidingWindowRateLimiter(int windowSize, long windowDuration) {        this.windowSize = windowSize;        this.windowDuration = windowDuration;        this.timestamps = new LinkedList<>();    }
    public synchronized boolean tryAcquire() {        long currentTime = System.currentTimeMillis(); // 获取当前时间戳        // 删除超过窗口持续时间的时间戳        while (!timestamps.isEmpty() && currentTime - timestamps.peek() > windowDuration) {            timestamps.poll();        }
        if (timestamps.size() < windowSize) { // 判断当前窗口内请求数是否小于窗口大小            timestamps.offer(currentTime); // 将当前时间戳加入队列            return true; // 获取请求成功        }
        return false; // 超过窗口大小，无法获取请求    }}

代码解读

在以上代码中，使用了一个Queue（队列）来存储请求的时间戳。构造函数中传入窗口大小 windowSize 和窗口持续时间 windowDuration。

tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

使用这个滑动窗口限流算法，可以限制在一定时间窗口内的请求频率，超过窗口大小的请求会被限制。您可以根据实际需求和业务场景进行调整和使用。

适用场景：同固定窗口的场景，且对流量限制要求较高的场景，需要更好地应对突发流量。

优劣分析

优势：

劣势：

• 突发流量无法处理（无法应对短时间内的大量请求，但是一旦到达限流后，请求都会直接暴力被拒绝。这样我们会损失一部分请求，这其实对于产品来说，并不太友好），需要合理调整时间窗口大小。

简介：基于（出口）流速来做流控。在网络通信中常用于流量整形，可以很好地解决平滑度问题。

特点：

原理

代码实现

public class LeakyBucketRateLimiter {    private long capacity; // 漏桶容量，即最大允许的请求数量    private long rate; // 漏水速率，即每秒允许通过的请求数量    private long water; // 漏桶当前水量    private long lastTime; // 上一次请求通过的时间戳
    public LeakyBucketRateLimiter(long capacity, long rate) {        this.capacity = capacity;        this.rate = rate;        this.water = 0;        this.lastTime = System.currentTimeMillis();    }
    public synchronized boolean tryAcquire() {        long now = System.currentTimeMillis();        long elapsedTime = now - lastTime;
        // 计算漏桶中的水量        water = Math.max(0, water - elapsedTime * rate / 1000);
        if (water < capacity) { // 判断漏桶中的水量是否小于容量            water++; // 漏桶中的水量加1            lastTime = now; // 更新上一次请求通过的时间戳            return true; // 获取请求成功        }
        return false; // 漏桶已满，无法获取请求    }}

代码解读

在以上代码中，capacity表示漏桶的容量，即最大允许的请求数量；rate表示漏水速率，即每秒允许通过的请求数量。water表示漏桶中当前的水量，lastTime表示上一次请求通过的时间戳。

tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

适用场景

一般用于保护第三方的系统，比如自身的系统需要调用第三方的接口，为了保护第三方的系统不被自身的调用打垮，便可以通过漏斗算法进行限流，保证自身的流量平稳的打到第三方的接口上。

优劣分析

优势：

劣势：

简介：基于（入口）流速来做流控的一种限流算法。

原理：该算法维护一个固定容量的令牌桶，每秒钟会向令牌桶中放入一定数量的令牌。当有请求到来时，如果令牌桶中有足够的令牌，则请求被允许通过并从令牌桶中消耗一个令牌，否则请求被拒绝。

实现方式

import java.util.concurrent.ScheduledExecutorService;import java.util.concurrent.ScheduledThreadPoolExecutor;import java.util.concurrent.TimeUnit;
public class TokenBucketRateLimiter {    private long capacity; // 令牌桶容量，即最大允许的请求数量    private long rate; // 令牌产生速率，即每秒产生的令牌数量    private long tokens; // 当前令牌数量    private ScheduledExecutorService scheduler; // 调度器
    public TokenBucketRateLimiter(long capacity, long rate) {        this.capacity = capacity;        this.rate = rate;        this.tokens = capacity;        this.scheduler = new ScheduledThreadPoolExecutor(1);        scheduleRefill(); // 启动令牌补充任务    }
    private void scheduleRefill() {        scheduler.scheduleAtFixedRate(() -> {            synchronized (this) {                tokens = Math.min(capacity, tokens + rate); // 补充令牌，但不超过容量            }        }, 1, 1, TimeUnit.SECONDS); // 每秒产生一次令牌    }
    public synchronized boolean tryAcquire() {        if (tokens > 0) { // 判断令牌数量是否大于0            tokens--; // 消耗一个令牌            return true; // 获取请求成功        }        return false; // 令牌不足，无法获取请求    }}

代码解读

capacity表示令牌桶的容量，即最大允许的请求数量；rate表示令牌产生速率，即每秒产生的令牌数量。tokens表示当前令牌数量，scheduler是用于调度令牌补充任务的线程池。

在构造方法中，初始化令牌桶的容量和当前令牌数量，并启动令牌补充任务scheduleRefill()。

scheduleRefill()方法使用调度器定期执行令牌补充任务，每秒补充一次令牌。在补充任务中，通过加锁的方式更新令牌数量，确保线程安全。补充的令牌数量为当前令牌数量加上产生速率，但不超过令牌桶的容量。

tryAcquire()方法使用synchronized关键字来实现线程安全，在方法中进行以下操作：

判断令牌数量是否大于0。

Guava的RateLimiter限流组件，就是基于令牌桶算法实现的。

适用场景

一般用于保护自身的系统，对调用者进行限流，保护自身的系统不被突发的流量打垮。如果自身的系统实际的处理能力强于配置的流量限制时，可以允许一定程度的流量突发，使得实际的处理速率高于配置的速率，充分利用系统资源。

优劣分析

优势：

劣势：

简介：滑动日志限速算法需要记录请求的时间戳，通常使用有序集合来存储，我们可以在单个有序集合中跟踪用户在一个时间段内所有的请求。

原理：

滑动日志算法可以用于实现限流功能，即控制系统在单位时间内处理请求的数量，以保护系统免受过载的影响。以下是滑动日志算法用于限流的原理：

通过滑动日志算法进行限流，可以实现对单位时间内的请求进行精确控制。它基于实时统计的方式，能够动态地适应请求流量的变化，并且在内存使用上比较高效。同时，通过调整时间窗口的长度和阈值的设置，可以灵活地控制限流的精度和灵敏度。

实现方式

import java.util.LinkedList;import java.util.List;
public class SlidingLogRateLimiter {    private int requests; // 请求总数    private List<Long> timestamps; // 存储请求的时间戳列表    private long windowDuration; // 窗口持续时间，单位：毫秒    private int threshold; // 窗口内的请求数阀值
    public SlidingLogRateLimiter(int threshold, long windowDuration) {        this.requests = 0;        this.timestamps = new LinkedList<>();        this.windowDuration = windowDuration;        this.threshold = threshold;    }
    public synchronized boolean tryAcquire() {        long currentTime = System.currentTimeMillis(); // 获取当前时间戳        // 删除超过窗口持续时间的时间戳        while (!timestamps.isEmpty() && currentTime - timestamps.get(0) > windowDuration) {            timestamps.remove(0);            requests--;        }
        if (requests < threshold) { // 判断当前窗口内请求数是否小于阀值            timestamps.add(currentTime); // 将当前时间戳添加到列表            requests++; // 请求总数增加            return true; // 获取请求成功        }
        return false; // 超过阀值，无法获取请求    }}

代码解读

在以上代码中，requests表示请求总数，timestamps用于存储请求的时间戳列表，windowDuration表示窗口持续时间，threshold表示窗口内的请求数阀值。

在构造函数中传入窗口内的请求数阀值和窗口持续时间。

tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

使用这个滑动日志限流算法，可以限制在一定时间窗口内的请求频率，超过阀值的请求会被限制。您可以根据实际需求和业务场景进行调整和使用。

适用场景：对实时性要求高，且需要精确控制请求速率的高级限流场景。

优劣分析

优势：

劣势：



1）RateLimiter（单机）

简介：基于令牌桶算法实现的一个多线程限流器，它可以将请求均匀的进行处理，当然他并不是一个分布式限流器，只是对单机进行限流。它可以应用在定时拉取接口数。通过aop、filter、Interceptor 等都可以达到限流效果。

用法

以下是一个基本的 RateLimiter 用法示例：

import com.google.common.util.concurrent.RateLimiter;
public class RateLimiterDemo {    public static void main(String[] args) {        // 创建一个每秒允许2个请求的RateLimiter        RateLimiter rateLimiter = RateLimiter.create(2.0);
        while (true) {            // 请求RateLimiter一个令牌            rateLimiter.acquire();            // 执行操作            doSomeLimitedOperation();        }    }
    private static void doSomeLimitedOperation() {        // 模拟一些操作        System.out.println("Operation executed at: " + System.currentTimeMillis());    }}

在这个例子中，RateLimiter.create(2.0) 创建了一个每秒钟只允许2个操作的限速器。rateLimiter.acquire() 方法会阻塞当前线程直到获取到许可，确保调用 doSomeLimitedOperation() 操作的频率不会超过限制。

RateLimiter 还提供了其他的方法，例如tryAcquire()，它会尝试获取许可而不会阻塞，立即返回获取成功或失败的结果。还可以设置等待时间上限，比如 tryAcquire(long timeout, TimeUnit unit) 可以设置最大等待时间。

Guava的RateLimiter非常灵活，它支持平滑突发限制（SmoothBursty）和平滑预热限制（SmoothWarmingUp）等多种模式，可以根据特定的应用场景来选择合适的限流策略。

2）sentinel（单机或者分布式）

简介：Sentinel是阿里巴巴开源的一款面向分布式系统的流量控制和熔断降级组件。它提供了实时的流量控制、熔断降级、系统负载保护和实时监控等功能，可以帮助开发者保护系统的稳定性和可靠性。

单机模式

集群模式

Sentinel 集群限流服务端有两种启动方式：

用法

Sentinel的用法主要包括以下几个方面：

<dependency>    <groupId>com.alibaba.csp</groupId>    <artifactId>sentinel-core</artifactId>    <version>1.8.2</version></dependency>

@SentinelResource(value = "demo", blockHandler = "handleBlock")public String demo() {    // ...}

public static void main(String[] args) {    System.setProperty("csp.sentinel.dashboard.server", "localhost:8080"); // 设置控制台地址    System.setProperty("project.name", "your-project-name"); // 设置应用名称    com.alibaba.csp.sentinel.init.InitExecutor.doInit();    SpringApplication.run(YourApplication.class, args);}

3）Nginx（分布式）

简介：Nginx从网关这一层面考虑，可以作为最前置的网关，抵挡大部分的网络流量，因此使用Nginx进行限流也是一个很好的选择，在Nginx中，也提供了常用的基于限流相关的策略配置。

用法

Nginx 提供了两种限流方法：一种是控制速率，另一种是控制并发连接数。

我们需要使用 limit_req_zone 用来限制单位时间内的请求数，即速率限制，

因为Nginx的限流统计是基于毫秒的，我们设置的速度是 2r/s，转换一下就是500毫秒内单个IP只允许通过1个请求，从501ms开始才允许通过第2个请求。

上面的速率控制虽然很精准但是在生产环境未免太苛刻了，实际情况下我们应该控制一个IP单位总时间内的总访问次数，而不是像上面那样精确到毫秒，我们可以使用 burst 关键字开启此设置。

burst=4意思是每个IP最多允许4个突发请求

利用 limit_conn_zone 和 limit_conn 两个指令即可控制并发数

其中 limit_conn perip 10 表示限制单个 IP 同时最多能持有 10 个连接；limit_conn perserver 100 表示 server 同时能处理并发连接的总数为 100 个。

注意：只有当 request header 被后端处理后，这个连接才进行计数。

降级是在高并发或异常情况下舍弃非关键业务或简化处理的一种技术手段。

按类型可分为有感降级，无感降级。

在限流中，服务调用方为每一个调用的服务维护一个有限状态机，在这个状态机会有三种状态：关闭（调用远程服务）、半打开（尝试调用远程服务）和打开（返回错误）。这三种状态之间切换的过程如下：

当调用失败的次数累积到一定的阈值时，熔断机制从关闭态切换到打开态。一般在实现时，如果调用成功一次，就会重置调用失败次数。

当熔断处于打开状态时，我们会启动一个计时器，当计时器超时后，状态切换到半打开态。也可以通过设置一个定时器，定期的探测服务是否恢复。

当熔断处于半打开状态时，请求可以达到后端服务，如果累计一定的成功次数后，状态切换到关闭态；如果出现调用失败的情况，则切换到打开态。

1）熔断

简介：熔断在程序中，表示“断开”的意思。如发生了某事件，程序为了整体的稳定性，所以暂时（断开）停止服务一段时间，以保证程序可用时再被使用。

熔断和降级的区别

熔断程序为了整体的稳定性，所以暂时（断开）停止服务一段时间；降级（Degradation）降低级别的意思，它是指程序在出现问题时，仍能保证有限功能可用的一种机制；

不同框架的熔断和降级的触发条件是不同，以Hystrix为例：

默认情况 hystrix 如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。

默认情况下，hystrix 在以下 4 种条件下都会触发降级机制：

熔断时可能会调用降级机制，而降级时通常不会调用熔断机制。因为熔断是从全局出发，为了保证系统稳定性而停用服务，而降级是退而求其次，提供一种保底的解决方案，所以它们的归属关系是不同（熔断 > 降级）。