分布式限流Sentinel

众所周知，互联网电商的各类活动是越来越多，例如削减男同胞钱包厚度的双十一、618、双十二、各类秒杀活动等，几乎所有的互联网电商企业都会参与其中，冲击GMV，会电商平台带来巨大的流量与可观的利润。

作为互联网电商中的一员，我自己所属的公司虽然远比不上淘宝、京东等，但作为社交电商领域的领头羊，我们在上述对于电商企业及其特殊的日子，流量也是不容小觑的。

好了，让我们进入这期的主题。例如在双十一、或者周年庆等这种特殊的日子，当12点刚到那一刻，巨大的用户流量涌入你们的系统，访问量突然剧增时，我们是如何保证系统的可用性、稳定性。我们的解决方案主要是通过Sentinel的限流、降级、熔断（增加服务器数量就不说了）以及消息中间件的削峰（我会专门写一期关于消息中间件的文章，到时候大家可以看看）。没错，本期的主角出现了，他就是 Sentinel ，阿里开源的面向分布式服务框架的轻量级流量控制框架。官网如下: https://github.com/alibaba/Sentinel

以下是另一个开源的流量控制框架 hystrix 与Sentinel的对比

分布式系统中，限流的资源可以是一个http接口，也可使是某个分布式应用中的API；一般我们针对C端的http接口进行限流，针对API进行熔断降级。

限制请求的数量，限制某段时间内的请求总量对于超出的总量的请求，可以直接拒绝，也可以在请求的时候对请求分组，允许特殊请求进来，剩下的拒绝，也可以放入消息队列，削峰填谷。

限流的实现方式：

服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。例如：当双11活动时，把无关交易的服务统统降级，如查看历史订单、工单等等。

在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务。如果调用链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“ 雪崩效应 ”。

熔断机制是应对雪崩效应的一种微服务链路保护机制 。服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。熔段解决如下几个问题：

本源码解析以限流为例，降级具体实现可自行参考源码 Sentinel采用滑动窗口算法来实现限流的。限流的直接表现是在执行 Entry nodeA = SphU.entry(资源名字) 的时候抛出 FlowException 异常。FlowException 是BlockException 的子类，您可以捕捉 BlockException 来自定义被限流之后的处理逻辑。

由上可知，会先初始化一个限流规则，initFlowRule方法中将创建一个限流规则FlowRule对象，主要限流参数如下

并设置其相应的限流规则属性，最后通过FlowRuleManager.loadRules(rules)加载限流规则。

限流规则初始化之后，通过entry= SphU.entry(resource)触发内部初始化。

从 SphU.entry() 方法往下执行会进入到 Sph.entry() ，Sph的默认实现类是 CtSph,而最终会进入CtSph 的entry 方法

通过我们给定的资源去封装了一个 StringResourceWrapper ，然后传入自己的重载方法，继而调用 entryWithPriority(resourceWrapper, count, false, args)：

由上述方法可知，主要是为了获取该资源对应的资源处理链，让我们来看下slotChain是如何获取的

当Map缓存中不存在ProcessorSlotChain实例，则具体通过 SlotChainProvider 去构造处理链

继续让我们来看下slotChainBuilder的build方法中做了些什么

我们可以看出上述底层源码是一个标准的责任链设计模式，通过查看ProcessorSlot的具体实现类，我们可以知道该责任链中的具体节点如图所示

执行对应的这些节点，具有有不同的职责，例如:

下图所示是各个slot对应的entry方法的具体实现

我们以StatisticSlot为例，来看看这些具体实现类内部的逻辑是怎样的。

请求通过了sentinel的流控等规则，再通过node.addPassRequest() 将当次请求记录下来

addPassRequest方法如下

addPass方法如下

WindowWrap主要属性如下

我们再看看获取当前窗口的方法 data.currentWindow()

我们再回到

获取到窗口以后通过 wrap.value().addPass(count)增加统计的 QPS。而这里的 wrap.value() 得到的是之前提到的 MetricBucket ，在 Sentinel 中QPS相关数据的统计结果是维护在这个类的 LongAdder[] 中，最终由这个指标来与我们实现设置好的规则进行匹配，查看是否限流，也就是 StatisticSlot的entry 方法中的。在执行StatisticSlot的entry前都要先进入到FlowSlot的entry方法进行限流过滤：

让我们进入checkFlow的内部

再此处我们拿到了设置的 FlowRule ，循环匹配资源进行限流过滤。这就是Sentinel 能做到限流的原因。

我们可以通过Sentinel的客户端查看接入了sentinel的各个系统。可针对系统中的各个资源设置相应的限流规则，如QPS或者线程数；或者设置相应的降级规则，如平均RT，异常比例以及异常数。

高并发常规手段：扩容、静态化、限流、缓存、队列

概要：guava的RateLimit、Nginx + redis + lua、sentinel

生成订单号— 扣库存—生成订单 —付款，扣完库存通知mq，mq没立刻返回，卡在生成订单上， 阻塞

     1）每次 请求获 1个token ， 2s 才可从桶中获取 10个，每秒 只能 5个并发

2）应对突发流量： 一次拿完5个，等1s，因为放5个要1s。

acquire前休眠1s，限流效果变化，因为已经放入足够。

3）从慢速过渡到平均： 设置缓冲时间

1）开启Nginx限流

2）每个 Nginx节点 都 对应 着独立的 redis 节点。

redis节点 存限流配置 ：限流名单、错误码、提示、阈值、开关。

请求来临，Nginx向redis发起evalsha命令，执行lua脚本，验证是否超过阈值：

    （1）目标 url 作为 key ，调用 redis 的 incrby增加访问次数 ， expire设置过期时间

    （2）最后根据 阈值判定走向 ，ps： 阈值到 ，要等 key过期 再 重新计算

轻量级，低侵入，熔断降级

其他：分段秒杀、答题、验证码

mq部分：https://www.jianshu.com/p/886552f434d4

技术这玩意儿，你不深入使用它，你就不知道它有多牛，更不知道会有多难！

并发:指定时间段内的请求数！

高并发:指定时间段内的超多请求数！

比如tomcat，单机最大支持并发数为8000左右，redis理论值可达到几万！

那么怎么设计一套可支持高并发的系统呢？使用技术如下:

1，分布式系统，微服务:使用springcloud家族包括eureka，zuul，feign，hysrix等或者dubbo搭建一套微服务框架！

2，前后端分离:使用node.js搭建前端服务系统！

3，静态化处理:将页面，后台枚举，数据库定义表等使用静态处理方式做处理！

4，文件服务器剥离:采用单独的文件服务器，防止页面加载的阻塞！

5，缓存:使用redis，memcache等将运行时数据缓存，代替频繁的操作数据库！

6，数据库:读写分离或者分库分表，采用druid等有性能监控系统的数据库连接框架！

7，消息中间件:使用xxxmq，kafka等消息中间件，解耦服务，而且异步处理效率更高！

8，反向代理:使用nginx等负载均衡服务！

9，代码层:避免大量创建对象，避免阻塞IO，避免多层for循环，避免线程死锁，避免大量同步！

10，各种优化:包括jvm优化，表结构优化，sql优化，关键字段加索引（注意避免索引失效），连接池优化等等！

11，搜索引擎:sql有大量的like语句，有必要切换成solr等搜索引擎！

12，cdn:使用CDN技术将请求分发到最合适的主机上，避免网络传输的延迟！

13，使用batch:增删改能一次做的别分为两次，但要注意batch合理设计，防止数据丢失！

14，限流，削峰！

大型网站遇到的挑战，主要是大量的用户，高并发的访问，就算一个简单的增删查改的功能，如果面对的是百万、千万甚至亿级的用户，都是一件难度很大的事情。

数据从数据库到浏览器的过程：数据库->应用数据集->内存对象->动态页面->HTTP服务器->用户浏览器。 那么我们可以把高并发的设计分成几个层次：

前端是指，用户的请求还没有到服务前的环节。

系统架构大了，部署的服务器多了，很多事情不可能通过人工完成了，比如一个接口调用发生了错误，不可能人工登录到服务器上去查日志吧，所以这些东西也是必不可少的。

都是说个大概，后面有机会的话，会把每一项都展开详细说明。

希望我的回答能够帮助到你！

我们通过这些架构要素来衡量我们整体系统架构设计的优劣，来判断是否达到了我们的要求。

性能是大型网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题，也正因为性能问题几乎无处不在，在请求链路的任何一个环节，都是我们去做极致性能优化方案中的切入点。

衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。

网站的伸缩性是指不需要改变服务器的硬件设计，仅仅靠改变应用服务器的部署数量，就可以扩大或缩小服务器的处理能力。

网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构的主要目标。

互联网跟传统软件不同，它是开放的，任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。

安全性架构，具体来说说就是保证数据的保密性、完整性、真实性、占有性。

要完全掌握大型网站的架构设计方案，或许你可以点击我头像，进入我的专栏"深入大型网站核心架构实战"。

这期专栏是笔者总结了当下这些互联网行业中相对成熟且经过大型网站检验的技术和方案，内容涵盖构建大型互联网系统服务所需的关键技术。

---