用户1292700247120
获得徽章 0
赞了这篇文章
#青训营笔记创作活动#
12月30日 打卡day1
高并发场景下，需要去应对流量高峰，常用方法有限流、熔断、降级。
什么是限流呢？限流是限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则通过拒绝服务的方式保证整体系统的可用性。
根据限流方式，分为计数器、滑动窗口、漏桶限令牌桶限流。
计数器限流是最简单的限流算法，其原理就是：在一段时间间隔内，对请求进行计数，与阀值进行比较判断是否需要限流，一旦到了时间临界点，将计数器清零。
1. 在程序中设置一个变量 count，过来一个请求就将这个数 +1，同时记录请求时间。
2. 下一个请求过来的时候，判断 count 的计数值是否超过设定的频次，以及当前请求的时间和第一次请求时间是否在 1 分钟内。
3. 如果在 1 分钟内并且超过设定的频次则证明请求过多，后面的请求就拒绝掉。
4. 如果该请求与第一个请求的间隔时间大于计数周期，且 count 值还在限流范围内，就重置 count。
这种方法虽然简单，但也没有很好的处理单位时间的边界。可能在两个单位时间之间出现请求高峰。系统可能会承受恶意用户的大量请求，甚至击穿系统。
滑动窗口限流把固定时间片划分成固定数量的可以移动的格子，并且随着时间的流逝，进行移动，对每个格子计数并判断阀值。
比如，一个时间窗口（一分钟），有 6 个格子，每个格子是 10 秒钟。每过 10 秒钟时间窗口向右移动一格。我们为每个格子都设置一个独立的计数器 Counter，假如一个请求在 0:45 访问了那么我们将第五个格子的计数器 +1（也是就是 0:40~0:50），在判断限流的时候需要把所有格子的计数和设定的频次进行比较即可。
其实计数器就是滑动窗口，只不过只有一个格子。格子的数量影响着滑动窗口算法的精度，依然有时间片的概念，无法根本解决临界点问题。
漏桶：
优点：可以很好的控制消费频率；
缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。
令牌桶：
优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；
缺点：实现稍微复杂，其它缺点没有想到。
Redis + Lua 分布式限流：
优点：支持分布式限流，有效保护下游依赖的服务资源；
缺点：依赖 Redis，对边界没有很好处理，导致限流不能精准控制。
12月30日 打卡day1
高并发场景下，需要去应对流量高峰，常用方法有限流、熔断、降级。
什么是限流呢？限流是限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则通过拒绝服务的方式保证整体系统的可用性。
根据限流方式，分为计数器、滑动窗口、漏桶限令牌桶限流。
计数器限流是最简单的限流算法，其原理就是：在一段时间间隔内，对请求进行计数，与阀值进行比较判断是否需要限流，一旦到了时间临界点，将计数器清零。
1. 在程序中设置一个变量 count，过来一个请求就将这个数 +1，同时记录请求时间。
2. 下一个请求过来的时候，判断 count 的计数值是否超过设定的频次，以及当前请求的时间和第一次请求时间是否在 1 分钟内。
3. 如果在 1 分钟内并且超过设定的频次则证明请求过多，后面的请求就拒绝掉。
4. 如果该请求与第一个请求的间隔时间大于计数周期，且 count 值还在限流范围内，就重置 count。
这种方法虽然简单，但也没有很好的处理单位时间的边界。可能在两个单位时间之间出现请求高峰。系统可能会承受恶意用户的大量请求，甚至击穿系统。
滑动窗口限流把固定时间片划分成固定数量的可以移动的格子，并且随着时间的流逝，进行移动，对每个格子计数并判断阀值。
比如，一个时间窗口（一分钟），有 6 个格子，每个格子是 10 秒钟。每过 10 秒钟时间窗口向右移动一格。我们为每个格子都设置一个独立的计数器 Counter，假如一个请求在 0:45 访问了那么我们将第五个格子的计数器 +1（也是就是 0:40~0:50），在判断限流的时候需要把所有格子的计数和设定的频次进行比较即可。
其实计数器就是滑动窗口，只不过只有一个格子。格子的数量影响着滑动窗口算法的精度，依然有时间片的概念，无法根本解决临界点问题。
漏桶：
优点：可以很好的控制消费频率；
缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。
令牌桶：
优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；
缺点：实现稍微复杂，其它缺点没有想到。
Redis + Lua 分布式限流：
优点：支持分布式限流，有效保护下游依赖的服务资源；
缺点：依赖 Redis，对边界没有很好处理，导致限流不能精准控制。
展开
评论
点赞