一、数据流转——Flink的数据抽象及数据交换过程本部分讲一下flink底层是如何定义和在操作符之间传递数据的。其中，第一个构造函数的checkBufferAndGetAddress()方法能够得到direct buffer的内存地址，因此可以操作堆外内存。1.2 ByteBuffer与NetworkBufferPoolpublic abstract class AbstractReference
反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为瓶颈，处理速率跟不上上游发送数据的速率，而需要对上游进行限速。由于实时计算应用通常使用消息队列来进行生产端和消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源（比如 Kafka consumer）的摄入速率。关于 Flink
参考文档https://ci.apache.org/projects/flink/flink-docs-release-1.5/monitoring/back_pressure.html
https://ci.apache.org/projects/flink/flink-docs-release-1.5/monitoring/back_pressure.html点击以后，如果抓包，会看到
当消费者的消费速率低于生产者的发送速率时，会造成背压，此时消费者无法从TCP缓存区中读取数据，因为它无法再从内存池中获取内存，从而造成TCP通道阻塞。生产者无法把数据发送出去，这就使生产者不再向缓存队列中写入数据，从而降低了生产速率。当消费者的消费速率提升且TCP通道不再阻塞时，生产者的发送速率又会得到提升，整个链路运行恢复正常。TCP的流量控制中有个非常重要的概念——TCP窗口。TCP窗口的大小
什么是 Back Pressure如果看到任务的背压警告（如 High 级别），这意味着 生成数据的速度比下游算子消费的的速度快。以一个简单的 Source -> Sink 作业为例。如果能看到 Source 有警告，这意味着 Sink 消耗数据的速度比 Source 生成速度慢。Sink 正在向 Source 施加反压。许多情况都会导致背压。例如，GC导致传入数据堆积，或者数据源
开胃菜在讲解Flink的checkPoint和背压机制之前，我们先来看下checkpoint和背压的相关基础，有助于后面的理解。作为用户，我们写好Flink的程序，上管理平台提交，Flink就跑起来了(只要程序代码没有问题），细节对用户都是屏蔽的。 实际上大致的流程是这样的：Flink会根据我们所写代码，会生成一个StreamGraph的图出来，来代表我们所写程序的拓扑结构。然后在提交的
想起来之前被问到了一个问题，如果Flink中的Task是一直不停的运行的话，那么拉取Kafka数据的Source端是不是会一直不停的拉取数据，如果消费速度不及时，内存不就很快会被撑爆了么？一开始对这个问题是一脸闷逼，后来随着对Flink使用的逐渐深入，对Flink的内部也有了一定的了解，所以本文就来了解下Flink内部的反压机制，看下反压机制是如何解决该问题的。&nbs
流处理系统需要能优雅地处理反压（backpressure）问题。反压通常产生于这样的场景：短时负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压，例如，垃圾回收停顿可能会导致流入的数据快速堆积，或者遇到大促或秒杀活动导致流量陡增。反压如果不能得到正确的处理，可能会导致资源耗尽甚至系统崩溃。目前主流的流处理系统 Storm/JStorm/Spark Streaming/F
1 网络流控1.1 网络流控的作用1.2 网络流控的实现-静态限速1.3 网络流控的实现：动态反馈/自动反压2 TCP流控机制2.1 TCP包结构2.2 TCP滑动窗口3 Flink TCP-based反压机制（before V1.5）3.1 示例：WindowWordCount3.2 编译阶段：生成 JobGraph3.3 运行阶段：调度 ExecutionGraph3.4 问题拆解：
网络监控工作中最重要的环节可能就是监控背压了，所谓背压是指系统接收数据的速率高于其处理速度 [1]。这种现象将给发送者带来压力，而导致它的原因可能有两种情况：
接收器很慢。
这可能是因为接收器本身就遇到了背压，所以无法以与发送方相同的速率继续处理数据；也有可能是接收器因为垃圾回收工作、缺少系统资源或 I/O 瓶颈而暂时卡住了。
声明: 1. 本文为我的个人复习总结, 并非那种从零基础开始普及知识 内容详细全面, 言辞官方的文章 2. 由于是个人总结, 所以用最精简的话语来写文章 &nbs
一、背压概述流处理系统需要能优雅地处理反压（backpressure）问题。反压通常产生于这样的场景：短时负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压，例如，垃圾回收停顿可能会导致流入的数据快速堆积，或者遇到大促或秒杀活动导致流量陡增。反压如果不能得到正确的处理，可能会导致资源耗尽甚至系统崩溃。目前主流的流处理系统 Storm/JStorm/Spark Strea
经常有人会问Flink如何处理背压问题。其实，答案很简单：Flink没用使用任何通用方案来解决这个问题，因为那根本不需要那样的方案。它利用自身作为一个纯数据流引擎的优势来优雅地响应背压问题。这篇文章，我们将介绍背压问题，然后我们将深挖Flink的运行时如何在task之间传输数据缓冲区内的数据以及流数据如何自然地两端降速来应对背压，最终将以一个小示例来演示它。什么是背压像Flink这样的流处理系统需
Apache Flink如何处理背压经常有人会问Flink如何处理背压问题。其实，答案很简单：Flink没用使用任何通用方案来解决这个问题，因为那根本不需要那样的方案。它利用自身作为一个纯数据流引擎的优势来优雅地响应背压问题。这篇文章，我们将介绍背压问题，然后我们将深挖Flink的运行时如何在task之间传输数据缓冲区内的数据以及流数据如何自然地两端降速来应对背压，最终将以一个小示例来演示它。1.
什么是 Back Pressure如果看到任务的背压警告（如 High 级别），这意味着 生成数据的速度比下游算子消费的的速度快。以一个简单的 Source -> Sink 作业为例。如果能看到 Source 有警告，这意味着 Sink 消耗数据的速度比 Source 生成速度慢。Sink 正在向 Source 施加反压。许多情况都会导致背压。例如，GC导致传入数据堆积，或者数据源在发送数据
一 . 你在开发Flink任务时，有没有遇到过背压问题，你是如何排查的？1. 背压产生的原因背压常常出现在大促或者一些热门活动等场景中， 在上面这类场景中, 短时间内流量陡增导致数据的堆积，系统整体的吞吐量无法提升。2. 监控背压方法可以通过 Flink Web UI 发现背压问题Flink 的 TaskManager 会每隔 50 ms 触发一次反压状态监测，共监测 100 次，并将计算结果反馈
单个 TaskManager 上的缓冲区总数通常不需要配置。需要配置时请参阅配置网络缓冲区文档。
造成背压（1）每当子任务的发送缓冲池耗尽时——也就是缓存驻留在结果子分区的缓存队列中或更底层的基于 Netty 的网络栈中时——生产者就被阻塞了，无法继续工作，并承受背压。接收器也是类似：较底层网络栈中传入的 Netty 缓存需要通过网络缓冲区提供给 Flink。如果相应子任务的缓冲池中没有可
通过这篇文章，大家在玩Flink的时候可以更加深刻地了解Checkpoint是怎么实现的，并且在设置相关参数以及使用的时候可以更加地得心应手。
目录相关基础问题反压InputGate(接收端处理反压)ResultPartition(发送端处理反压)总结最后相关基础在讲解Flink的checkPoint和背压机制之前，我们先来看下checkpoint和背压
Credit漫谈 在看上一部分的代码时，有一个小细节不知道读者有没有注意到，我们的数据发送端的代码叫做PartittionRequesetQueue.java，而我们的接收端却起了一个完全不相干的名字：CreditBasedPartitionRequestClientHandler.java。为什么前面加了CreditBased的前缀呢？1 背压问题 在流模型中，我们期待数据是像水流一样平滑的流过
《flink中的背压的处理原理》什么是背压问题流系统中消息的处理速度跟不上消息的发送速度，导致消息的堆积。如果系统能感知消息堆积，并调整消息发送的速度。 使消息的处理速度和发送速度相协调就是有背压感知的系统。背压如果不能得到正确地处理，可能会导致资源被耗尽或者 甚至出现更糟的情况导致数据丢失。flink就是一个有背压感知的基于流的分布式消息处理系统。 举例说明： 1.正常情况：消息处理速度
