11.4 如何利用广播变量动态更新告警规则？

一个在生产环境运行的流作业有时候会想变更一些作业的配置或者数据流的配置，然后作业可以读取并使用新的配置，而不是通过修改配置然后重启作业来读取配置，毕竟重启一个有状态的流作业代价挺大，本节将带你熟悉 Broadcast，并通过一个案例来教会你如何去动态的更新作业的配置。

11.3 如何利用 Async I/O 读取告警规则？

Async 中文是异步的意思，在流计算中，使用异步 I/O 能够提升作业整体的计算能力，本节中不仅会讲解异步 I/O 的 API 原理，还会通过一个实战需求（读取告警规则）来讲解异步 I/O 的使用。

11.2 如何使用 Flink ProcessFunction 处理宕机告警?

在 3.3 节中讲解了 Process 算子的概念，本节中将更详细的讲解 Flink ProcessFunction，然后教大家如何使用 ProcessFunction 来解决公司中常见的问题 —— 宕机，这个宕机不仅仅包括机器宕机，还包含应用宕机，通常出现宕机带来的影响是会很大的，所以能及时收到告警会减少损失。

第十一章 —— Flink 实战

本章主要是 Flink 实战，介绍了一些常见的需求，比如实时统计网站页面的 PV/UV、宕机告警、动态更新配置、应用 Error 日志实时告警等，然后分别去分析这些需求的实现方式，明白该使用 Flink 中的哪些知识点才能够很好的完成这种需求，并提供完整的案例代码供大家参考。在实现完成这些需求之后，笔者还将会更深一步的去讲解下这些知识点背后的实现方式，希望可以加深你对这些知识点的印象，以便后面你可以灵活的处理类似的需求。

11.1 如何统计网站各页面一天内的 PV 和 UV？

大数据开发最常统计的需求可能就是 PV、UV。PV 全拼 PageView，即页面访问量，用户每次对网站的访问均被记录，按照访问量进行累计，假如用户对同一页面访问了 5 次，那该页面的 PV 就应该加 5。UV 全拼为 UniqueVisitor，即独立访问用户数，访问该页面的一台电脑客户端为一个访客，假如用户对同一页面访问了 5 次，那么该页面的 UV 只应该加 1，因为 UV 计算的是去重后的用户数而不是访问次数。当然如果是按天统计，那么当天 0 点到 24 点相同的客户端只被计算一次，如果过了今天 24 点，第二天该用户又访问了该页面，那么第二天该页面的 UV 应该加 1。 概念明白了那如何使用 Flink 来统计网站各页面的 PV 和 UV 呢？通过本节来详细描述。

10.2 如何使用 Flink ParameterTool 读取配置？

在使用 Flink 中不知道你有没有觉得配置的管理很不方便，比如像算子的并行度配置、Kafka 数据源的配置（broker 地址、topic 名、group.id）、Checkpoint 是否开启、状态后端存储路径、数据库地址、用户名和密码等，反正各种各样的配置都杂乱在一起，当然你可能说我就在代码里面写死不就好了，但是你有没有想过你的作业是否可以不修改任何配置就直接在各种环境（开发、测试、预发、生产）运行呢？可能每个环境的这些配置对应的值都是不一样的，如果你是直接在代码里面写死的配置，那这下子就比较痛苦了，每次换个环境去运行测试你的作业，你都要重新去修改代码中的配置，然后编译打包，提交运行，这样你就要花费很多时间在这些重复的劳动力上了。有没有什么办法可以解决这种问题呢？

第十章 —— Flink 最佳实践

本章将介绍两个最佳实践，第一个是如何合理的配置重启策略，笔者通过自己的亲身经历来讲述配置重启策略的重要性，接着介绍了 Flink 中的重启策略和恢复策略的发展实现过程；第二个是如何去管理 Flink 作业的配置。两个实践大家可以参考，不一定要照搬运用在自己的公司，同时也希望你可以思考下自己是否有啥最佳实践可以分享。

10.1 如何设置 Flink Job RestartStrategy（重启策略）？

从使用 Flink 到至今，遇到的 Flink 有很多，解决的问题更多（含帮助微信好友解决问题），所以对于 Flink 可能遇到的问题及解决办法都比较清楚，那么在这章就给大家讲解下几个 Flink 中比较常遇到的问题的解决办法。

9.6 如何处理 Flink 中数据倾斜问题？

在大数据计算场景，无论使用 MapReduce、Spark 还是 Flink 计算框架，无论是批处理还是流处理都存在数据倾斜的问题，通过本节学习产生数据倾斜的原因及如何在生产环境解决数据倾斜。

9.5 Flink 中如何保证 Exactly Once？

在分布式场景下，我们的应用程序随时可能出现任何形式的故障，例如：机器硬件故障、程序 OOM 等。当应用程序出现故障时，Flink 为了保证数据消费的 Exactly Once，需要有相应的故障容错能力。Flink 是通过周期性 Checkpoint 的方式来实现故障容错，这里使用的是基于 Chandy-Lamport 改进的算法。本节会介绍 Flink 内部如何保证 Exactly Once 以及端对端如何保证 Exactly Once。

9.4 如何合理的设置 Flink 作业并行度？

在 9.2 节中讲解了 Flink Job 中的执行计划，并详细分析了 Flink 中的 operator chain 在一起的各种条件，在 9.3 节中也通过真实生产环境的案例来分享并行度与 Slot 的概念与关系。相信大家也都有一定的理解，但是有时候生产环境如果 Job 突然消费不及时了，或者 Job 就根本不在消费数据了，那么该怎么办？首先得看下相关的监控查看 Job 是否在正常运行，是否出现反压的情况，是否这会生产数据量过大然而并行度却是根据之前数据量设置的，种种原因都需要一个个排查一下，然后找到根因才能够对应的去解决。这节来讲解下遇到这种问题后如何合理配置并行度呢？

9.3 Flink Parallelism 和 Slot 深度理解

相信使用过 Flink 的你或多或少遇到过下面这个问题（笔者自己的项目曾经也出现过这样的问题），错误信息如下：

9.2 如何查看 Flink 作业执行计划？

当一个应用程序需求比较简单的情况下，数据转换涉及的 operator（算子）可能不多，但是当应用的需求变得越来越复杂时，可能在一个 Job 里面算子的个数会达到几十个、甚至上百个，在如此多算子的情况下，整个应用程序就会变得非常复杂，所以在编写 Flink Job 的时候要是能够随时知道 Job 的执行计划那就很方便了。

第九章 —— Flink 性能调优

通过第八章的监控图表信息，我们可以发现问题，在发现问题后，需要去分析为什么会发生这些问题以及我们该如何去解决这些问题。本章将会介绍很多 Flink 生产环境遇到的问题，比如作业出现反压、作业并行度配置不合理、作业数据倾斜等，除了引出这种常见问题之外，笔者还将和你一起去分析这种问题造成的原因以及如何去优化作业。比如合理的配置并行度、让作业算子尽可能的 chain 在一起已达到最优等。希望通过本章的内容，你可以将这些解决方法运用在你的公司，帮助公司解决类似的问题。

9.1 如何处理 Flink Job BackPressure （反压）问题?

反压（BackPressure）机制被广泛应用到实时流处理系统中，流处理系统需要能优雅地处理反压问题。反压通常产生于这样的场景：短时间的负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压，例如，垃圾回收停顿可能会导致流入的数据快速堆积，或遇到大促、秒杀活动导致流量陡增。反压如果不能得到正确的处理，可能会导致资源耗尽甚至系统崩溃。反压机制是指系统能够自己检测到被阻塞的 Operator，然后自适应地降低源头或上游数据的发送速率，从而维持整个系统的稳定。Flink 任务一般运行在多个节点上，数据从上游算子发送到下游算子需要网络传输，若系统在反压时想要降低数据源头或上游算子数据的发送速率，那么肯定也需要网络传输。所以下面先来了解一下 Flink 的网络流控（Flink 对网络数据流量的控制）机制。

8.2 搭建一套 Flink 监控系统

8.1 节中讲解了 JobManager、TaskManager 和 Flink Job 的监控，以及需要关注的监控指标有哪些。本节带大家讲解一下如何搭建一套完整的 Flink 监控系统，如果你所在的公司没有专门的监控平台，那么可以根据本节的内容来为公司搭建一套属于自己公司的 Flink 监控系统。

第八章 —— Flink 监控

Flink 相关的组件和作业的稳定性通常是比较关键的，所以得需要对它们进行监控，如果有异常，则需要及时告警通知。本章先会教会教会大家如何利用现有 Flink UI 上面的信息去发现和排查问题，会指明一些比较重要和我们非常关心的指标，通过这些指标我们能够立马定位到问题的根本原因。接着笔者会教大家如何去利用现有的 Metrics Reporter 去构建一个 Flink 的监控系统，它可以收集到所有作业的监控指标，并会存储这些监控指标数据，最后还会有一个监控大盘做数据可视化，通过这个大盘可以方便排查问题。

8.1 实时监控 Flink 及其作业

7.2 Flink 作业如何在 Standalone、YARN、Mesos、K8S 上部署运行？

前面章节已经有很多学习案列带大家使用 Flink，不仅有讲将 Flink 应用程序在 IDEA 中运行，也有讲将 Flink Job 编译打包上传到 Flink UI 上运行，在这 UI 背后可能是通过 Standalone、YARN、Mesos、Kubernetes 等运行启动的 Flink。那么这节就系统讲下如何部署和运行我们的 Flink Job，大家可以根据自己公司的场景进行选择使用哪种方式进行部署 Flink 作业！

第七章 —— Flink 作业环境部署

在第一章中介绍过 Flink 是可以以多种方式部署的，比如 Standalone、YARN、Mesos、K8S。本章将先对 Flink 中的所有配置文件做一个详细的讲解，接下来将讲解 JobManager 高可用部署相关的配置，最后会分别讲解如何在不同的平台上部署运行 Flink 作业。虽然在你们公司可能只会用到其中的一种，但是仍然建议你将每种方式都熟悉一下。

7.1 Flink 配置详解及如何配置高可用？

6.5 Flink 扩展库——Gelly

在 1.9 版本中还剩最后一个扩展库就是 Gelly，本节将带你了解一下 Gelly 的功能以及如何使用。

6.4 Flink 扩展库——Machine Learning

随着人工智能的火热，机器学习这门技术也变得异常重要，Flink 作为一个数据处理的引擎，虽然目前在该方面还较弱，但是在 Flink Forward Asia 2019 北京站后，阿里开源了 Alink 平台的核心代码，并上传了一系列的算法库，该项目是基于 Flink 的通用算法平台，开发者和数据分析师可以利用 Alink 提供的一系列算法来构建软件功能，例如统计分析、机器学习、实时预测、个性化推荐和异常检测。相信未来 Flink 的机器学习库将会应用到更多的场景去，本节将带你了解一下 Flink 中的机器学习库。

6.3 Flink 扩展库——State Processor API

State Processor API 功能是在 1.9 版本中新增加的一个功能，本节将带你了解一下其功能和如何使用？

6.2 使用 Flink CEP 处理复杂事件

6.1 节中介绍 Flink CEP 和其使用场景，本节将详细介绍 Flink CEP 的 API，教会大家如何去使用 Flink CEP。