Dubbo 3 之 Triple 流控反压原理解析

作者： 顾欣

Triple 是 Dubbo3 提出的基于 HTTP2 的开放协议，旨在解决 Dubbo2 私有协议带来的互通性问题。Triple 基于 HTTP2 定制自己的流控，支持通过特定的异常通知客户端业务层服务端负载高情况，保护了服务端被大流量击垮，提高系统高可用能力。

流控反压现状

客户端和服务器端在接收数据的时候有一个缓冲区来临时存储数据，但是缓冲区的大小是有限制的，所以有可能会出现缓冲区溢出的情况， Http 通过流控保护数据溢出丢失风险。

Http1 流控

在 HTTP1.1 中，流量的控制依赖的是底层 TCP 协议，在客户端和服务器端建立连接的时候，会使用系统默认的设置来建立缓冲区。在数据进行通信的时候，会告诉对方它的接收窗口的大小，这个接收窗口就是缓冲区中剩余的可用空间。如果接收窗口大小为零，则说明接收方缓冲区已满，则发送方将不再发送数据，直到客户端清除其内部缓冲区，然后请求恢复数据传输。

Http2 流控

Http2 使用了多路复用机制，一个 TCP 连接可以有多个 Http2 连接，故在 Http2 中，有更加精细的流控制机制，允许服务端实现自己数据流和连接级的流控制。服务端与客户端初次见了连接时，会通过发送 Http2SettingsFrame 设置初始化的流控窗口大小，用于 Stream 级别流控，默认为65,535字节。定好流控窗口后，每次客户端发送数据就会减少流控窗口的大小，服务端收到数据后会发送窗口更新包（WINDOW_UPDATE frame）通知客户端更新窗口。客户端收到窗口更新包后就会增加对应值的流控窗口，从而达到动态控制的目的。

Triple 流控反压

Netty 基于 Http2 实现了基础的流控，当服务端负载过高，客户端发送窗口为0时，新增请求就无法被发送出去，会在缓存到客户端待发送请求队列中，缓存数据过大，就会造成客户端内存溢出，影响业务程序。

Triple 基于 netty 实现了 Http2 协议，通过 Http2FlowController 接口统一封装，在实现分为进站（inbound）和出站（outbound）两个维度的实现。Triple 在 inbound 流量上使用了 netty 的默认流控实现，在 outbound 上实现了自己流控，基于服务端负载，将服务端流量压力透传到客户端业务层，实现客户端的业务反压，暂停业务继续发送请求，保护服务端不被大流量击垮。

连接初始化

Triple 在初次建立连接时，通过 TripleHttp2Protocol 初始化 http2 配置，默认流控窗口 DEFAULT_WINDOW_INIT_SIZE = MIB_8，并在服务端和客户端加入自己的 outbound 流控接口。

Inbound 流控

Inbound 流量会通过 DefaultHttp2LocalFlowController 的 consumeBytes 方法实现流控窗口更新与发送。

1.入口传入 Http 流与更新数据大小

2.找到对应连接实现数据消费

3.更新流控窗口

4.发送流控更新数据包（window_update）

Outbound 流控

Outbound 通过 Triple 自己的流控实现 TriHttp2RemoteFlowController，将服务端压力反馈到业务层，保护服务端被大流量击垮。

1.发送数据时判断是否还有窗口

2.窗口为0时抛出特定异常

3.反馈客户端流控异常

总结

Triple 通过将底层客户端发送窗口为0场景封装为特定流控异常，透传至客户端上层业务，阻止客户端业务继续数据发送，有效的保护了服务端被大流量击垮和客户端的内存溢出的问题。

未来展望

目前 Triple 已经基本实现了流控反压能力，未来我们将深度联动业务，基于业务负载自适应调整反压流控，一是在 inbound 上将流控窗口包发送时机调整到服务端业务处理完成后，二是在 outbound 流量上关联客户端业务层，动态调整客户端发送速率。从而实现基于服务端业务负载动态反压流控机制。

点击此处查看原文文档