剖析暴增流量下的限流算法和最强哨兵Sentinel

剖析暴增流量下的限流算法和最强哨兵Sentinel

场景描述

在复杂的生产环境下可能部署着成千上万的服务实例，当流量持续不断地涌入，服务之间相互调用频率陡增时，会产生系统负载过高、网络延迟，硬件负荷过载等一系列问题，从而导致某些服务不可用。如果不进行相应的流量控制，可能会导致级联故障，并影响到服务的可用性，因此如何对高流量请求进行合理控制，成为保障服务稳定性的关键。限流可通过对某一时间窗口内的请求数进行限制,保持系统的可用性和稳定性,防止因流量暴增而导致的系统运行缓慢或宕机。

流量激增，常见策略是什么？

缓存为客户端（浏览器，app等），代理服务，后台服务，数据库等设定缓存。对频繁读的数据尽可能的从前端到后端进行合理的数据缓存。类型的缓存功能描述及常用技术举例：

 

 

降级系统中的非核心服务，如果遇到流量过大的情况，那么就把这个服务降级掉。例如：当获取数据列表，然后对数据进行排序展示，如果在大流量下，这个排序就可以降级掉。

传输数据传输过程中可以对数据进行压缩处理，从而减少网络带宽。

规则请求访问过程中可以通过防火墙，请求代理服务，前后端业务逻辑设定访问规则进行安全控制，过滤掉非法数据请求。如访问时段，请求url，IP黑白名单等规则设定。

限流限流控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统稳定性角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。在一定时间内把请求限制在一定范围内，保证系统不被冲垮，同时尽可能提升系统的吞吐量。这种限流方式的控制如同人们生活中经常遇到的，早晚高峰地铁站通过排大长龙进站乘车达到限流的目的，为了保证地铁站不会因为突然的客流高峰而被冲垮，而中断正常的运营。

有些时候，缓存、降级、压缩等只能解决系统运营中流量的一部分问题，但是不能解决核心的应用服务之间流量控制的问题。例如，即将到来第十个天猫双十一狂欢节，用户的购买，支付等行为，是涉及到大量写操作，且是核心链路服务。类似这样的核心操作服务是无法通过降级来达到提高系统服务运营稳定性的，这个时候，限流就比较重要了。

常见的限流算法

计数器算法计数器算法指在一段时间内，进行计数，与阀值进行比较，如果超过了阀值则进行限流操作，到了时间临界点，将计数器清零进行重新基数，即单位时间段内可访问请求的次数进行控制。计数器算法是一种比直观简单的限流算法，常用于应用服务对外提供的接口层面。

 

由于计数器算法存在时间临界点缺陷，因此在时间临界点左右的极短时间段内容易遭到攻击。比如设定每分钟最多可以请求100次某个接口，如12:00:00-12:00:59时间段内没有数据请求，而12:00:59-12:01:00时间段内突然并发100次请求，而紧接着跨入下一个计数周期，计数器清零，在12:01:00-12:01:01内又有100次请求。那么也就是说在时间临界点左右可能同时有2倍的阀进行请求，从而造成后台处理请求过载的情况，导致系统运营能力不足，甚至导致系统崩溃。

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

 

滑动窗口算法可以有效的规避计数器算法中时间临界点的问题，但是仍然存在时间片段的概念。同时滑动窗口算法计数运算也相对计数器算法比较耗时。时间片段越精确，流量控制越精密，从而导致计算耗时越长。

漏桶算法漏桶算法设计思路比较直观简单,即水(请求)以不确定的速率先进入到漏桶里,然后漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。因此漏桶算法在这方面比滑动窗口而言，更加先进。

 

漏桶算法需要设定两个参数，一个是桶的容量大小用，用来决定最多可以存放多少水（请求），一个是水桶漏的大小，即出水速率，即出水速率决定单位时间向服务器请求的平均次数。因此漏桶算法存在如下两个问题：

漏桶的漏出速率是固定的参数，所以即使网络中不存在资源冲突(没有发生拥塞),漏桶算法也不能使流突发到端口速率提高。因此漏桶算法对于存在突发特性的流量来说缺乏效率。漏桶的漏出速率是固定的参数同时水桶容量大小限制，那么意味着如果瞬时流量增大且超过水桶水桶容量的话，将有部分请求被丢弃掉（也就是所谓的溢出）。

令牌桶算法令牌桶算法是和水桶算法效果一样但方向相反的算法。随着时间流逝,系统会按恒定时间间隔往桶里加入制定数量的水，如每100毫秒往桶里加入1000毫升的水，如果桶已经满了就不再加了（说明：令牌桶算法和漏桶算法相反，漏桶算法是按照客户请求的数量往漏桶中加水的，而令牌桶算法是服务器端控制往桶里加水的）。当有新请求来临时,会各自从桶里拿走一个令牌,如果没有令牌可拿了就阻塞或者拒绝服务。

 

 

令牌桶算法的优点如下：

服务器端可以根据实际服务性能和时间段改变改变生成令牌的速度和水桶的容量。 一旦需要提高速率,则按需提高放入桶中的令牌的速率。生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味着当面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。算法总计：以上四种算法均可以达到流量控制的目的，不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量，这是符合设计规范和运营需求且合理的算法。如因极少部分流量需要保证可能导致系统达到极限而挂掉，则得不偿失。

Sentinel限流产品介绍

Sentinel 译为哨兵。这个命名形象的诠释了Sentinel在分布式系统中的工作角色和重要性。Sentinel 是面向分布式服务架构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护、监控管理等多个维度来帮助保护服务的稳定性。，这个命名形象的诠释了Sentinel在分布式系统中的工作角色和重要性。Sentinel作为一个调配器，可以根据需要把随机的请求调整成合适的形状，如下图所示：

 

 

 

Sentinel具有以下特征:

· 丰富的应用场景：Sentinel承接了阿里巴巴近10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、实时熔断下游不可用应用等。

· 完备的实时监控：Sentinel同时提供实时的监控功能。可以在控制台中看到接入应用的单台机器秒级数据，甚至500 台以下规模的集群的汇总运行情况。

· 广泛的开源生态：Sentinel提供开箱即用的与其它开源框架/库的整合模块，例如与Spring Cloud、Dubbo、gRPC 的整合。只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。

· 完善的SPI 扩展点：Sentinel 提供简单易用、完善的SPI 扩展点。可以通过实现扩展点，快速的定制逻辑。例如定制规则管理、适配数据源等。

Sentinel功能介绍

· 流量控制：同一个资源可以对应多条限流规则。FlowSlot 会对该资源的所有限流规则依次遍历，直到有规则触发限流或者所有规则遍历完毕。流量控制方式有基于QPS/并发数的流量控制、基于调用关系的流量控制（根据调用方限流、根据关系的资源流量控制，根据调用链路入口限流等）。

· 熔断降级：熔断降级是指当资源处于不稳定的情况下，在接下来的时间窗口之内，对该资源的调用都自动熔断。通常用平均响应时间和异常比例两种方式来衡量资源是否处于稳定的状态即。

· 热点参数限流：热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。Sentinel 利用LRU 策略，结合底层的滑动窗口机制来实现热点参数统计。LRU 策略可以统计单位时间内，最近最常访问的热点参数，而滑动窗口机制可以帮助统计每个参数的QPS。

 

 

· 系统负载保护：当系统负载高于某个阈值，就禁止或者减少流量的进入；当系统负载开始好转，则恢复流量的进入。

· 黑白名单控制：黑白名单根据资源的请求来源限制资源是否通过，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。

· 实时监控：实时监控可根据系统提供的秒级日志记录实现包含单点监控，链路监控，簇点监控。

· 控制台：Sentinel提供一个轻量级的控制台，它提供机器发现、单机资源实时监控、集群资源汇总，以及规则管理的功能。

 

Sentinel 的开源生态

Sentinel提供对Web Servlet，Dubbo，Spring Boot ，Spring Cloud，gRPC，Apache RocketMQ，Redis等集成支持。

 

 

总结

在项目设计开发和运营中难免会遇到大流量访问的情况，除了参考当应对大流量常用策略优化之外，还应考虑到应用服务本身流量的控制和监控。比如微服务架构模式下可针对性的某些特定服务之间进行流量控制和监控，实时了解系统运营和稳定情况，动态增减服务节点，从而提高系统的稳定性和健壮性，进而为用户提供更高质量的服务。