网站开发项目总结范文,企业网站导航设计,百度收录查询工具,做 爱 网站小视频前言 在实际项目中#xff0c;曾经遭遇过线上5WQPS的峰值#xff0c;也在压测状态下经历过10WQPS的大流量请求#xff0c;本篇博客的话题主要就是自己对高并发流量控制的一点思考。 应对大流量的一些思路 首先#xff0c;我们来说一下什么是大流量#xff1f; 大流量… 前言 在实际项目中曾经遭遇过线上5WQPS的峰值也在压测状态下经历过10WQPS的大流量请求本篇博客的话题主要就是自己对高并发流量控制的一点思考。 应对大流量的一些思路 首先我们来说一下什么是大流量 大流量我们很可能会冒出TPS每秒事务量QPS每秒请求量1W5W10W100W...。其实并没有一个绝对的数字如果这个量造成了系统的压力影响了系统的性能那么这个量就可以称之为大流量了。 其次应对大流量的一些常见手段是什么 缓存说白了就是让数据尽早进入缓存离程序近一点不要大量频繁的访问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获取许可令牌。 分布式场景下的限流 上面所说的限流的一些方式都是针对单机而言的其实大部分的场景单机的限流已经足够了。分布式下限流的手段常常需要多种技术相结合比如NginxLuaRedisLua等去做。本文主要讨论的是单机的限流这里就不在详细介绍分布式场景下的限流了。一句话让系统的流量先到队列中排队、限流不要让流量直接打到系统上。 本文转自zfz_linux_boy 51CTO博客原文链接http://blog.51cto.com/zhangfengzhe/2066683如需转载请自行联系原作者
