为什么要TCP流量控制？

所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。

TCP流量控制不是为了减少网络压力，那是TCP拥塞控制的作用。

下面简单介绍一下TCP流量控制的目的： 
作用对象：相互连接着的两个终端（发送端与接收端）。 
解决问题：解决发送端与接收方吞吐量不匹配的问题，比如当一个发送端A每秒发10个数据包，而接收端B每秒只能接受1个数据包，那么就会出现丢包的情况，所以发送端与接收端要的吞吐量要匹配。 

目的：让发送端根据接收端的接收能力动态的调整发送速率

如何进行TCP流量控制？

利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。这里采用滑动窗口机制，一是不用每次发送完成都需要等待收到确认消息才能继续发送，二是参考接收端的接收能力，限制发送数据段大小，避免丢失现象。

发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值(可增大或减小)。

接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。

滑动窗口：

发送端已发送了 400 字节的数据，但只收到对前 200 字节数据的确认，同时窗口大小不变。还可发送 300 字节。

发送端收到了对方对前 400 字节数据的确认，但对方通知发送端必须把窗口减小到 400 字节（发送窗口缩小）。现在发送端最多还可发送 400 字节的数据。

发送窗口与接收窗口关系：

TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。

首先介绍TCP流量控制需要的几个变量：

1. LastByteSent ：最后发送的数据包的序号，由发送端进行维护
2. LastByteAck：最后收到的ACK包确认的数据包序号，由发送端进行维护
3. rwnd：接收窗口，由发送方进行维护，表示接收方还有多少空余空间，由接收方发回（与ACK一起？待查）。接收方将其rwnd值放入它发送给发送方的报文段的接收窗口字段中，通知发送方它在该连接的缓存中还有多少可用空间。
4. LastByteRead：由接收方维护，表示应用程序最后从缓存里面读取的数据包的序号
5. RcvBuffer:接收方缓存的最大值
6. LastByteRcvd：从网络中到达的最后一个放入接收缓存的数据包的序号

如果要：要保证不因为溢出而丢包，即保证接收方缓存足以接收即将收到的数据。 
即：LastByteRcvd−LastByteRead≤RcvBuffer

LastByteRcvd−LastByteRead≤RcvBuffer

又：rwnd=RcvBuffer−[LastByteRcvd−LastByteRead]

rwnd=RcvBuffer−[LastByteRcvd−LastByteRead]

要达成TCP流量控制，需要满足下式：将未确认的数据量控制在值rwnd内：LastByteSent−LastByteAck≤rwnd

LastByteSent−LastByteAck≤rwnd

TCP报文段发送时机的选择：

TCP报文段发送时机主要有以下几种选择途径。

1）TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节就组装成一个TCP报文段发送出去。

2）由发送方的应用程序指明要求发送报文段，即TCP支持的推送操作

3）是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段发送出去。

具体是如何进行的？

如图所示，说明了利用可变窗口大小进行流量控制。设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,图中的箭头上面大写ACK，表示首部中的确认为ACK，小写ack表示确认字段的值。

     接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300，第二次减小到rwind=100最后减到rwind=0，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。

     假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

最简单的思路：rwnd=0时咱们不发送了，但这样会存在一个问题，就是如果之后没有ACK，那么连接就相当于断开了。 
所以真正的解决方案是：当rwnd=0时，发送端发送只有一个字节的数据的报文段。这些报文段将会被接收方确认。最终缓存开始清空，并且确认报文里将包含一个非0的rwnd值

如何恢复？

等下一次ACK到来可能rwnd就变大了，到时候就可以发送更多的数据了。

UDP不提供流量控制。

前言

分布式高可靠中的负载均衡的核心在于，将用户请求均匀分配到多个处理服务器处理，以解决单个服务器的单点瓶颈问题。但如果用户请 求数非常多的话，即便实现了负载均衡，服务器能力达到上限，还是无法处理所有的用户请求。

比如，类似双十一、双十二的秒杀场景，用户流量突增时，即使做了负载均衡，仍然会感受到点击抢购时，需要等待较长的时间。这背后的原理是系统控制了用户的请求量。

什么是流量控制？

网络传输中的流量控制，就是让发送方发送数据的速率不要太快，让接收方来得及接收数据，具体的实现方法就是滑动窗口。

滑动窗口：在任意时刻，发送方都维持一个连续的允许发送的数据大小， 称为发送窗口；接收方也会维持一个连续的允许接收的数据大小，称为接收窗口。每次发送方给接收方发送数据后，必须收到接收方返回的确认消息，发送窗口才可向后移动，发送新的数据。

如图所示，发送窗口和接收窗口大小均为 1，发送方发送数据 D1 后，只有接收到来自接收方的确认消息 ACK，发送窗口才可向后移动，即发送方才可以发送后续数据 D2。

在前面提到的双十一、双十二秒杀场景中，用户流量突增，在这种高并发、大流量的情况下，服务器的处理能力成为电商系统的瓶颈，处理不好就会导致系统崩溃，服务不可用。而分布式系统中的流量控制，就是解决这类问题的一种关键技术。

通俗地说，分布式流量控制就是在分布式系统下，控制每个服务器接收的请求数，以保证服务器来得及处理这些请求，尽可能保证用户请求持续地被处理，而不是让大量的用户请求“阻塞”在服务器中，等待被执行。

分布式系统流量控制策略

消息队列就是实现流量控制的一种方法，通过 一个消息队列来存放用户的消息，然后服务器到消息队列中逐个消费，避免消息过多时服务器处理不过来的情况。

除此之外，分布式系统的流量控制策略还有很多，常用的主要包括两种：漏桶策略和令牌桶策略。

漏桶策略

如下图所示，有一个固定容量的水桶，桶底有一个小洞，水桶可以接收任意速率的水流，但无论水桶里有多少水，水从小洞流出的速率始终不变，桶里的水满了之后，水就会溢出。

漏桶策略借鉴上述原理，无论用户请求有多少，无论请求速率有多大，“漏桶”都会接收下来，但从漏桶里出来的请求是固定速率的，保证服务器可以处理得游刃有余。当“漏桶”因为容量限制放不下更多的请求时，就会选择丢弃部分请求。这种思路其实就是一种“宽进严出”的策略。

比如，在某段时间内，系统每秒会有 10 个用户发出请求，但这些请求经过漏桶后，每秒始终只流出 2 个请求，服务器每秒最多处理 2 个请求。无论请求速率有多大，都能达到限流的目的，避免服务器在短暂时间内需要处理大量请求，但由于处理能力受限导致系统崩溃，从而保证了系统的高可靠。

优点：做到了流量整形，即无论流量多大，即便是突发的大流量，输出依旧是 一个稳定的流量。

缺点：对于突发流量的情况，因为服务器处理速度与正常流量的处理速度一致，会丢弃比较多的请求。

当突发大流量到来时，服务器最好能够更快地处理用户请求，这也是分布式系统大多数情况下想要达到的效果。漏桶策略适用于间隔性突发流量且流量不用即时处理的场景，可以在流量较小时的“空闲期”，处理大流量时流入漏桶的流量；不适合流量需要即时处理的场景，突发流量时可以放入桶中，但缺乏效率，始终以固定速率进行处理。

漏桶算法已经用于很多框架了，比如阿里开源的流量控制框架 Sentinel 中的匀速排队限流策略，就采用了漏桶算法；分布式追踪系统 Jaeger 中，有一种采集策略是速率限制类型，内部使用的也是漏桶算法等。

令牌桶策略

令牌桶策略指的是桶里放着很多令牌，请求只有拿到令牌才能被服务器处理。

如图所示，有一个固定容量的存放令牌的桶，以固定速率向桶里放入令牌，桶满时会丢弃多出的令牌。每当请求到来时，必须先到桶里取一个令牌才可被服务器处理，只有拿到了令牌的请求才会被服务器处理。可以将令牌理解为门卡，只有拿到了门卡才能顺利进入房间。

假设，令牌以每秒 3 个的速率放入到令牌桶中，桶的容量为 10。通常情况下， 每秒会有 2 个用户请求，请求到来时就会到桶里取一个令牌，由于请求的速率低于放令牌的速率，因此令牌桶里令牌会逐渐增多，直到达到桶的容量。超过桶容量后，令牌会被丢弃。

当大流量到来时，比如某个时刻来了 10 个请求，此时桶里有 10 个令牌，请求都会被服务器处理；但如果来的请求数不止 10 个，令牌会被取完，多余的请求取不到令牌，也就没办法及时被服务器处理，需要等待令牌。

优点：当有突发大流量时，只要令牌桶里有足够多的令牌，请求就会被迅速执行。通常情况下，令牌桶容量的设置，可以接近服务器处理的极限，可以有效利用服务器的资源。这种策略适用于有突发特性的流量，且流量需要即时处理的场景。

在实际使用中，令牌桶算法也很常见。比如，Google 开源工具包 Guava 提供的限流工具类 RateLimiter，就是基于令牌桶算法来完成限流的。

两种策略对比

Sentinel 流量控制工作原理

Sentinel 的核心是，监控应用的并发线程数或 QPS（请求数 / 每秒）指标，当达到系统设定的阈值时，Sentinel 可以采取一定的策略对流量进行控制，以避免应用被瞬时高流量击垮，从而保证应用高可靠。

在 Sentinel 中，关于流量控制有两种方式：

• 通过并发线程数进行流量控制，
• 通过 QPS 指标进行流量控制。

通过并发线程数进行流量控制：

过多的线程会消耗非常多的系统资源，包括线程资源消耗、线程调度消耗等。为了解决这个问题，引入了线程池。线程池维护了多个启动着的线程，随时等待着去执行系统分配的任务，系统每次需要处理任务时，可以直接从线程池中取线程，从而避免了创建和销毁线程的时间和资源等消耗。

同一时刻每个线程只能执行一个任务或请求，可以通过并发线程数进行流量控制。

如图所示，假设现在线程池中有 3 个线程，最大并发处理数为 3，现在有 2 个请 求 Q1 和 Q2 到来，由于请求数少于线程数，因此请求可以被并发执行。线程池中启动着的线程 1 和线程 2 会进行相应的处理，而不会创建新线程，线程处理完请求后也不会被销毁，而是回到线程池中继续等待新的请求。但如果现在同时有 4 个请求到来，只有 3 个请求可以被并发处理，而剩下的一个请求要么丢弃，要么等待空闲线程。

在分布式系统中，每个请求都会由一个线程去进行处理。当请求太多系统处理不过来时，意味着线程池可能已经被耗尽（线程池中无空闲线程），因此当请求过多时，执行请求的并发线程数自然会随之增加，当超过一定的阈值（比如线程池中线程总数）时，需要采取一定的 策略来进行流量控制。

在 Sentinel 中，就采用了直接拒绝的方式，即新来的请求会直接拒绝。

通过 QPS 指标进行流量控制：

QPS 是指每秒的请求数，大流量也就意味着 QPS 大。当 QPS 达到阈值时，Sentinel 提供 了三种流量控制策略，分别是直接拒绝、预热（Warm Up）和匀速排队：

• 直接拒绝：最直接也是最暴力的方式，与并发线程数流量控制采取的方式一致，当 QPS 达到系统设定的阈值时，直接拒绝新来的请求。 这种策略乍一听起来确实不是很好，但对于系统处理能力确切已知的情况（即阈值设定为每秒能接受的最大处理请求数），却非常实用。当请求超出阈值时，可以直接拒绝，因为系统已经没有更多的能力来处理多余的请求了。因此，该策略适用于对系统处理能力确切已知的场景。
• 预热：当系统的 QPS 长期处于一个较低水平时，一旦发生流量骤增，如果直接让系统每秒处理大量的请求，可能会因为服务器处理能力不足，导致系统崩溃。因此 Sentinel 提供了一种“预热”机制，让系统的 QPS 缓慢增加，在一定的时间内逐渐增加到上限。如下图所示，假设通常情况下系统每秒处理 3 个请求，即 QPS=3，当用户请求增加时，系统每秒处理的请求数相应增加，但不会一下子提高很多。比如，每秒增加 1 个处理请求，逐步达到 QPS=10 的处理上限，并不再继续增加，从而避免大流量一下子导致系统故障。
  
  预热这种策略像是一种特殊的令牌桶：放令牌的速率通常保持在一个较低的水平，当流量突增时，放令牌的速率不会一下子提高到最高水平，而是会慢慢增加，直到增加到最大速率则不可再增加。因此，该策略与令牌桶策略的适用场景类似，即适用于具有突发特性的流量，且流量可以即时处理的场景。
• 匀速排队：本质是漏桶策略。它会严格控制系统每秒处理的请求数，请求数很多时，请求之间的间隔也会保持一致。如图所示，当 QPS=5 时，每隔 200ms 才允许服务器处理下一个请求。假设请求队列中有 10 个请求瞬间到达，服务器不会一下子全处理完，而是按照请求的顺序，每 200ms 处理 一个请求，直到处理完所有请求。处理的请求就像是在匀速排队。

该策略中，系统会设定一个时间间隔 T，假设最大排队时长设置为 6T，上次请求通过的时刻为 t1。当新的请求在 t2 时刻到来的话，则进行判断，首先查看是否还有其他请求在排队。

如果没有请求在排队，分两种情况：

• 当 t2 - t1 的值大于或等于时间间隔 T，请求可以通过；
• 当 t2 - t1 的值小于 T 时，需要等待，直到 t2 - t1 的值达到时间间隔 T 时，才可以让请求通过。

如果已经有请求在排队，就需要计算该新请求的预期通过时间。比如，有 3 个请求在排队，则该新请求预期通过时间为 t1+4T，因为需要等到在该请求前面的请求都通过后该请求才可通过，且两个请求通过的时间间隔必须达到 T 才可以。

若排队的请求过多，新来的请求预期等待时间超出最大排队时长，即等待时间超过 6T 时，则直接拒接这个请求。

匀速排队的适用场景与漏桶策略类似，即适用于间隔性突发流量且流量不用即时处理的场景。

知识扩展：什么是拥塞控制？它与流量控制的区别是什么？

分布式领域，流量控制：指业务上的流量，即用户请求。

分布式领域，拥塞控制：指网络上传输的数据，即网络上数据传输出现拥塞时应当如何控制。

分布式领域中，这两个概念不是 一回事儿。

但是对于网络上数据的传输而言，流量控制与拥塞控制非常容易混淆。

网络数据传输中，流量控制：指控制发送方和接收方的传输和接收速率在双方都可以接受的范围，通常使用的方法是滑动窗口；

网络数据传输中，拥塞控制：通过检测网络状况，随时疏通网络，避免网络中过多数据堆积，导致无法传输数据，包括慢启动与拥塞避免方法。

总结

一、 为什么需要容错设计：

        在分布式系统中，因为使用的机器和服务非常多，所以故障发生的频率会比传统的单体应用更大。只不过，单体应用的故障影响面很大，而分布式系统中由于故障的影响面可以被隔离，所以影响面较小，但是因为机器和服务多，出故障的频率也很多。不过我们需要明白下面这些道理：

• 出现故障不可怕，故障影响面过大才可怕
• 出现故障不可怕，故障恢复时间过长才可怕

        另一方面，因为分布式系统的架构复杂，为了有效对分布式架构进行运维管理，我们会在系统中添加各种监控指标，方便出问题时快速定位。因此有些公司拼命地添加各种监控指标，有的甚至能添加出几万个监控指标，但这样做却给人一种”使蛮力“的感觉，一方面，信息太多就等于没有信息，另一方面，SLA 要求我们定义出核心关键指标。如果只是拼命添加各种监控指标而不定义出关键指标，这其实是一种思维上的惰性。

        另外，上述的措施都是在 “救火阶段” 而不是在 “防火阶段”，所谓 “防火胜于救火”，所以我们更要考虑如何进行防火，这就要求我们在设计或者运维时都要为可能发生的故障考虑，即所谓 “Design for Failure”，面向失败设计，在设计时要考虑如何减轻故障，如果无法避免，也要使用自动化的方式恢复故障，减少故障影响面。而容错设计就是面向失败设计中一个非常重要的环节，常见的容错设计有：

（1）流控：即流量控制，根据流量、并发线程数、响应时间等指标，把随机到来的流量调整成合适的形状，即流量塑性，保证系统在流量突增情况下的可用性，避免系统被瞬时的流量高峰冲垮，一旦达到阈值则进行拒绝服务、排队等降级操作。

（2）熔断：当下游服务发生一定数量的失败后，打开熔断器，后续请求就快速失败。一段时间过后再判断下游服务是否已恢复正常，从而决定是否重置熔断器。

（3）降级：当访问量剧增、服务出现异常或者非核心服务影响到核心流程时，暂时牺牲掉一些东西，以保障整个系统的平稳运行。

（4）隔离：将系统或资源分隔开，保证系统故障时，能限定传播范围和影响范围，防止滚雪球效应，保证只有出问题的服务不可用，服务间的相互不影响。常见的隔离手段：资源隔离、线程隔离、进程隔离、集群隔离、机房隔离、读写隔离、快慢隔离、动静隔离等。

（5）超时：相当多的服务不可用问题，都是客户端超时机制不合理导致的，当服务端发生抖动时，如果超时时间过长，客户端一直处于占用连接等待响应的阶段，耗尽服务端资源，最终导致服务端集群雪崩；如果超时时间设置过短又会造成调用服务未完成而返回，所以一个健康的服务，一定要有超时机制，根据业务场景选择恰当的超时阈值。

（6）幂等：当用户多次请求同一事件时，得到的结果永远是同一个。

二、流控设计：

       限流的目的是通过限制并发访问数或者时间窗口内的请求数，保证系统在流量突增情况下的稳定性，使系统不至于被高流量击垮，一旦达到限制阈值就可以拒绝服务（告知没有资源了或定向到错误页）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。而一般高并发系统常见的限流方式有：

• 限制单位时间的调用量
• 限制系统的总并发数，比如数据库连接池、线程池
• 限制时间窗口内的并发数，比如漏桶和令牌桶

下面我们就讨论各种限流方式的设计与具体应用场景：

1、限制单位时间内的调用量：

        从字面上很容易理解，就是通过一个计数器来统计单位时间内某个服务的访问量。如果超过了阙值，则该单位时间段那不允许继续访问，或者把请求放入队列中等下一个时间段继续访问。需要注意的是计数器在进入下一个单位时间段时需要先清零。

        对于单位时间的设置，第一不能太长，太长将导致限流效果不够“敏感”；第二不能设置得太短，越短的单位时间段将导致阈值越难设置，比如1秒钟，因为高峰期的1秒钟和低峰期的1秒钟的流量有可能相差百倍甚至千倍。最优的单位时间片段应该以阈值设置的难易程度为标准，比如我们的监控系统统计的是服务每分钟的调用量，那我们自然可以选择1分钟作为时间片段，因为我们很容易评估每个服务在高峰期和低峰期的分钟调用量，并可以通过服务在每分钟的平均耗时和异常量来评估服务在不同单位时间段的服务质量。

        当单位时间段和阈值已经确定下来了，接下来就该考虑计数器的实现了，在 Java 中最常用的就是 AtomicLong，每次服务调用时，我们可以通过 AtomicLong.incrementAndGet() 方法来给计数器加1并返回最新值，并通过这个最新值和阈值来进行比较来看该服务单位时间段内是否超过了阈值。对于限制单位时间段内调用量的这种限流方式，实现简单，适用于大多数场景，但是也有一定的局限性，如果设定的阀值在单位时间段内的前几秒就被流量突刺消耗完了，将导致该时间段剩余的时间内该服务“拒绝服务”，这种现象被称为“突刺消耗”。

2、限制系统的总并发数：

        这种方式通过严格限制某服务的并发访问速度，也就限制了该服务单位时间段内的访问量。相比于第一种方案，它有着更严格的限制边界，因为如果采用第一种限流方案，如果大量的服务在极短的时间产生，仍然会压垮系统，甚至雪崩。并发限流一般用于服务资源有严格的限制的场景，比如连接数，线程数等。

        在 Java 中实现，并发限流也非常简单，比如可以使用信号量 Semaphore，在服务调用的入口调用非阻塞方法 Semaphore.tryAcquire() 来尝试获取一个信号量；如果获取失败，则直接返回或将调用放入到某个队列中；当服务执行完成，则使用 Semaphore.release() 来释放资源。

        但这种方式仍然可以造成流量尖刺，即每台服务器上该服务的并发量从 0 上升到阀值是没有任何阻力的，因为并发量考虑的只是服务能力边界的问题。      

3、通过漏桶进行限流：

        漏桶算法有点像我们生活中用到的漏斗，液体倒进去漏斗后从下端小口中以固定速率流出。漏桶算法就是这样，不管流量有多大，漏桶都保证了流量的常速率输出，由于调用的消费速率已经固定，那么当桶的容量堆满时，就只能丢弃了。示意图如下：

         漏桶算法是一种悲观策略，它严格地限制了系统的吞吐量，从某种角度上来说，它的效果和并发量限流很类似。漏桶算法可以用于大多数场景，但是由于它对于服务吞吐量有着严格限制，可能导致某些服务称为瓶颈。

        在 Java 中想要实现一个漏桶算法，可以准备一个队列，当作桶的容量，另外通过一个计划线程池（ScheduledExecutorService）来定期从队列中获取并执行请求调用，可以一次拿多个请求，然后并发执行。

4、通过令牌桶进行限流：

        令牌桶算法可以看成是漏桶算法的一种改进，漏桶算法能够强行限制请求调用的速率，而令牌桶算法能够在限制平均调用速率的同时，允许一定程度的突发调用，实现平滑限流。令牌桶算法中，桶中会有一定数量的令牌，每次请求调用需要去桶中拿取令牌，拿到令牌后才有资格执行，否则必须等待。

        看到这里或许有些疑问，如果把令牌比喻成信号量，那么好像和并发限流没什么区别。其实不是，令牌桶算法的精髓在于拿令牌和放令牌的方式，这和单纯的并发限流有明显的区别：

• 每次请求时需要获取的令牌数不是固定的，比如当桶中的令牌比较多时，每次调用只需要获取一个令牌，随着令牌数的逐渐减少，当令牌使用率（使用中的令牌数/令牌总数）达到某个比率时，可能一次需要获取两个令牌，获取令牌的个数可能还会升高。

• 归还令牌有两种方法，第一种是直接放回，第二种是什么也不做，由另一个额外的令牌生成步骤将令牌允许放回桶中。

         前面讲过，令牌桶允许一定程度的突发调用，那么关于令牌桶处理数据报文的方式，RFC 中定义了两种令牌桶算法：

• 单速率三色标记（single rate three color marker，srTCM，RFC2697 定义，或称为单速双桶算法）算法，主要关注报文尺寸的突发。
• 双速率三色标记（two rate three color marker，trTCM，RFC2698 定义，或称为双速双桶算法）算法，主要关注速率的突发。

        两种算法都是为报文打上红、黄、绿三种颜色的标记，所以称为“三色标记”。 QoS 会根据报文的颜色，设置报文的丢弃优先级，两种算法都可工作于色盲模式和非色盲模式。对于单速率三色标记算法和双速率三色标记算法感兴趣的读者，可以阅读这篇文章：https://zhuanlan.zhihu.com/p/164503398

小结：令牌桶和漏桶算法区别：

（1）内容上：令牌桶算法是按固定速率生成令牌，请求能从桶中拿到令牌就执行，否则执行失败。漏桶算法是任务进桶速率不限，但是出桶的速率是固定的，超出桶大小的的任务丢弃，也就是执行失败。

（2）突发流量适应性上：令牌桶限制的是流入的速率且灵活，允许一次取出多个 token，只要有令牌就可以处理任务，在桶容量上允许处理突发流量。而漏桶算法出桶的速率固定，有突发流量也只能按流出的速率处理任务，所以漏桶算法是平滑流入的速率，限制流出速率。

5、四种限流算法的比较与小结：

        下面给出在某种特定场景和特定参数下四种限流方式对服务并发能力影响的折线图，其中X轴表示当前并发调用数，而Y轴表示某服务在不同并发调用程度下采取限流后的实际并发调用数：

        在不同场景不同参数下，服务采用所述四种限流方式都会有不同的效果，没有哪种限流算法能保证在所有场景下都是最优限流算法，因为这需要从服务资源特性、限流策略（参数）配置难度、开发难度和效果检测难度等多方面因素来考虑。但是相比于其他三种限流方式来说，令牌桶算法限流无疑是最为灵活的，因为它有着众多可配置的参数来直接影响限流的效果，比如 Google 的 Guava 包的 RateLimiter 提供了令牌桶算法的实现，感兴趣的读者可以自行百度。

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

参考文章：https://www.iteye.com/blog/manzhizhen-2311691

三、熔断设计：

1、什么是熔断机制：

        熔断机制可以快速地拒绝可能导致异常的调用，防止应用程序不断执行可能失败的操作，当感知到下游服务的资源出现不稳定状态（调用超时或异常比例升高时），暂时切断对下游服务的调用，而不是一直阻塞等待服务响应，阻止级联失败导致的雪崩效应，保证系统的可用性；尤其是后端太忙的时候，使用熔断设计可以保护后端不会过载。另外，对于服务间的调用一般都会设置超时与重试机制，但如果错误太多，或是在短时间内得不到修复，那么再多的重试也没有任何意义了，这时也需要使用熔断机制快速返回结果。

        另外，开启熔断之后，也应该不断检测下游服务的健康情况，当检测到该节点的服务调用响应正常后，则恢复调用链路。这就要求熔断器具备感知异常的能力以及对关键逻辑实现开关控制，因此，熔断的设计有两个关键点：

• ① 判断何时熔断：客户端对每次请求服务端的正常、异常（失败、拒绝、超时）返回计数，当异常返回次数超过设定阈值时进行熔断。进入熔断状态后，后续对该服务接口的调用不再经过网络，直接执行本地的默认方法，达到服务降级的效果。
• ② 何时从熔断状态恢复：处于熔断状态时，客户端每隔一段时间（比如5秒），允许部分请求通过，若这部分请求正常返回，就恢复熔断。

2、熔断机制的实现：

（1）以 Hystrix 为例，Hystrix 设计了三种状态：

• ① 熔断关闭状态（Closed）： 服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制。
• ② 熔断开启状态（Open）： 在固定时间内，接口调用出错比率达到一个阈值，会进入熔断开启状态。进入熔断状态后， 后续对该服务接口的调用不再经过网络，直接执行本地的 fallback 方法。
• ③ 半熔断状态（Half-Open）： 在进入熔断开启状态一段时间之后，熔断器会进入半熔断状态。所谓半熔断就是尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断开启状态。

（2）阿里研发的 Sentinel 内部熔断机制的实现其实也是熔断器的思想。Sentinel 底层会通过优化的滑动窗口数据结构来实时统计所有资源的调用数据（通过 QPS、限流 QPS、异常数、RT 等）。若资源配置了熔断降级规则，那么调用时就会取出当前时刻的统计数据进行判断。当达到熔断阈值时会将熔断器置为开启状态，切断所有的请求，直到过了降级时间窗口后再重置熔断器，继续允许请求通过。

四、降级设计：

1、什么是服务降级：

        所谓降级，就是指当访问量剧增、下游服务出现问题 或 非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务，这也是降级的最终目的。本质是为了解决资源不足和访问量过大的问题，当资源和访问量出现矛盾的时候，在有限的资源下，为了能够扛住大量的请求，我们就需要对系统进行降级操作，也就是暂时牺牲掉一些东西，以保障整个系统的平稳运行。一般来说，降级可以牺牲掉的东西有：

（1）降低一致性，从强一致性变成最终一致性：对于降低一致性，把强一致性变成最终一致性的做法可以有效地释放资源，并且让系统运行得更快，从而可以扛住更大的流量。通常会有两种做法：一种是简化流程的一致性（比如使用异步简化流程），一种是降低数据的一致性（比如使用缓存）。

（2）停止次要功能：停止访问不重要的功能，从而让系统释放出更多的资源。

（3）简化功能：把一些功能简化掉，比如简化业务流程，或是不再返回全量数据，只返回部分数据。

2、服务降级的类型与策略：

2.1、降级按照是否可以自动化可分为：人工开关降级和自动开关降级。

2.2、按触发降级的时机可以分为以下几个大类：

• 限流降级：当服务端请求数的数量超过配置的限制阈值，后续请求会被降级
• 超时降级：事先配置好超时时间和超时重试次数及机制，并使用异步机制探测恢复情况
• 失败降级：该方式主要是针对不稳定的API，当失败调用次数或者比例达到一定阀值时自动降级，同样要使用异步机制探测回复情况
• 故障降级：如要调用的远程服务挂掉了（比如网络故障、DNS故障、HTTP服务返回错误的状态码和RPC服务抛出异常），则可以直接降级

2.3、降级按照功能维度可分为：读服务降级和写服务降级

（1）读降级：可以暂时切换读数据来源，比如返回缓存数据、默认值、兜底数据。如果后端服务有问题，则可以降级为只读缓存，这种方式适合对读一致性要求不高的场景

① 缓存降级：使用缓存方式来降级部分读频繁的服务接口。每次服务调用成功时，记录服务的结果在缓存中，下一次失败时读取缓存的旧数据；可以根据时延要求选择本地缓存、分布式缓存、数据库或本地文件。适用场景为能够接受一定延迟的只读业务，且有足够的存储资源。但需要注意以下几点：

• 分布式缓存或数据库只是把服务故障转移到另一个依赖；
• 冷数据无法降级，即较长时间之前的状态数据无法降级；
• 降级后的数据存在一致性问题，需要根据业务情况设置合理的有效期；
• 数据量大时消耗过多的存储（特别是缓存）且命中率低，可以设置合理的缓存大小，使用LRU方式替换旧缓存。

② 默认值：直接返回配置中的默认值或者空数据。适用于弱依赖的只读业务，需要注意的是，默认值尽量有多种选择，避免千篇一律。

比如主播标语服务，在配置中心配置一批中性的默认标语，标语服务失败时直接随机取一条返回给用户，故障率不高的情况下用户基本上感知不到异常。

（2）写降级：可以使用异步处理并保证最终一致性，比如先更新缓存，然后异步同步到数据库中；或者采用事后处理，执行补偿机制，自动或者手动补偿。

        在 CAP 原理和 BASE 理论中写操作存在数据一致性这个问题，降级的目的是为了提供高可用性，在多数的互联网架构中，可用性是大于数据一致性的。所以丧失写入数据的同步，通过上面的理论，我们也能勉强接受数据最终一致性。高并发场景下，如果写入操作无法及时到达或抗压，可以异步消费数据、cache更新、log等方式进行补偿

文章小结：限流、熔断、降级都是解决服务间 RPC 过程出现的异常问题，保证服务稳定性的手段。限流发生在Server端，熔断发生在Client端，而降级是触发限流、熔断之后的补偿措施。在实际场景中通常会配合实现，比如熔断和降级，熔断决定何时降级，降级是服务在熔断状态下的对外表现。

相关阅读：

常见的服务器架构入门：从单体架构、EAI 到 SOA 再到微服务和 ServiceMesh

常见分布式理论（CAP、BASE）和一致性协议（Gosssip协议、Raft一致性算法）

一致性哈希算法原理详解

Nacos注册中心的部署与用法详细介绍

Nacos配置中心用法详细介绍

SpringCloud OpenFeign 远程HTTP服务调用用法与原理

什么是RPC？RPC框架dubbo的核心流程

服务容错设计：流量控制、服务熔断、服务降级

sentinel 限流熔断神器详细介绍

Sentinel 规则持久化到 apollo 配置中心

Sentinel-Dashboard 与 apollo 规则的相互同步

Spring Cloud Gateway 服务网关的部署与使用详细介绍

Spring Cloud Gateway 整合 sentinel 实现流控熔断

Spring Cloud Gateway 整合 knife4j 聚合接口文档

常见分布式事务详解（2PC、3PC、TCC、Saga、本地事务表、MQ事务消息、最大努力通知）

分布式事务Seata原理

RocketMQ事务消息原理