今天是很忙碌的一天哦，有两个业务在催着验收，终于21：45卡点交上去了。
明早再修修补补一下应该就可以开始做实时方面的需求了，小紧张，
今天同事在同步会上讲这块业务的数据流时就提到了checkpoint和savepoint还有流处理的其他概念，多亏了这几天的学习，在脑海里已经有初步理解了不至于摸不着头脑。有一种上学时候预习到的的课本被老师提到的感觉哈哈哈。
速速开始今天的学习内容，讲Flink的反压机制。
反压是流式系统中关于处理能力的动态反馈机制，并且是从下游到上游的反馈。
正如之前介绍的，反压通常是由于某段时间内源头数据量暴涨，导致流任务处理数据的速度远远小于源头数据的流入速度。这种场景如果没有得到合适的处理，流任务的内存会越积越大，可能导致资源耗尽甚至系统崩溃。
反压原因
- 数据倾斜：数据分布不均，导致个别task处理数据过多。
- 算子性能问题：可能某个节点逻辑很复杂，如sink节点很慢或lookup join热查询慢等。
- 流量陡增：如大促时流量激增，或者使用了数据炸开的函数。
反压影响
- 任务处理性能出现瓶颈
- Checkpoint时间长或失败(某些反压会导致barrier需要花很长时间才能对齐，影响任务的稳定性)
- State状态变大/堆积
- Kafka数据积压
- OOM（内存溢出）
不同流计算引擎的处理方式
对于不同的流计算引擎，处理方式是不一样的：
- Storm是通过监控processbolt中的接收队列负载情况来处理反压，如果超过高水位值，就将反压信息写到ZooKeeper，由ZooKeeper上的watch通知该拓扑的所有worker都进入反压状态，最后spout停止发送tuple 来处理的。
- 而 Spark Streaming通过设置属性“spark.streaming.backpressure.enabled可以自动进行反压处理，它会动态控制数据接收速率来适配集群数据处理能力。
- 对于Flink来说，不需要进行任何的特殊设置，其本身的纯数据流引擎可以非常优雅地处理反压问题。
在Flink中，每个组件都有对应的分布式阻塞队列，只有队列不满的情况下，上游才能向下发送数据，因此较慢的接收者会自动降低发送者的发送速率，因为一旦队列满了(有界队列)，发送者会被阻塞。
常见处理方案
- 很多时候反压就是资源不足导致的，给任务加资源：CPU资源、内存资源、其他资源
- 定位为数据倾斜、算子性能问题之类，就去解决这些问题
- 流量过大消费不过来，就调大并行度
- 限流与缓冲，限制数据源的消费数据速度。
Flink通过水位线（Watermark）机制来实现限流。水位线是一个时间戳，表示当前处理的数据已经到达的位置。通过控制水位线的传播速度，Flink可以限制数据的流量，避免数据的堆积和延迟。当下游节点处理速度较慢时，水位线的传播速度会相应减慢，从而限制上游节点的生产速度。
比如在事件时间窗口的应用中，可以自己设置在数据源处加一些限流措施，让每个数据源都能够够匀速消费数据，避免出现有的 Source 快，有的 Source 慢，导致窗口 input pool 打满，watermark 对不齐导致任务卡住 - 关闭 Checkpoint。关闭 Checkpoint 可以将 barrier 对齐这一步省略掉，促使任务能够快速回溯数据。然后等数据回溯完成之后，再将 Checkpoint 打开