对高并发流量控制的一点思考 推荐 原创 zfz_linux_boy 2018-01-30 10:01:59 博主文章分类:Java ©著作权 文章标签 高并发 流量控制 流量控制 文章分类 软件研发 ©著作权归作者所有:来自51CTO博客作者zfz_linux_boy的原创作品,请联系作者获取转载授权,否则将追究法律责任 前言 在实际项目中,曾经遭遇过线上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获取许可(令牌)。 分布式场景下的限流 **上面所说的限流的一些方式,都是针对单机而言的,其实大部分的场景,单机的限流已经足够了。分布式下限流的手段常常需要多种技术相结合,比如Nginx+Lua,Redis+Lua等去做。本文主要讨论的是单机的限流,这里就不在详细介绍分布式场景下的限流了。 ** **一句话,让系统的流量,先到队列中排队、限流,不要让流量直接打到系统上。 ** 赞 收藏 评论 分享 举报 上一篇:程序员不可不知的Linux性能工具 下一篇:透彻理解Spring事务设计思想之手写实现 提问和评论都可以,用心的回复会被更多人看到 评论 发布评论 全部评论 () 最热 最新 相关文章 精确掌控并发:固定时间窗口算法在分布式环境下并发流量控制的设计与实现 主要介绍分布式场景下常用的并发流量控制方案,包括固定时间窗口、滑动时间窗口、漏桶、令牌桶、分布式消息中间件等,并重点讲清楚固定时间窗口应用原理和应用场景,以及使用reids实现的核心代码。 限流 redis 流量控制 分布式流量限流 想设计一个高并发的消息中间件前,先熟悉一下这些知识点 要想设计一个具有高并发的消息中间件,那么首先就要了解下消息中间件涉及哪些具体的知识点。 数据 消息中间件 分布式架构 hbase 高并发分析 随着大数据时代的到来,HBase作为一种高可靠、高性能、面向列、可伸缩的分布式存储系统,广泛应用于大数据领域。在实际应用中,HBase经常需要处理高并发的读写请求,因此对其高并发性能的分析和优化显得尤为重要。本文将深入探讨HBase的高并发机制、性能瓶颈以及优化策略,并结合实际代码示例进行说明。HBase高并发机制HBase的高并发机制主要依赖于其底层的分布式架构和存储设计。HBase通过将数据分 数据 高并发 性能瓶颈 高并发流量控制策略 前言应对大流量的成了系统的压力,影响了系统的性能,. 分布式 限流 滑动窗口 代码实现 面试被问高并发流量控制,我脸都绿了。。。 应对大流量的一些思路限流的常用方式限流神器:Guava RateLimiter分布式场景下的限流前言在实 限流 滑动窗口 代码实现 面试被问高并发流量控制,我脸都绿了... 重磅。。。 限流 滑动窗口 代码实现 【152期】如何应对高并发流量? 前言应对大流量的一些思路限流的常用方式限流神器:Guava RateLimiter分布式场景下的限流前言在实际项目中,曾经遭遇过线上5W+QPS的峰值,也在压测状态下经历过10W+QPS的大流量请求,本篇博客的话题主要就是自己对高并发流量控制的一点思考。应对大流量的一些思路“首先,我们来说一下什么是大流量?大流量,我们很可能会冒出:TPS(每秒事务量),QPS(每秒请求量),1W+,5W+,10W JAVA k8s高并发流量 **Kubernetes高并发流量处理流程**当我们在使用Kubernetes部署应用程序时,我们通常要面对高并发流量的情况。为了应对这种情况,我们需要做一些配置和优化。下面我将介绍Kubernetes处理高并发流量的步骤,并提供相应的代码示例。**步骤**| 步骤 | 操作 || ----- | ----- || 1 | 部署应用程序到Kubernetes集群中 || 2 | 应用程序 Deployment 高并发 对性能优化的一点思考 说到数据库性能优化,大家都能说上来N条注意事项。可真正运用的时候往往会忽略这方面的内容。当时有时候可能是由于要的比较急,容不得多想。但磨刀不误砍柴工。下面是一个我刚近遇到的一个例子。希望大家可以重视下这方面的内容。原因:公司要对某系统数据进行审核。于是得到任务,从数据库中提取出某一日的相关数据,及当日及其后第一日,第三日,第五日,第十日等的相应收盘价。分析:收盘价放在ji 职场 休闲 性能优化 对缓存击穿的一点思考 前言缓存(内存orMemcachedorRedis.....)在互联网项目中广泛应用,本篇博客将讨论下缓存击穿这一个话题,涵盖缓存击穿的现象、解决的思路、以及通过代码抽象方式来处理缓存击穿。什么是缓存击穿?上面的代码,是一个典型的写法:当查询的时候,先从Redis集群中取,如果没有,那么再从DB中查询并设置到Redis集群中。注意,在实际开发中,我们一般在缓存中,存储的数据结构是JSON。(JDK 缓存击穿 一点思考 51CTO 高并发下资源池资源申请一点思考 昨天在看Cache Client代码的时候,发现在从资源池中获取SocketIO部分代码在高并发情况下效率不高,因此考虑通过一些变通的方式来提高效率,下面说的内容仅仅是当前自己琢磨出来可以部分提高效率的方法,希望看了这篇文章的同学能够有更好的方式或者算法来提高效率。 情景: Cache Client 的SocketIO 职场 休闲 集群架构 一点思考 现在要做两件事情1,稳下自己的情绪不要太急。2,明确下前进路线并做好规划稳步前进有时候很难控制住自己急躁的情绪,很难静下心来专心做一件事情,思绪漂泊不定会想很多问题,能不能找一份理想的工作,能不能多挣点钱,能不能在职业生涯上有所建树,如果2年以后5以后工作没有进展,生活安逸,平淡无奇....这是无法让人接受的,必须前进!一直以来我都是跟着别人的步伐前进,我想我应该有自己要走,我要走 一点思考 如何处理网站高并发流量问题 很多平台一旦做大了,平台的流量就会陡增,同时并发访问的流量也会暴增,原本规划的硬件配置就无法满足当下的流量问题。 那么如何处理好高并发的流量问题呢? 小编将这些分为2个方面:架构层面和网站本地项目层面。 一、架构层面 1、硬件升级 假设一台服务器最多能支持每天10万独立IP,如果访问量增大的话,那么 高并发 对wide stripe技术的一点思考 RAID技术发展到现在遇到了应用瓶颈,其最大的问题在于数据重构时间过长。在漫长的数据重构过程中,多块盘损坏的概率很高。对于RAID6而言,如果第三块盘损坏,那么数据将会彻底丢失。在数据重构过程中,应用数据和重构数据相互竞争有限的IO带宽,导致数据重构时间进一步增加,数据安全性受到严重挑战。面对RAID这样的问题,业内一直在思考我们RAID的技术是否已经走到了历史的尽头。笔者曾经也分析过,业内的很多 总结 RAID stripe wide 高并发流量控制 以前没关注过,这里只学的是单机的处理方式。 1.什么是大流量 大流量,我们很可能会冒出:TPS(每秒事务量),QPS(每秒请求量),1W+,5W+,10W+,100W+...。 其实并没有一个绝对的数字,如果这个量造成了系统的压力,影响了系统的性能,那么这个量就可以称之为大流量了。 2.应对大流量常 限流 滑动窗口 缓存 数据 时间片 lua流量控制 流量控制网络 一、流量控制 当AB两台设备在发送数据,如果A设备有较高的发送速度,而B设备只有较低的接收速度,那么就会造成不匹配,容易造成传输错误,因此就需要流量控制。这种情况一般是由于B设备的缓冲区溢出而造成的。 流量控制不止是链路层具备的功能,传输层也具备相应的功能。下面是链路层流量控制与传输层流量控制的区别:数据链路层的流量控制是点对点的,而传输层的流量控制是端到端的。不回复确认帧。传输层的流量控制手 lua流量控制 滑动窗口 流量控制 重传 axios流量控制 osi 流量控制 OSI(开放系统)模型是一组协议的集合,它使得两个不同的系统之间能够互相通信,分为七层第一层:物理层物理层负责把逐个的比特(01)从一个节点移动到下个节点具体体现在如何把比特转换成电或者光信号、线路配置、数据传输速率、物理拓扑、传输方式等第二层:数据链路层它把网络层收到的比特流划分成可以处理的数据单元:帧物理编址:在帧的首部指明发送源地址和目的地址(MAC)流量控制:防止接受方的超负荷而无法工作差 axios流量控制 网络层 表示层 编址 java udp 流量控制 udp的流量控制 TCP和UDP区别:TCP面向连接,UDP不面向连接TCP三次握手:1.客户端发送同步序列编号(SYN)包到服务器,进入syn_send状态,等待服务器确认;2.服务器收到syn包,必须确认客户的syn包即ack,同时自己也发送一个syn包,此时服务器进入syn_recv状态;3.客户端收到服务器的syn+ack包,向服务器发送确认包(ack),完成三次握手。TCP四次挥手: TCP流量 java udp 流量控制 TCP 服务器 拥塞控制 对ThreadLocal实现原理的一点思考 前言 在《透彻理解Spring事务设计思想之手写实现》中,已经向大家揭示了Spring就是利用ThreadLocal来实现一个线程中的Connection是同一个,从而保证了事务。本篇博客将带大家来深入分析ThreadLocal的实现原理。 ThreadLocal是什么、有什么、能做什么? Thre 强引用 内存泄露 弱引用 局部变量 成员变量 对扩展openflow协议的一点思考 软件定义X变得越来越火,正所谓,Software is eating the world。软件定义网络也是如此。不论是在工业界还是学术界都将是一次伟大的革命,都在紧随着这个行业的方向,找自己的研究点,关注着标准化的进展。各种Controller,原型系统都相继出现,还有的是是做SDN 的Debug,安全,总之让这个生态系统变得更加健壮。尽管南向接口标准非常多,可是openflow适合我们 控制流 通信协议 Javascript 软件定义网络