互联网行业迅速发展,用户量剧增,系统面临巨大的并发请求压力。
软件系统有三个追求:高性能、高并发、高可用,俗称三高。三者既有区别也有联系,门门道道很多,全面讨论需要三天三夜,本篇讨论高并发
性能下降、资源竞争和稳定性问题等
高并发是指系统或应用程序在同一时间段内接收到大量并发请求的能力。具体来说,高并发环境下系统需要能够同时处理大量的请求,而不会出现性能问题或响应延迟
高并发场景广泛应用于热门网站、电商平台、社交媒体等互联网应用中。例如,在电商平台上有大量用户同时浏览、搜索商品,提交订单等操作;社交媒体平台上有大量用户同时发布、点赞、评论等操作。这些场景需要系统能够同时处理大量请求,并保证系统的性能、可用性和用户体验
在网站或APP的开发中,缓存机制是一个不可或缺的环节,可以提高网站或APP的访问速度,降低数据库压力。但在高并发环境下,缓存机制的作用更加明显,不仅可以有效减轻数据库的负载,还可以提高系统的稳定性和性能,从而给用户带来更好的体验
缓存的工作原理是先从缓存中获取数据,如果有数据则直接返回给用户,如果没有数据则从慢速设备上读取实际数据并且将数据放入缓存。
浏览器缓存是指将网页中的资源(如HTML、CSS、JavaScript、图像等)存储在用户的浏览器内部,以便在后续请求同一资源时可以直接从本地缓存中获取,而无需再次从服务器下载
浏览器缓存适用于那些静态内容变化较少的网页和静态资源,可以显著提升网站性能和用户体验,并减少服务器的负载
使用浏览器缓存可以通过设置响应头中的Expires和Cache-Control字段来控制缓存的行为。
浏览器缓存存储实时性不敏感的数据,如商品框架、商家评分、评价和广告词。它有过期时间,并通过响应头进行控制。实时性要求高的数据不适合使用浏览器缓存
客户端缓存是将数据存储在浏览器中,以提高访问速度和减少服务器请求
在大促期间,为了防止服务端承受瞬间的高流量压力,可以提前将一些素材(如js/css/image等)下发到客户端进行缓存,避免在大促期间再次请求这些素材。此外,还可以将一些兜底数据或样式文件存放在客户端缓存中,以确保在服务端异常或网络异常的情况下,保持app的正常运行。
CDN(Content Delivery Network)是建立在承载网之上的分布式网络,由分布在不同区域的边缘节点服务器组成。
CDN缓存通常用于存放静态页面数据、活动页面、图片等数据。它有两种缓存机制:推送机制(将数据主动推送到CDN节点)和拉取机制(首次访问时从源服务器获取数据并存储在CDN节点)。
CDN缓存可以提高网站访问速度,适用于网站访问量大、访问速度慢、数据变化不频繁的场景
常见的CDN缓存工具包括Cloudflare、Akamai、Fastly和AWS CloudFront等。这些工具提供了全球分布的CDN网络,以加速内容传输和提升性能。它们提供了控制台和API,用于配置CDN缓存规则、管理缓存内容、刷新和更新缓存等
反向代理缓存是指在反向代理服务器上对请求的响应进行缓存,以提高服务的性能和用户体验。它将经常请求的静态内容缓存在代理服务器上,当有用户请求同样的内容时,代理服务器会直接返回缓存的响应,而无需再次向源服务器请求
适用于访问外部服务速度比较慢,但是数据变化不频繁的场景。
本地缓存是将数据或资源存储在客户端的存储介质中,如硬盘、内存或数据库。它可以是临时的,只在应用程序运行期间有效,或者可以是持久的,即在不同的应用程序会话中保持有效
本地缓存适用于频繁访问数据、离线访问、减少带宽消耗和提升用户体验的场景。
一般分为磁盘缓存、CPU缓存、应用缓存
分布式缓存是将缓存数据分散存储在多台服务器上的缓存解决方案
高并发读取、数据共享和协同处理、提供弹性和可扩展性、降低后端请求次数等场景
缓存穿透是指数据库和缓存都没有的数据,每次都要经过缓存去访问数据库,大量的请求有可能导致DB宕机。(强调都没有数据+并发访问)
缓存击穿是指数据库有,缓存没有的数据,大量请求访问这个缓存不存在的数据,最后请求打到DB可能导致DB宕机。(强调单个Key过期+并发访问)
缓存雪崩是指数据库有,缓存没有的数据,大量请求访问这些缓存不存在的数据,最后请求打到DB可能导致DB宕机。(强调批量Key过期+并发访问)
缓存一致性指的是缓存与DB之间的数据一致性,我们需要通过各种手段来防止缓存与DB不一致,我们要保证缓存与DB的数据一致或者数据最终一致。
缓存的好处我们非常受益,用户的每一次请求都伴随着无数缓存的诞生,但是缓存同时也给我们带来了不小的挑战,比如在上面提到的一些疑难课题:缓存穿透、缓存击穿、缓存雪崩和缓存一致性。
除此之外,我们还会涉及到其他的一些缓存难题,如:缓存倾斜、缓存阻塞、缓存慢查询、缓存主从一致性问题、缓存高可用、缓存故障发现与故障恢复、集群扩容收缩、大Key热Key......
再强大的系统,也怕流量短事件内集中爆发,就像银行怕挤兑一样,所以,高并发另一个必不可少的模块就是限流。
限流是一种通过控制请求的速率或数量来保护系统免受过载的技术。流控的精髓是限制单位时间内的请求量,最大程度保障系统的可靠性及可用性
限流是在高并发环境下,为了保护系统的稳定性和可用性而引入的一种策略。通过限制并发请求的数量或频率,可以防止系统被过多的请求压垮或耗尽资源
常见的流控算法包括:固定窗口、滑动窗口、漏桶、令牌桶、滑动日志等算法
固定窗口限流算法(Fixed Window Rate Limiting Algorithm)是一种最简单的限流算法,其原理是在固定时间窗口(单位时间)内限制请求的数量
固定窗口是最简单的流控算法。即,给定时间窗口,维护一个计数器用于统计访问次数,并实现以下规则:
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;
}
为了解决临界突变问题,可以引入滑动窗口。即:把大的时间窗口拆分成若干粒度更细的子窗口,每个子窗口独立统计,按子窗口时间滑动,统一限流。
当滑动窗口的格子周期划分的越多,那么滑动窗口的滚动就越平滑,限流的统计就会越精确。
将单位时间周期分为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 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> iterator = counters.entrySet().iterator();
while (iterator.hasNext()) {
Map.Entry 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 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();
}
}
固定窗口算法实现简单,性能高,但是会有临界突发流量问题,瞬时流量最大可以达到阈值的2倍。
为了解决临界突发流量,可以将窗口划分为多个更细粒度的单元,每次窗口向右移动一个单元,于是便有了滑动窗口算法。
滑动窗口当流量到达阈值时会瞬间掐断流量,所以导致流量不够平滑。
想要达到限流的目的,又不会掐断流量,使得流量更加平滑?可以考虑漏桶算法!需要注意的是,漏桶算法通常配置一个FIFO的队列使用以达到允许限流的作用。
由于速率固定,即使在某个时刻下游处理能力过剩,也不能得到很好的利用,这是漏桶算法的一个短板。
限流和瞬时流量其实并不矛盾,在大多数场景中,短时间突发流量系统是完全可以接受的。令牌桶算法就是不二之选了,令牌桶以固定的速率v产生令牌放入一个固定容量为n的桶中,当请求到达时尝试从桶中获取令牌。
当桶满时,允许最大瞬时流量为n;当桶中没有剩余流量时则限流速率最低,为令牌生成的速率v。
如何实现更加灵活的多级限流呢?滑动日志限流算法了解一下!这里的日志则是请求的时间戳,通过计算制定时间段内请求总数来实现灵活的限流。
当然,由于需要存储时间戳信息,其占用的存储空间要比其他限流算法要大得多。
以上几种限流算法的实现都仅适合单机限流。虽然给每台机器平均分配限流配额可以达到限流的目的,但是由于机器性能,流量分布不均以及计算数量动态变化等问题,单机限流在分布式场景中的效果总是差强人意。
分布式限流最简单的实现就是利用中心化存储,即将单机限流存储在本地的数据存储到同一个存储空间中,如常见的Redis等。
基于令牌桶算法实现的一个多线程限流器,它可以将请求均匀的进行处理,当然他并不是一个分布式限流器,只是对单机进行限流。它可以应用在定时拉取接口数。 通过aop、filter、Interceptor 等都可以达到限流效果
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 被后端处理后,这个连接才进行计数。
降级是在高并发或异常情况下舍弃非关键业务或简化处理的一种技术手段
按类型可分为有感降级,无感降级
主要是通过一定的监控感知到异常出现或即将出现,对调用服务进行快速失败返回或者进行切换,在指标回正的时候恢复服务调用,这个也可以称为熔断。
系统不作感知,在调用服务出现异常则自动忽略,进行空返回或无操作。降级的本质为作为服务调用方去规避提供方带来的风险。
在限流中,服务调用方为每一个调用的服务维护一个有限状态机,在这个状态机会有三种状态:关闭(调用远程服务)、半打开(尝试调用远程服务)和打开(返回错误)。这三种状态之间切换的过程如下:
当调用失败的次数累积到一定的阈值时,熔断机制从关闭态切换到打开态。一般在实现时,如果调用成功一次,就会重置调用失败次数
当熔断处于打开状态时,我们会启动一个计时器,当计时器超时后,状态切换到半打开态。也可以通过设置一个定时器,定期的探测服务是否恢复
当熔断处于半打开状态时,请求可以达到后端服务,如果累计一定的成功次数后,状态切换到关闭态;如果出现调用失败的情况,则切换到打开态
熔断在程序中,表示“断开”的意思。如发生了某事件,程序为了整体的稳定性,所以暂时(断开)停止服务一段时间,以保证程序可用时再被使用。
默认情况 hystrix 如果检测到 10 秒内请求的失败率超过 50%,就触发熔断机制。之后每隔 5 秒重新尝试请求微服务,如果微服务不能响应,继续走熔断机制。如果微服务可达,则关闭熔断机制,恢复正常请求。
* Hystrix 降级触发条件
默认情况下,hystrix 在以下 4 种条件下都会触发降级机制:
附录