01 引言
在前面的博客，我们学习了Flink与Spark了，有兴趣的同学可以参阅下：
- 《Flink教程（01）- Flink知识图谱》
- 《Flink教程（02）- Flink入门》
- 《Flink教程（03）- Flink环境搭建》
- 《Flink教程（04）- Flink入门案例》
- 《Flink教程（05）- Flink原理简单分析》
- 《Flink教程（06）- Flink批流一体API（Source示例）》
- 《Flink教程（07）- Flink批流一体API（Transformation示例）》
- 《Flink教程（08）- Flink批流一体API（Sink示例）》
- 《Flink教程（09）- Flink批流一体API（Connectors示例）》
- 《Flink教程（10）- Flink批流一体API（其它）》
- 《Flink教程（11）- Flink高级API（Window）》
- 《Flink教程（12）- Flink高级API（Time与Watermaker）》
- 《Flink教程（13）- Flink高级API（状态管理）》
- 《Flink教程（14）- Flink高级API（容错机制）》
- 《Flink教程（15）- Flink高级API（并行度）》
- 《Flink教程（16）- Flink Table与SQL》
- 《Flink教程（17）- Flink Table与SQL（案例与SQL算子）》
- 《Flink教程（18）- Flink阶段总结》
- 《Flink教程（19）- Flink高级特性（BroadcastState）》
- 《Flink教程（20）- Flink高级特性（双流Join）》
- 《Flink教程（21）- Flink高级特性（End-to-End Exactly-Once）》
- 《Flink教程（22）- Flink高级特性（异步IO）》
- 《Flink教程（23）- Flink高级特性（Streaming File Sink）》
- 《Flink教程（24）- Flink高级特性（File Sink）》
- 《Flink教程（25）- Flink高级特性（FlinkSQL整合Hive）》
- 《Flink教程（26）- Flink多语言开发》
- 《Flink教程（27）- Flink Metrics监控》
- 《Flink教程（28）- Flink性能优化》
- 《Flink教程（29）- Flink内存管理》
- 《Flink教程（30）- Flink VS Spark》
本文主要讲解Flink的网络流控及反压。
02 为什么需要网络流控?
首先我们可以看下这张最精简的网络流控的图，Producer 的吞吐率是 2MB/s，Consumer 是 1MB/s，这个时候我们就会发现在网络通信的时候我们的 Producer 的速度是比 Consumer 要快的，有 1MB/s 的这样的速度差，假定我们两端都有一个 Buffer，Producer 端有一个发送用的 Send Buffer，Consumer 端有一个接收用的 Receive Buffer，在网络端的吞吐率是 2MB/s，过了 5s 后我们的 Receive Buffer 可能就撑不住了，这时候会面临两种情况：
- 如果 Receive Buffer 是有界的，这时候新到达的数据就只能被丢弃掉了。
- 如果 Receive Buffer 是无界的，Receive Buffer 会持续的扩张，最终会导致 Consumer 的内存耗尽。
03 网络流控的实现：静态限速
为了解决这个问题，我们就需要网络流控来解决上下游速度差的问题，传统的做法可以在 Producer 端实现一个类似 Rate Limiter 这样的静态限流，Producer 的发送速率是 2MB/s，但是经过限流这一层后，往 Send Buffer 去传数据的时候就会降到 1MB/s 了，这样的话 Producer 端的发送速率跟 Consumer 端的处理速率就可以匹配起来了，就不会导致上述问题。但是这个解决方案有两点限制：
- 事先无法预估 Consumer 到底能承受多大的速率
- Consumer 的承受能力通常会动态地波动
04 网络流控的实现：动态反馈/自动反压
针对静态限速的问题我们就演进到了动态反馈（自动反压）的机制，我们需要 Consumer 能够及时的给 Producer 做一个 feedback，即告知 Producer 能够承受的速率是多少。动态反馈分为两种：
- 负反馈：接受速率小于发送速率时发生，告知 Producer 降低发送速率
- 正反馈：发送速率小于接收速率时发生，告知 Producer 可以把发送速率提上来
来看看几个经典案例：
4.1 案例一：Storm 反压实现
上图就是 Storm 里实现的反压机制，可以看到 Storm 在每一个 Bolt 都会有一个监测反压的线程（Backpressure Thread），这个线程一但检测到 Bolt 里的接收队列（recv queue）出现了严重阻塞就会把这个情况写到 ZooKeeper 里，ZooKeeper 会一直被 Spout 监听，监听到有反压的情况就会停止发送，通过这样的方式匹配上下游的发送接收速率。
4.2 案例二：Spark Streaming 反压实现
Spark Streaming 里也有做类似这样的 feedback 机制，上图 Fecher 会实时的从 Buffer、Processing 这样的节点收集一些指标然后通过 Controller 把速度接收的情况再反馈到 Receiver，实现速率的匹配。
4.3 为什么 Flink（before V1.5）没有用类似的方式实现 feedback 机制？
首先在解决这个疑问之前我们需要先了解一下 Flink 的网络传输是一个什么样的架构。
这张图就体现了 Flink 在做网络传输的时候基本的数据的流向，发送端在发送网络数据前要经历自己内部的一个流程，会有一个自己的 Network Buffer，在底层用 Netty 去做通信，Netty 这一层又有属于自己的 ChannelOutbound Buffer，因为最终是要通过 Socket 做网络请求的发送，所以在 Socket 也有自己的 Send Buffer，同样在接收端也有对应的三级 Buffer。学过计算机网络的时候我们应该了解到，TCP 是自带流量控制的。
实际上 Flink （before V1.5）就是通过 TCP 的流控机制来实现 feedback 的。
4.4 TCP 流控机制
根据下图我们来简单的回顾一下 TCP 包的格式结构。首先，他有 Sequence number 这样一个机制给每个数据包做一个编号，还有 ACK number 这样一个机制来确保 TCP 的数据传输是可靠的，除此之外还有一个很重要的部分就是 Window Size，接收端在回复消息的时候会通过 Window Size 告诉发送端还可以发送多少数据。
接下来我们来简单看一下这个过程。
TCP 流控：滑动窗口
TCP 的流控就是基于滑动窗口的机制，现在我们有一个 Socket 的发送端和一个 Socket 的接收端，目前我们的发送端的速率是我们接收端的 3 倍，这样会发生什么样的一个情况呢？假定初始的时候我们发送的 window 大小是 3，然后我们接收端的 window 大小是固定的，就是接收端的 Buffer 大小为 5。
首先，发送端会一次性发 3 个 packets，将 1，2，3 发送给接收端，接收端接收到后会将这 3 个 packets 放到 Buffer 里去。
接收端一次消费 1 个 packet，这时候 1 就已经被消费了，然后我们看到接收端的滑动窗口会往前滑动一格，这时候 2，3 还在 Buffer 当中 而 4，5，6 是空出来的，所以接收端会给发送端发送 ACK = 4 ，代表发送端可以从 4 开始发送，同时会将 window 设置为 3 （Buffer 的大小 5 减去已经存下的 2 和 3），发送端接收到回应后也会将他的滑动窗口向前移动到 4，5，6。
这时候发送端将 4，5，6 发送，接收端也能成功的接收到 Buffer 中去。
到这一阶段后，接收端就消费到 2 了，同样他的窗口也会向前滑动一个，这时候他的 Buffer 就只剩一个了，于是向发送端发送 ACK = 7、window = 1。发送端收到之后滑动窗口也向前移，但是这个时候就不能移动 3 格了，虽然发送端的速度允许发 3 个 packets 但是 window 传值已经告知只能接收一个，所以他的滑动窗口就只能往前移一格到 7 ，这样就达到了限流的效果，发送端的发送速度从 3 降到 1。
我们再看一下这种情况，这时候发送端将 7 发送后，接收端接收到，但是由于接收端的消费出现问题，一直没有从 Buffer 中去取，这时候接收端向发送端发送 ACK = 8、window = 0 ，由于这个时候 window = 0，发送端是不能发送任何数据，也就会使发送端的发送速度降为 0。这个时候发送端不发送任何数据了，接收端也不进行任何的反馈了，那么如何知道消费端又开始消费了呢？
TCP 当中有一个 ZeroWindowProbe 的机制，发送端会定期的发送 1 个字节的探测消息，这时候接收端就会把 window 的大小进行反馈。当接收端的消费恢复了之后，接收到探测消息就可以将 window 反馈给发送端端了从而恢复整个流程。TCP 就是通过这样一个滑动窗口的机制实现 feedback。
