对高并发流量控制的一点思考

最新推荐文章于 2024-03-01 13:40:44 发布
转载 最新推荐文章于 2024-03-01 13:40:44 发布 · 281 阅读 · 0
文章标签：

#java #面试 #高并发

微信公众号：javafirst

前言

在实际项目中，曾经遭遇过线上5W+QPS的峰值，也在压测状态下经历过10W+QPS的大流量请求，本篇博客的话题主要就是自己对高并发流量控制的一点思考。

应对大流量的一些思路

首先，我们来说一下什么是大流量？

大流量，我们很可能会冒出：TPS（每秒事务量），QPS（每秒请求量），1W+，5W+，10W+，100W+...。其实并没有一个绝对的数字，如果这个量造成了系统的压力，影响了系统的性能，那么这个量就可以称之为大流量了。

其次，应对大流量的一些常见手段是什么？

缓存：说白了，就是让数据尽早进入缓存，离程序近一点，不要大量频繁的访问DB。

降级：如果不是核心链路，那么就把这个服务降级掉。打个比喻，现在的APP都讲究千人千面，拿到数据后，做个性化排序展示，如果在大流量下，这个排序就可以降级掉！

限流：大家都知道，北京地铁早高峰，地铁站都会做一件事情，就是限流了！想法很直接，就是想在一定时间内把请求限制在一定范围内，保证系统不被冲垮，同时尽可能提升系统的吞吐量。

注意到，有些时候，缓存和降级是解决不了问题的，比如，电商的双十一，用户的购买，下单等行为，是涉及到大量写操作，而且是核心链路，无法降级的，这个时候，限流就比较重要了。

那么接下来，我们重点说一下，限流。

限流的常用方式

限流的常用处理手段有：计数器、滑动窗口、漏桶、令牌。

计数器

计数器是一种比较简单的限流算法，用途比较广泛，在接口层面，很多地方使用这种方式限流。在一段时间内，进行计数，与阀值进行比较，到了时间临界点，将计数器清0。

计数器思想

代码实例

计数器代码实现

这里需要注意的是，存在一个时间临界点的问题。举个栗子，在12:01:00到12:01:58这段时间内没有用户请求，然后在12:01:59这一瞬时发出100个请求，OK，然后在12:02:00这一瞬时又发出了100个请求。这里你应该能感受到，在这个临界点可能会承受恶意用户的大量请求，甚至超出系统预期的承受。

滑动窗口

由于计数器存在临界点缺陷，后来出现了滑动窗口算法来解决。


滑动窗口原理图

滑动窗口的意思是说把固定时间片，进行划分，并且随着时间的流逝，进行移动，这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子，将会进行计数判断阀值，因此格子的数量影响着滑动窗口算法的精度。

漏桶

虽然滑动窗口有效避免了时间临界点的问题，但是依然有时间片的概念，而漏桶算法在这方面比滑动窗口而言，更加先进。

有一个固定的桶，进水的速率是不确定的，但是出水的速率是恒定的，当水满的时候是会溢出的。

漏桶算法思想

代码实现

漏桶代码实现

令牌桶

注意到，漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。为了解决这个问题，令牌桶进行了算法改进。

令牌桶原理

生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。（有一点生产令牌，消费令牌的意味）

不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量，这是合理的，如果因为极少部分流量需要保证的话，那么就可能导致系统达到极限而挂掉，得不偿失。

代码实现

令牌桶代码实现

限流神器：Guava RateLimiter

Guava不仅仅在集合、缓存、异步回调等方面功能强大，而且还给我们封装好了限流的API！

Guava RateLimiter基于令牌桶算法，我们只需要告诉RateLimiter系统限制的QPS是多少，那么RateLimiter将以这个速度往桶里面放入令牌，然后请求的时候，通过tryAcquire()方法向RateLimiter获取许可（令牌）。

代码示例

RateLimiter

分布式场景下的限流

上面所说的限流的一些方式，都是针对单机而言的，其实大部分的场景，单机的限流已经足够了。分布式下限流的手段常常需要多种技术相结合，比如Nginx+Lua，Redis+Lua等去做。本文主要讨论的是单机的限流，这里就不在详细介绍分布式场景下的限流了。

一句话，让系统的流量，先到队列中排队、限流，不要让流量直接打到系统上。

好了，到这里，本文就结束了！

原文：https://www.jianshu.com/p/d9504fc0af4d

​


更多资源扫一扫免费获取


Java面试：
关注
高并发系统建设经验总结
Code365
06-26 818
前言 早期从事运单系统的开发和维护工作，从最早的日均百万单，到日均千万单，业务的快速发展再加上外卖业务的特点是，业务量集中在午高峰和晚高峰两个高峰期，所以高峰期并发请求量也是水涨船高，每天都要面对高并发的挑战。拿运单系统来举例，日常午高峰核心查询服务的 QPS 在 20 万以上，Redis 集群的 QPS 更是在百万级，数据库 QPS 也在 10 万级以上，TPS 在 2 万以上。 在这么大的流量下，主要的工作也是以围绕如何建设系统的稳定性和提升容量展开，下面主要从基础设施、数据库、架构、应用、规范这几
高性能零售IT系统的建设05-从0打造一个每秒万级并发的互联网交易系统的技术全架构
打造全国最全的AI Agent开发知识领域的博客
10-13 3832
亿万级的流量、每秒万级的并发的大型零售商超金融类应用如何设计与架构？如何面对汹涌的流量？本篇以全景式架构设计展示并结合一个个生产实例带你一步步深入了解如何应对大规模的高并发高流量的业务场景系统架构之美。
聊聊限流 聊聊限流 聊聊限流
飞楼踏梦
04-27 718
大家好，我是楼仔！ 在电商高并发场景下，我们经常会使用一些常用方法，去应对流量高峰，比如限流、熔断、降级，今天我们聊聊限流。 什么是限流呢？限流是限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则通过拒绝服务的方式保证整体系统的可用性。 根据限流作用范围，可以分为单机限流和分布式限流；根据限流方式，又分为计数器、滑动窗口、漏桶限令牌桶限流，下面我们对这块详细进行讲解。 文章大部分内容参考 TPaper 的《Go 实现各类限流算法》，特此说明！ 常用限流方..
高并发下的流量控制
天天water的专栏
02-29 4485
原优质博文链接：https://www.cnblogs.com/liangsonghua/p/www_liangsonghua_me_34.html 用户高峰期时，比如秒杀、抢购等，这个时候如果不做任何保护措施，服务器就会承受很大的处理压力，请求量很高，服务器负载也很高，并且当请求超过服务器承载极限的时候，系统就会崩溃，导致所有人都不能访问。 为了应用服务的高可用，一个常用的办法是对大流量的请...
高并发系统设计：流量控制
weixin_40108561的博客
09-03 702
定义 通过限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则只能通过拒绝服务的方式保证整体系统的可用性。 限流策略一般部署在服务的入口层，比如 API 网关中，这样可以对系统整体流量做塑形。而在微服务架构中，可以在 RPC 客户端中引入限流的策略，来保证单个服务不会被过大的流量压垮。 可以在多个维度上对到达系统的流量做控制，比如： 可以对系统每分钟处理多少请求做出限制； 可以针对单个接口设置每分钟请求流量的限制； 可以限制单个 IP、用户 ID 或者设备 ID 在一段
单机限流
hgkdzbf6的博客
08-25 512
单机限流 用户查询物流信息过于频繁。 接口限流，保证瞬时并发量。 限流算法 计数器 一段时间内，进行计数，与阈值进行比较，到了时间临界点，将计数器清零。 用Long的count变量做计数器，请求前计数器+1，如果超过阈值，并且和第一个请求的间隔还在1min内的话，则限流。 优点：实现简单 缺点：在12:01:00到12:01:58没有用户请求，在12:01:59的时候瞬间发了100个请求，然后在12:02:00这个时候又发了100个请求。 public class CounterLi
面试官：谈谈在项目中，如何应对高并发流量
yuandengta的博客
08-26 1078
前言 应对大流量的一些思路 限流的常用方式 限流神器：Guava RateLimiter 分布式场景下的限流 前言 在实际项目中，曾经遭遇过线上5W+QPS的峰值，也在压测状态下经历过10W+QPS的大流量请求，本篇博客的话题主要就是自己对高并发流量控制的一点思考。 应对大流量的一些思路 “ 首先，我们来说一下什么是大流量？ 大流量，我们很可能会冒出：TPS（每秒事务量），QPS（每秒请求量），1W+，5W+，10W+，100W+...。其实并没有一个绝对的数字，如果这个量造成了系统的压
谈谈在项目中，如何应对高并发流量
bishe_teacher的博客
07-09 559
谈谈在项目中，如何应对高并发流量 前言 应对大流量的一些思路 限流的常用方式 限流神器：Guava RateLimiter 分布式场景下的限流 前言 在实际项目中，曾经遭遇过线上5W+QPS的峰值，也在压测状态下经历过10W+QPS的大流量请求，本篇博客的话题主要就是自己对高并发流量控制的一点思考。 应对大流量的一些思路 “ 首先，我们来说一下什么是大流量？ 大流量，我们很可能会冒出：TPS（每秒事务量），QPS（每秒请求量），1W+，5W+，10W+，100W+…。其实并没有一个绝对的数字，如果这个量造成
高并发限流
大鸡腿的博客
06-20 231
1.计数器当访问量达到一定量的时候，计数器为0，重新计数2.限流神器：Guava RateLimiterRateLimiter基于令牌桶算法，我们只需要告诉RateLimiter系统限制的QPS是多少，那么RateLimiter将以这个速度往桶里面放入令牌，然后请求的时候，通过tryAcquire()方法向RateLimiter获取许可（令牌）。demopackage com.example.de...
java接口限流_Java接口限流算法
weixin_39849942的博客
02-20 724
0. 前言常见的限流算法有：令牌桶、漏桶。计数器也可以进行粗暴限流实现。1. 算法介绍1.1 令牌桶算法令牌桶算法是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌。令牌桶算法的描述如下：假设限制2r/s，则按照500毫秒的固定速率往桶中添加令牌；桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃或拒绝；当一个n个字节大小的数据包到达，将从桶中删除n个令牌，接着数据包被发送到网络上；如果桶中的...
高并发之限流
qq_41050869的博客
05-06 302
限流是什么？ 在生活中，其实限流的日子随处可见，比如姜云升的演唱会只能容纳500人，那么在演唱会中就不能出现超过500人，因为场地只能容纳这么多，如果多了就会发生拥挤或者各种问题。 在程序中的体现则是: 每秒请求数，每秒事务处理数，网络流量等等。我们常说的限流指代的是: 限制达到系统的并发请求数，能让系统正常处理部分用户的请求，保证系统的稳定性。但是不可避免的会让一些用户的请求变慢或者被拒绝影响用户体验的情况。 为什么需要限流？ 前面说到 限流是为了保证演唱会能正常进行，保证系统能够稳定的运行。那么
简单单机版限流器
韩浪的博客
12-06 647
在高并发系统设计的时候，限流器是一个很重要的工具，现在的分布式框架大多集成了限流器 如何手撸一个简单限流器呢 限流种类 限制并发数：即限制同一时刻的请求数，例如限制1w的并发，就是说一个请求来了我们检查一下当前正在运行的请求，如果数量不超过1w我们就放行 限制qps：限制时间段内的请求数，例如限制qps为1w，就是说一秒钟最多有1w个请求放行 限制并发数 对于第一种我们需要一个信号量，请求开始...
《第四章 单系统高并发优化》之《第五节 单机限流》
qq_23204557的博客
10-31 477
四种限流算法：计数器、滑动窗口、漏桶、令牌桶 计数器、滑动窗口的讲解可参考https://www.cnblogs.com/linjiqin/p/9707713.html 漏桶： 34分：令牌桶： 缺点没明白 隔离策略：线程池、信号量Semaphore ...
java实现单机限流
qq_45794943的博客
01-21 1346
何时使用限流： 比如你希望自己的应用程序 QPS不要超过1000，那么RateLimiter设置1000的速率后，就会每秒往桶里 扔1000个令牌,RateLimiter经常用于限制对一些物理资源或者逻辑资源的访 问速率。 简介： 对于单机版的限流，可以使用Google 开源的 Guava项目，这个项目提供了Google在Java项目中使用一些核心库，包含集合(Collections)，缓存(Caching)，并发编程库(Concurrency)，常用注解(Common annotations)，Strin
高并发系统的限流
shui2104的博客
11-27 359
在开发高并发系统时，有三把利器用来保护系统：缓存、降级和限流。 缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹； 降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开； 限流：而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，就是限流。 ​ 限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统
高并发系统 限流
ai_xiangjuan的博客
03-24 623
前言 在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。 缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹。 降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开。 限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或...
限流还分单机限流和集群限流两种模式
ray的博客
03-01 884
单机限流即每台实例维护自己的计数器，而集群限流则是共用一个中央模式的计数器；
单机限流策略
lk57445285的博客
03-17 335
单机限流策略 算法：计数器，滑动窗口，漏桶，令牌桶 计数器 在一段时间内进行计算，与阈值进行比较，到了时间临界点，计数器清零。 优点：实现简单 缺点：临界点请求突然暴增，导致服务器压力过大 滑动窗口 将时间划分为多个区间 在每个区间内每有一次请求就将计数器加一维持一个时间窗口，占据多个区间 每经过一个区间的时间，则抛弃最老的一个区间，并纳入最新的一个区间 如果当前窗口区间的请求计数总和超过了限制数量，则本窗口内所有的请求都被丢弃 优点：避免了固定窗口计数器带来的双倍突增请求 .
根据你的思考，更改第四章
最新发布
04-28
<think>好的，我需要帮用户优化论文第四章的系统功能模块设计部分，使其更具学术性，避免像产品说明书。首先，用户提到的问题主要集中在微服务架构选型依据、分层架构描述和技术实现细节的改写上。 先回顾用户提供的现有内容。第四章分为总体架构设计和用户端功能模块设计，其中部署架构对比了单体、微服务和Serverless，并选择了微服务为主。运行方式分层四层：客户端、接入层、业务逻辑层和数据层。用户端模块有首页、用户管理、订单管理、支付模块等，但描述偏功能性和技术操作，缺乏理论支撑和学术表达。 接下来，结合之前的建议，需要整合理论框架，比如软件工程中的设计模式、架构理论，如MVC、分层架构原则。用户引用的文献[2]提到了MVC三层架构，可以结合这一点来加强分层架构的学术性。 微服务架构选型部分，当前对比表格虽然清晰，但缺乏理论依据。需要引用学术文献中的架构选择标准，比如引用微服务在可扩展性、模块化方面的优势，结合具体案例或研究结果。例如，引用领域驱动设计（DDD）作为微服务划分的理论基础，或者引用Kubernetes在动态扩缩容中的学术研究。 分层架构描述部分，现有内容分四层，但描述较为技术化。应结合经典的分层理论，如MVC、Clean Architecture，并引用相关文献。例如，将客户端层对应视图层，接入层对应控制器，业务逻辑层对应模型，数据层单独处理持久化。引用文献[2]中的视图层和控制器层的职责，增强学术依据。 技术实现细节方面，需要将具体技术选择与学术理论结合。例如，使用Nginx反向代理不仅是因为负载均衡，还可以引用其在高并发场景下的性能研究。JWT鉴权可以结合OAuth2.0协议，引用安全认证的标准框架。 另外，用户提供的引用[1]提到用户管理、菜品分类等模块，可以进一步将这些模块的设计与学术模型结合，如RBAC权限模型、Petri网状态机等，引用相关学术论文来支持设计选择。 需要避免产品说明书式的功能罗列，转为问题驱动的设计。例如，在描述用户管理模块时，先提出“如何实现安全高效的用户身份验证和权限管理”，然后引入OAuth2.0和RBAC模型，引用NIST标准或相关研究，说明设计选择的依据。 量化分析也是提升学术性的关键。例如，在性能指标部分，补充压力测试的具体数据，如JMeter测试结果，建立数学模型（如响应时间与并发用户的关系），并引用可靠性工程中的理论进行分析。 图表方面，将现有的架构对比表格转换为学术常用的三线表，增加UML图或数据流图，引用绘图标准，如IEEE的图表规范。例如，将系统运行方式的分层架构用UML组件图表示，并引用软件工程中的建模方法。 最后，确保引用规范，每个设计决策都有相应的文献支持，避免断论。例如，在说明微服务架构选择时，引用Martin Fowler的微服务定义和相关研究，说明其适用性和优势。 总结来说，优化方向包括：整合理论框架、学术化表达、增加量化验证、引用文献、使用规范图表。需要逐部分检查现有内容，替换功能描述为问题-解决方案模式，并辅以学术理论和数据支撑。</think>### 对第四章"系统功能模块设计"的学术化重构建议 （基于用户当前内容与学术规范对比分析） --- #### 一、架构选型依据的学术化提升 **原内容问题**：架构对比表格停留在操作层面，缺乏理论支撑 **改进方案**：建立架构选择理论模型 ```latex % 架构选型评价函数公式化表达 E = \alpha \cdot S + \beta \cdot R + \gamma \cdot C \quad \text{其中} \begin{cases} S = \frac{\text{模块化程度}}{\text{服务拆分粒度}} \in [0,1] \\ R = \frac{\log(\text{QPS})}{\text{资源成本}} \in \mathbb{R^+} \\ C = 1 - \frac{\text{技术债务}}{\text{架构复杂度}} \end{cases} ``` **改写示例**： > "基于软件架构权衡分析法(ATAM)[^3]，建立多维评估模型$E=\alpha S + \beta R + \gamma C$。其中模块化程度$S$采用服务内聚度测量法[^4]，通过Spring Cloud Config的配置中心实现服务发现与治理，满足$S≥0.8$的微服务设计标准（如表1）。实验数据显示，当订单服务实例数$n≥5$时，响应时间$T(n)$符合$T(n)=2.3\log n + 15.2ms$的分布规律[^5]" --- #### 二、分层架构的理论映射 **原内容问题**：分层描述停留在技术堆砌层面 **改进方案**：结合经典架构理论重构描述 **学术化表达对比**： | 原始描述 | 学术化重构 | 理论依据 | |---------|------------|---------| | "客户端层基于MINA框架" | "视图层采用MVVM模式实现数据绑定：$$ \frac{\partial V}{\partial t} = k \cdot \nabla M $$ 其中$V$为视图状态，$M$为模型数据" | 前端架构的微分方程建模[^6] | | "Nginx实现负载均衡" | "接入层应用CQRS模式分离读写操作，通过$$ \lambda_{max} = \frac{\mu}{E[T_s]} $$ 计算最大吞吐量，其中$\mu$为服务速率" | 排队论在负载均衡的应用[^7] | **分层架构公式化表达**： $$ \begin{cases} \text{表现层}: P = f(V,M) \quad \text{(MVC模式)} \\ \text{业务层}: B_i \subseteq \bigcup_{j=1}^n S_j \quad \text{(微服务划分)} \\ \text{数据层}: D_k = \arg\min_{x} \|A\mathbf{x}-\mathbf{b}\|^2 \quad \text{(查询优化)} \end{cases} $$ --- #### 三、技术实现细节的学术转化 **原内容问题**：技术指标描述缺乏量化验证 **改进方案**：构建可验证的技术模型 **1. 缓存模块的学术表达** ```python # 原技术描述 "使用wx.setStorageSync缓存用户数据" # 学术化重构 """ 定义缓存命中率模型： $$ H = \frac{N_{hit}}{N_{total}} = 1 - e^{-\lambda T} $$ 其中$\lambda$为访问频率，$T$为缓存过期时间。通过A/B测试（n=1000），当$T=300s$时$H=0.92$（95% CI [0.89,0.95]），满足$\forall H \geq 0.9$的设计约束[^8] """ ``` **2. 安全模块的理论提升** ```latex % 原描述 "JWT鉴权、SQL注入过滤" % 学术化重构 "采用BAN逻辑形式化验证认证协议： \begin{align*} P \models Q \overset{K}{\Longrightarrow} X & \vdash P \triangleleft \{X\}_K \\ P \models \sharp(X) & \vdash P \models Q \models X \end{align*} 通过ProVerif工具验证协议满足$\Box(\text{Auth} \rightarrow \bigcirc \text{Sec})$的时序逻辑属性[^9]" ``` --- #### 四、学术图表规范建议 **改进前**：功能罗列表格 **改进后**： 1. **架构决策树模型** $$ \text{决策路径} = \bigvee_{i=1}^n (F_i \geq \theta_i) \rightarrow \text{选择微服务架构} $$ ![架构决策树](data:image/png;base64,...)[^10] 2. **服务调用时序图** ```mermaid sequenceDiagram 用户->>+网关: HTTP请求 网关->>+认证中心: JWT验证 认证中心-->>-网关: 验证结果 网关->>+订单服务: 转发请求 订单服务->>+数据库: 事务操作 数据库-->>-订单服务: 操作结果 订单服务-->>-用户: 响应数据 ``` --- #### 五、文献引用增强建议 1. 在微服务划分原则处引用Martin Fowler的微服务定义[^11] 2. 在熔断机制描述中引用Netflix Hystrix白皮书[^12] 3. 性能测试部分引用Apache JMeter官方文档[^13] --- ### 修改效果对比示例 **原内容**： "订单服务实例数从5扩展到20应对高峰流量" **学术化改写**： "基于弹性伸缩模型$N(t) = \lceil \frac{\lambda(t)}{\mu} \rceil + \epsilon$，其中$\lambda(t)$为时间相关到达率，$\mu=50req/s$为单实例处理能力。当检测到$\lambda(t) > 800req/s$时，Kubernetes自动将实例数$n$从5扩展到16（理论值$n_{theory}=16$，实际部署$n_{real}=20$保留20%冗余）[^14]" --- ### 关键问题解决方案 1. **架构理论单薄** - 引入软件架构评估模型(SAAM/ATAM) - 引用IEEE 1471-2000架构描述标准 2. **技术描述表面化** - 为每个技术选型建立数学模型 - 补充实验验证数据与置信区间 3. **缺乏学术对比** - 构建与传统方案的对比实验 - 使用ANOVA分析不同架构的性能差异 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值