This is an automated email from the ASF dual-hosted git repository. albumenj pushed a commit to branch 1228_blog_2 in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
commit 7470650c7920ed55e20752bc99521975d36d3e06 Author: Albumen Kevin <[email protected]> AuthorDate: Wed Dec 28 21:13:39 2022 +0800 Update index --- .../blog/java/codeanalysis/triple-backpressure.md | 32 +++++++++++----------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/content/zh/blog/java/codeanalysis/triple-backpressure.md b/content/zh/blog/java/codeanalysis/triple-backpressure.md index d2c4c11ed48..15e014b7691 100644 --- a/content/zh/blog/java/codeanalysis/triple-backpressure.md +++ b/content/zh/blog/java/codeanalysis/triple-backpressure.md @@ -12,20 +12,20 @@ Triple 是 Dubbo 3 提出的基于 HTTP2 的开放协议， Triple 基于 HTTP/2 定制自己的流控，支持通过特定的异常通知客户端业务层服务端负载高情况， 保护了服务端被大流量击垮，提高系统高可用能力。 -# 一、流控反压现状 +## 一、流控反压现状 客户端和服务器端在接收数据的时候有一个缓冲区来临时存储数据， 但是缓冲区的大小是有限制的，所以有可能会出现缓冲区溢出的情况， HTTP 通过流控保护数据溢出丢失风险。 -## 1、HTTP/1 流控 +### 1、HTTP/1 流控 在 HTTP/1.1 中，流量的控制依赖的是底层TCP协议，在客户端和服务器端建立连接的时候， 会使用系统默认的设置来建立缓冲区。在数据进行通信的时候，会告诉对方它的接收窗口的大小， 这个接收窗口就是缓冲区中剩余的可用空间。如果接收窗口大小为零，则说明接收方缓冲区已满， 则发送方将不再发送数据，直到客户端清除其内部缓冲区，然后请求恢复数据传输。 -## 2、HTTP/2 流控 +### 2、HTTP/2 流控 HTTP/2 使用了多路复用机制，一个TCP连接可以有多个 HTTP/2 连接， 故在 HTTP/2 中，有更加精细的流控制机制，允许服务端实现自己数据流和连接级的流控制。 @@ -37,7 +37,7 @@ HTTP/2 使用了多路复用机制，一个TCP连接可以有多个 HTTP/2 连  -# 二、Triple流控反压 +## 二、Triple流控反压 Netty 基于 HTTP/2 实现了基础的流控，当服务端负载过高，客户端发送窗口为 0 时， 新增请求就无法被发送出去，会在缓存到客户端待发送请求队列中，缓存数据过大， @@ -50,7 +50,7 @@ Triple 在 inbound 流量上使用了 Netty 的默认流控实现， 将服务端流量压力透传到客户端业务层，实现客户端的业务反压，暂停业务继续发送请求， 保护服务端不被大流量击垮。 -## 1 连接初始化 +### 1、连接初始化 Triple在初次建立连接时，通过 `TripleHttpProtocol` 初始化 HTTP/2 配置， 默认流控窗口 `DEFAULT_WINDOW_INIT_SIZE = MIB_8`， @@ -58,50 +58,50 @@ Triple在初次建立连接时，通过 `TripleHttpProtocol` 初始化 HTTP/2  -## 2 Inbound流控 +### 2、Inbound流控 Inbound 流量会通过 `DefaultHttpLocalFlowController` 的 `consumeBytes` 方法实现流控窗口更新与发送。 -### 1.入口传入HTTP 流与更新数据大小 +#### 1) 入口传入HTTP 流与更新数据大小  -### 2.找到对应连接实现数据消费 +#### 2) 找到对应连接实现数据消费  -### 3.更新流控窗口 +#### 3) 更新流控窗口  -### 4.发送流控更新数据包（window_update） +#### 4) 发送流控更新数据包（window_update）  -## 3 Outbound流控 +### 3、Outbound流控 Outbound 通过 Triple 自己的流控实现 `TriHttpRemoteFlowController`， 将服务端压力反馈到业务层，保护服务端被大流量击垮。 -### 1.发送数据时判断是否还有窗口 +#### 1) 发送数据时判断是否还有窗口  -### 2.窗口为0时抛出特定异常 +#### 2) 窗口为0时抛出特定异常  -### 3.反馈客户端流控异常 +#### 3) 反馈客户端流控异常  -## 4 总结 +### 4、总结 Triple 通过将底层客户端发送窗口为 0 场景封装为特定流控异常， 透传至客户端上层业务，阻止客户端业务继续数据发送， 有效的保护了服务端被大流量击垮和客户端的内存溢出的问题。 -# 三、未来展望 +## 三、未来展望 目前 Triple 已经基本实现了流控反压能力，未来我们将深度联动业务， 基于业务负载自适应调整反压流控，
