高并发架构设计（三大利器：缓存、限流和降级）

引言

高并发背景

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

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

高并发对系统的挑战

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

什么是高并发

高并发的定义

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

高并发的特点

大量请求：高并发场景下，系统需要同时处理大量的请求，这些请求可能来自于不同的用户或客户端。
同时访问：这些请求几乎同时到达系统，需要在短时间内进行处理和响应。
资源竞争：由于大量请求同时到达，系统的资源（如CPU、内存、网络带宽等）可能会面临竞争和争夺。
响应时间要求高：高并发场景通常对系统的响应速度有较高的要求，用户期望能够快速获取响应结果

高并发场景和应用

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

高并发的影响

系统性能的下降和延迟增加
资源竞争和资源耗尽
系统稳定性和可用性的挑战

高并发应对策略

缓存：缓解系统负载压力，提高系统响应速度
限流：控制并发访问量，保护系统免受过载影响
降级：保证核心功能的稳定性，舍弃非关键业务或简化处理

缓存

简介

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

工作原理

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

常用技术

浏览器缓存

简介

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

适用场景

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

常见用法

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

使用Expires字段：Expires字段指定了缓存的过期时间，是一个具体的日期和时间。服务器可以在响应头中添加Expires字段，告诉浏览器在该时间之前可以直接从缓存中获取资源，而无需再向服务器发起请求。例如：Expires: Mon, 31 Dec 2022 23:59:59 GMT。
使用Cache-Control字段：Cache-Control字段提供了更灵活的缓存控制选项。可以通过设置max-age指令来指定缓存的最大有效时间，单位是秒。例如：Cache-Control: max-age=3600 表示资源可以在1小时内直接从缓存中获取。还可以使用其他指令，如no-cache表示缓存但不使用缓存、no-store表示禁止缓存等。

注意事项

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

客户端缓存

简介

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

适用场景

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

CDN缓存

简介

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

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

适用场景

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

常用工具以及用法

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

反向代理缓存

简介

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

适用场景

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

常用工具以及用法

Nginx：一款高性能的反向代理服务器，支持反向代理缓存功能，可通过配置文件进行缓存策略的设置。Nginx代理层缓存主要以Http模块与proxy_cacahe模块进行配置即可。
Varnish：一个专门用于反向代理缓存的开源软件，可以高效地缓存并提供快速的响应。
Squid：一款功能强大的缓存代理服务器，支持反向代理缓存和正向代理缓存。

本地缓存

简介

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

适用场景

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

常用工具以及用法

一般分为磁盘缓存、CPU缓存、应用缓存

磁盘缓存：存储在硬盘等永久性存储介质上，用于加速数据的读取和访问。
CPU缓存：位于处理器内部的高速存储器，用于暂时存储频繁访问的数据或指令，提高计算机的性能。
应用缓存：存储在内存中的应用程序数据或资源，用于提高应用程序的响应速度和用户体验。用Java服务来举例，又分为堆内缓存与堆外缓存。

分布式缓存

简介

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

适用场景

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

常用工具以及用法

Redis：Redis是一种高性能的键值存储系统，支持丰富的数据类型和灵活的缓存策略。可以使用Redis搭建分布式缓存集群，利用其快速的读写能力和一致性哈希算法实现数据分片和负载均衡。
Memcached：Memcached是一种简单而快速的分布式内存对象缓存系统，用于减轻数据库负载和加速动态Web应用程序。它采用分布哈希算法进行数据分片和分布式存储。
Hazelcast：Hazelcast是一个开源的分布式内存数据网格平台，提供分布式缓存和分布式计算能力。它可以用于构建高吞吐量和高可用性的分布式缓存系统。

缓存问题

缓存穿透

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

缓存击穿

缓存击穿是指数据库有，缓存没有的数据，大量请求访问这个缓存不存在的数据，最后请求打到DB可能导致DB宕机。（强调单个Key过期+并发访问）

缓存雪崩

缓存雪崩是指数据库有，缓存没有的数据，大量请求访问这些缓存不存在的数据，最后请求打到DB可能导致DB宕机。（强调批量Key过期+并发访问）

缓存一致性

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

其他

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

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

小结

缓存类型	介绍	解决方案/工具	优点	缺点	适用场景
浏览器缓存	存储在用户设备上的缓存，用于存储静态资源和页面内容。	通过设置HTTP头中的缓存相关字段来控制缓存行为。	- 快速响应，避免频繁访问服务器或网络 - 减少网络带宽消耗，提升网站性能	- 缓存数据可能不是最新的，需要考虑缓存一致性和更新机制的设计 - 缓存命中率受限于缓存容量和缓存策略的选择	- 静态资源的缓存 - 减少网络带宽消耗
客户端缓存	应用程序在用户设备上的缓存，用于存储数据、计算结果或其他业务相关的内容。	使用本地存储、SessionStorage、LocalStorage或IndexedDB等Web API来进行数据的存储和读取。	- 减轻后端负载，提升系统性能 - 快速响应，避免频繁访问服务器或网络资源	- 缓存数据可能不是最新的，需要考虑缓存一致性和更新机制的设计 - 缓存命中率受限于缓存容量和缓存策略的选择	- 频繁访问的数据或计算结果 - 减轻后端负载
CDN缓存	内容分发网络的缓存，用于存储和加速静态资源的分发。	部署静态资源到CDN服务器并配置CDN缓存策略，用户请求将被转发到就近的CDN节点，加速内容的分发和访问。	- 加速静态资源的访问速度，提升用户体验 - 减轻源服务器负载，提高系统可扩展性	- 只适用于静态资源的缓存，动态内容无法缓存 - CDN配置和管理的复杂性	- 静态资源的分发和访问 - 加速静态资源的加载和访问
反向代理缓存	位于服务器前端的缓存，用于缓存和加速动态内容和静态资源的访问。	配置反向代理服务器并设置缓存策略，将用户请求转发到缓存服务器，减轻后端服务器的负载并加速内容的访问。	- 加速内容的访问速度，提升用户体验 - 减轻源服务器负载，提高系统可扩展性	- 只适用于特定的Web服务器和应用程序	- 动态内容和静态资源的缓存和加速访问 - 减轻后端服务器的负载
本地缓存	应用程序在用户设备上的缓存，用于缓存数据和资源以提高应用的性能和响应速度。	使用缓存库或框架（如localStorage、sessionStorage、Workbox等）来实现本地缓存功能。	- 提升应用的性能和响应速度 - 减少对远程资源的依赖，提高离线使用体验	- 本地缓存容量受限于用户设备的存储空间	- 频繁访问的数据或资源 - 提升应用的性能和响应速度
分布式缓存	在分布式系统中使用的缓存，用于存储和共享数据。分布式缓存通常部署在多台服务器上，并提供高并发读写能力和数据访问的可扩展性。分布式缓存常用于大规模应用和系统中。	使用分布式缓存系统（如Redis、Memcached等）来存储和访问缓存数据。	- 高并发读写能力和数据存储的可扩展性	- 需要额外的服务器资源来部署和管理分布式缓存系统 - 缓存一致性和数据同步问题需要考虑	- 高并发读写能力和数据存储的可扩展性 - 大规模应用和系统的缓存和数据共享

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

限流

简介

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

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

作用

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

限流算法

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

固定窗口算法（计数器）

简介

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

原理

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

如果访问次数小于阈值，则允许访问，访问次数+1；
如果访问次数超出阈值，则限制访问，访问次数不增；
如果超过了时间窗口，计数器清零，并重置清零后的首次成功访问时间为当前时间。

适用场景

保护后端服务免受大流量冲击，避免服务崩溃。
对 API 调用进行限制，保证公平使用。
防止恶意用户对服务进行洪水攻击

实现方式

public static Integer counter = 0;  //统计请求数
public static long lastAcquireTime =  0L;
public static final Long windowUnit = 1000L ; //假设固定时间窗口是1000ms
public static final Integer threshold = 10; // 窗口阀值是10
/**
  * 固定窗口时间算法
  */
 public synchronized boolean fixedWindowsTryAcquire() {
     long currentTime = System.currentTimeMillis();  //获取系统当前时间
     if (currentTime - lastAcquireTime > windowUnit) {  //检查是否在时间窗口内
         counter = 0;  // 计数器清0
         lastAcquireTime = currentTime;  //开启新的时间窗口
     }
     if (counter < threshold) {  // 小于阀值
         counter++;  //计数统计器加1
         return true;
     }

     return false;
 }

优劣分析

优点

- 固定窗口算法非常简单，易于实现和理解。
- 性能高

缺点

- 存在明显的临界问题
  eg:
  比如: 假设限流阀值为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了，已触发限流啦，实际上，紫色格子的请求都被拒绝

实现方式

/**
 * 单位时间划分的小周期（单位时间是1分钟，10s一个小格子窗口，一共6个格子）
 */
private int SUB_CYCLE = 10;

/**
 * 每分钟限流请求数
 */
private int thresholdPerMin = 100;

/**
 * 计数器, k-为当前窗口的开始时间值秒，value为当前窗口的计数
 */
private final TreeMap<Long, Integer> counters = new TreeMap<>();

/**
 * 滑动窗口时间算法实现
 */
 public synchronized boolean slidingWindowsTryAcquire() {
    long currentWindowTime = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC) / SUB_CYCLE * SUB_CYCLE; //获取当前时间在哪个小周期窗口
    int currentWindowNum = countCurrentWindow(currentWindowTime); //当前窗口总请求数

    //超过阀值限流
    if (currentWindowNum >= thresholdPerMin) {
        return false;
    }

    //计数器+1
    counters.get(currentWindowTime)++;
    return true;
}

/**
* 统计当前窗口的请求数
*/
private int countCurrentWindow(long currentWindowTime) {
    //计算窗口开始位置
    long startTime = currentWindowTime - SUB_CYCLE* (60s/SUB_CYCLE-1);
    int count = 0;

    //遍历存储的计数器
    Iterator<Map.Entry<Long, Integer>> iterator = counters.entrySet().iterator();
    while (iterator.hasNext()) {
        Map.Entry<Long, Integer> entry = iterator.next();
        // 删除无效过期的子窗口计数器
        if (entry.getKey() < startTime) {
            iterator.remove();
        } else {
            //累加当前窗口的所有计数器之和
            count =count + entry.getValue();
        }
    }
    return count;
}

适用场景

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

优劣分析

优势

- 简单易懂
- 精度高（通过调整时间窗口的大小来实现不同的限流效果）
- 可扩展性强（可以非常容易地与其他限流算法结合使用）

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

漏桶算法

简介

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

特点

可以以任意速率流入水滴到漏桶（流入请求）
漏桶具有固定容量，出水速率是固定常量（流出请求）
如果流入水滴超出了桶的容量，则流入的水滴溢出（新请求被拒绝）

原理

思想

将数据包看作是水滴，漏桶看作是一个固定容量的水桶，数据包像水滴一样从桶的顶部流入桶中，并通过桶底的一个小孔以一定的速度流出，从而限制了数据包的流量

工作原理

对于每个到来的数据包，都将其加入到漏桶中，并检查漏桶中当前的水量是否超过了漏桶的容量。
如果超过了容量，就将多余的数据包丢弃。如果漏桶中还有水，就以一定的速率从桶底输出数据包，保证输出的速率不超过预设的速率，从而达到限流的目的。

代码实现

 /**
 * LeakyBucket 类表示一个漏桶,
 * 包含了桶的容量和漏桶出水速率等参数，
 * 以及当前桶中的水量和上次漏水时间戳等状态。
 */
public class LeakyBucket {
    private final long capacity;    // 桶的容量
    private final long rate;        // 漏桶出水速率
    private long water;             // 当前桶中的水量
    private long lastLeakTimestamp; // 上次漏水时间戳

    public LeakyBucket(long capacity, long rate) {
        this.capacity = capacity;
        this.rate = rate;
        this.water = 0;
        this.lastLeakTimestamp = System.currentTimeMillis();
    }

    /**
     * tryConsume() 方法用于尝试向桶中放入一定量的水，如果桶中还有足够的空间，则返回 true，否则返回 false。
     */
    public synchronized boolean tryConsume(long waterRequested) {
        leak();
        if (water + waterRequested <= capacity) {
            water += waterRequested;
            return true;
        } else {
            return false;
        }
    }

    /**
     * leak() 方法用于漏水，根据当前时间和上次漏水时间戳计算出应该漏出的水量，然后更新桶中的水量和漏水时间戳等状态。
     */
    private void leak() {
        long now = System.currentTimeMillis();
        long elapsedTime = now - lastLeakTimestamp;
        long leakedWater = elapsedTime * rate / 1000;
        if (leakedWater > 0) {
            water = Math.max(0, water - leakedWater);
            lastLeakTimestamp = now;
        }
    }
}
注意: tryConsume() 和 leak() 方法中，都需要对桶的状态进行同步，以保证线程安全性。

适用场景

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

优劣分析

优势

- 可以平滑限制请求的处理速度，避免瞬间请求过多导致系统崩溃或者雪崩。
- 可以控制请求的处理速度，使得系统可以适应不同的流量需求，避免过载或者过度闲置。
- 可以通过调整桶的大小和漏出速率来满足不同的限流需求，可以灵活地适应不同的场景。

劣质

- 需要对请求进行缓存，会增加服务器的内存消耗。
- 对于流量波动比较大的场景，需要较为灵活的参数配置才能达到较好的效果。
- 但是面对突发流量的时候，漏桶算法还是循规蹈矩地处理请求，这不是我们想看到的啦。流量变突发时，我们肯定希望系统尽量快点处理请求，提升用户体验嘛。

令牌桶算法

简介

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

原理

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

实现方式

/**
 * TokenBucket 类表示一个令牌桶
 */
public class TokenBucket {

    private final int capacity;     // 令牌桶容量
    private final int rate;         // 令牌生成速率，单位：令牌/秒
    private int tokens;             // 当前令牌数量
    private long lastRefillTimestamp;  // 上次令牌生成时间戳

    /**
     * 构造函数中传入令牌桶的容量和令牌生成速率。
     */
    public TokenBucket(int capacity, int rate) {
        this.capacity = capacity;
        this.rate = rate;
        this.tokens = capacity;
        this.lastRefillTimestamp = System.currentTimeMillis();
    }

    /**
     * allowRequest() 方法表示一个请求是否允许通过，该方法使用 synchronized 关键字进行同步，以保证线程安全。
     */
    public synchronized boolean allowRequest() {
        refill();
        if (tokens > 0) {
            tokens--;
            return true;
        } else {
            return false;
        }
    }

    /**
     * refill() 方法用于生成令牌，其中计算令牌数量的逻辑是按照令牌生成速率每秒钟生成一定数量的令牌，
     * tokens 变量表示当前令牌数量，
     * lastRefillTimestamp 变量表示上次令牌生成的时间戳。
     */
    private void refill() {
        long now = System.currentTimeMillis();
        if (now > lastRefillTimestamp) {
            int generatedTokens = (int) ((now - lastRefillTimestamp) / 1000 * rate);
            tokens = Math.min(tokens + generatedTokens, capacity);
            lastRefillTimestamp = now;
        }
    }
}

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

适用场景

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

优劣分析

优势

- 稳定性高：令牌桶算法可以控制请求的处理速度，可以使系统的负载变得稳定。
- 精度高：令牌桶算法可以根据实际情况动态调整生成令牌的速率，可以实现较高精度的限流。
- 弹性好：令牌桶算法可以处理突发流量，可以在短时间内提供更多的处理能力，以处理突发流量。

劣质

- 实现复杂：相对于固定窗口算法等其他限流算法，令牌桶算法的实现较为复杂。对短时请求难以处理：在短时间内有大量请求到来时，可能会导致令牌桶中的令牌被快速消耗完，从而限流。这种情况下，可以考虑使用漏桶算法。
- 时间精度要求高：令牌桶算法需要在固定的时间间隔内生成令牌，因此要求时间精度较高，如果系统时间不准确，可能会导致限流效果不理想。

滑动日志算法（比较冷门）

简介

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

原理

实现方式

Copypublic class SlidingLogRateLimiter extends MyRateLimiter {
    /**
     * 每分钟限制请求数
     */
    private static final long PERMITS_PER_MINUTE = 60;
    /**
     * 请求日志计数器, k-为请求的时间（秒），value当前时间的请求数量
     */
    private final TreeMap<Long, Integer> requestLogCountMap = new TreeMap<>();

    @Override
    public synchronized boolean tryAcquire() {
        // 最小时间粒度为s
        long currentTimestamp = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);
        // 获取当前窗口的请求总数
        int currentWindowCount = getCurrentWindowCount(currentTimestamp);
        if (currentWindowCount >= PERMITS_PER_MINUTE) {
            return false;
        }
        // 请求成功，将当前请求日志加入到日志中
        requestLogCountMap.merge(currentTimestamp, 1, Integer::sum);
        return true;
    }

    /**
     * 统计当前时间窗口内的请求数
     *
     * @param currentTime 当前时间
     * @return -
     */
    private int getCurrentWindowCount(long currentTime) {
        // 计算出窗口的开始位置时间
        long startTime = currentTime - 59;
        // 遍历当前存储的计数器，删除无效的子窗口计数器，并累加当前窗口中的所有计数器之和
        return requestLogCountMap.entrySet()
                .stream()
                .filter(entry -> entry.getKey() >= startTime)
                .mapToInt(Map.Entry::getValue)
                .sum();
    }
}