This is an automated email from the ASF dual-hosted git repository.
albumenj pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new 47bf2a10f0a Update index (#1779)
47bf2a10f0a is described below
commit 47bf2a10f0abdf4c04de59d8135045b199796707
Author: Albumen Kevin <[email protected]>
AuthorDate: Wed Dec 28 21:14:17 2022 +0800
Update index (#1779)
---
.../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 已经基本实现了流控反压能力，未来我们将深度联动业务，
基于业务负载自适应调整反压流控，
