免费企业网站模板psd,泗水网站建设ys178,网站建设的安全威胁,友情链接交换1.为什么要限流#xff1f; 任何一个系统的运算、存储、网络资源都不是无限的#xff0c;当系统资源不足以支撑外部超过预期的突发流量时#xff0c;就应该要有取舍#xff0c;建立面对超额流量自我保护的机制#xff0c;而这个机制就是微服务中常说的“限流” 2.四种限流…1.为什么要限流 任何一个系统的运算、存储、网络资源都不是无限的当系统资源不足以支撑外部超过预期的突发流量时就应该要有取舍建立面对超额流量自我保护的机制而这个机制就是微服务中常说的“限流” 2.四种限流设计模式 说到限流大家直接的想法就是Sentinel但是Sentinel限流的原理可能很多人没去深入理解或者限流到底是怎么做的具体如何进行限流业界内也有一些常见设计模式。 2.1流量计数器模式 流量计数器是一种最简单的限流方式通过记录固定时间窗口内的请求次数来判断是否达到限流阈值。如果请求次数超过限制值则拒绝后续请求。 实现方式 将时间划分为固定的时间窗口如 1 秒、1 分钟。 每个窗口维护一个计数器记录当前时间窗口内的请求次数。 如果计数器值超过限流阈值直接拒绝请求否则增加计数器。 固定窗口边界问题 在窗口边界的两端可能存在短时间内超量请求的“临界问题”
比如场景设定一秒内的TPS大于80时就限流。
存在问题即使每一秒的统计流量都没有超过 80 TPS也不能说明系统没有遇到过大于 80 TPS 的流量压力。比如说系统在连续2秒内都收到60TPS的请求但是请求发生的时间分别在第1秒的后0.5秒以及第2秒的前0.5秒。这样系统实际曾在1秒内发生超过80 TPS的请求。 即使连续若干秒统计流量超过阈值也不能说明流量压力一定超过系统承受能力
假设 10 秒的时间片段中前 3 秒的 TPS 平均值到了 100而后 7 秒的平均值是 30 左右此时系统是否能够处理完这些请求而不产生超时失败答案是可以的
存在缺陷造成上面2个问题得原因是流量计数器模式是对时间点进行离散的统计 2.2滑动窗口模式 概念时间轴上一个固定大小的窗口随时间平滑滚动。任何时刻静态地通过窗口内观察到的信息都等价于一段长度与窗口大小相等的信息。主要是通过记录多个较小时间窗口子窗口的请求次数实现更精细化的限流控制。 假设准备观察的时间片段为 10 秒以 1 秒作为统计精度那可以得到一个长度为 10 的数组。设定限流阈值是最近 10 秒内收到的请求不超过 500 个那么就需要统计10个子数组的请求总数是否超过阈值。 优点 解决了固定窗口边界问题 缺点 只适用于否决式限流超过阈值的流量就必须失败 2.3漏桶模式 漏桶可以简单的理解小学水池应用题一个水池每秒以 X 升速度注水同时又以 Y 升速度出水问水池啥时候装满。 概念将请求视为流入漏桶的水漏桶以固定速率“漏水”。当请求流量超过漏桶的处理能力时多余的请求会被丢弃或排队。其核心思想是平滑请求流量 实现方式 维护一个队列或计数器用来模拟漏桶。 新请求到来时将请求放入桶中。 按固定速率处理桶中的请求。 如果桶已满则拒绝新请求。 缺点 比较难确定桶的大小和水流出的速度 2.4令牌桶算法 和漏桶一样是基于缓冲区的限流算法简单理解就是去银行办事时在排队机号取号的场景。 概念通过固定速率向桶中添加令牌请求到来时需要先消耗令牌才能被处理。如果桶中没有足够的令牌请求会被拒绝。与漏桶算法不同令牌桶允许一定的突发流量。 实现方式 维护一个桶桶中存储令牌。 按固定速率比如限流是1秒100次请求那么间隔10ms时间放入令牌向桶中添加令牌直到桶满为止。 请求到来时从桶中取出令牌如果没有令牌就马上失败或者进入降级逻辑。 实际开发的时候不需要专门做放令牌到桶里这件事只需要在获取令牌前比较一下时间戳与当前时间就能算出需要放入多少令牌下面是示例代码 private long lastTime System.currentTimeMillis();
private int tokens 0; // 当前令牌数
private static final int LIMIT 100; // 桶容量
private static final int REFILL_RATE 10; // 令牌添加速率令牌/秒public synchronized boolean tryAcquire() {long now System.currentTimeMillis();// 添加令牌tokens Math.min(LIMIT, tokens (int) ((now - lastTime) / 1000) * REFILL_RATE);lastTime now;if (tokens 0) {tokens--;return true;}return false;
} 3.分布式限流 上面介绍的4种限流算法都只适用于单机限流或者把系统当做整体来限流。实际应用中仍然需要精细的每个服务的限流。 概念过将限流逻辑分散到多个节点同时使用一致性算法保证全局限流的一致性。它结合了本地限流和集中式限流的优点。 实现方式 基于 Redis Lua 脚本使用 Redis 脚本实现分布式限流在 Redis 中存储全局的请求计数器 基于一致性算法使用分布式一致性算法如 Raft、Paxos维护全局流量状态 分布式网关通过 API 网关如 Kong、Nginx、Spring Cloud Gateway实现流量的统一调度和限流。 缺点 实现复杂度高且网络通信和一致性操作带来额外延迟。当流量大时限流本身会降低系统处理能力 总结 今天学习了4种限流设计模式流量计数器模式、滑动窗口模式、漏桶模式、令牌桶模式后面2种都是基于缓冲区的限流算法。简单了解了下分布式限流的概念。限流本身是有代价的实际开发中需要权衡方案的代价和收益。后续有时间补充Sentinel的限流原理和其中用了哪些设计模式。 文章转载自卷福同学 原文链接https://www.cnblogs.com/dnboy/p/18621955 体验地址引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构
