九师兄

在上一篇文章中，我们知道了Flink执行savePoint是怎么一步一步的将Savepoint请求发送到服务器的，下面我们看卡 服务器接受到Savepoint请求是怎么执行的。在stopWithSavepoint方法中我们主要做了我们停止检查点协调器，然后触发检查点。在下面方法中我们首先获取master节点的网关，然后把请求发送给master。然后stopWithSavepoint这个方法有2个实现类，我们先看。然后JobMaster就收到了这个请求，然后调用。后面的比较复杂了，下次有空，分章节分析。

我们知道我们执行如下命令就可以产生一个SavePoint，那么这个流程会是什么样的呢？然后在里面解析参数并行执行然后在savepoint方法里面做参数解析和一些配置，其中主要有2个重要配置然后就触发我们的检查点然后是发生请求，等待报错或者正常发生请求调用的是方法然后是两阶段执行Savepoint这段代码触发 Flink 的 Checkpoint 是分为两个阶段的。

今天看了一个现场环境，然后对方因为Hadoop问题，然后导致一直无法提交任务到yarn上，日志阻塞如下日志详情如下这个hadoop集群是别人的，然后我们的flink要体检任务到别人的集群，和对方掰持了很久，我说我们提交任务到yarn，然后yarn属于hadoop，你现在hdfs集群有问题，导致我们无法提交任务到yarn，然后对方说你只使用我们的kafka集群，kafka是好的呀，和这个有什么关系，我一脸懵逼，觉得他们的运维太low了。

是这样的，我们有个系统，采用的是实体类，以前我们是使用实体类传参。实体类如下然后报错这个错误通常是由于 Flink 作业尝试对一个未在 Flink 序列化注册中的类进行序列化或反序列化引起的。当 Flink 使用 Kryo 序列化器时，它需要知道将要序列化或反序列化的所有类。注册类: 确保你使用的所有自定义类都已经注册到 Flink 的 Kryo 注册器中。这可以通过 Flink 的 ExecutionConfig 进行配置，手动注册类，例如：flink 低版本flink高版本。

Slow waitForAckedSeqno took 37735ms: 表示等待确认序列号的操作花费了37,735毫秒，超过了设定的阈值。以前也会打日志，但是打了四五十行，然后就提交成功了，但是没有报错warn,现在提示这个warn，怀疑是hadoop有问题了。threshold=30000ms: 阈值是30,000毫秒，这是一个预定义的时间，用于标识等待确认序列号的最大允许时间。在前一段时间搞了flink提交任务到kerberos认证的yarn集群，今天某个现场原先能运行的任务，现在突然卡住了。

然后我们继续往后面看，这个host是数字，代表运行在第几台机器，这个在TaskManager中是一对一的，在TaskManager列表中是按照从上往下的顺序1,2,3,4等机器排序的，但是如果你是docker容器，那么这里是一样的，都是1，因为是宿主机，不是docker容器。如果我们想知道运行到哪个容器上呢？我们点开SubTasks这里，左边的ID是任务的并行度ID，然后右边是数据处理，可以看到我们这个并行度处理的数据量很大，说明这个节点发生了数据倾斜。那么我们的任务运行到哪里了呢？

里面有个简单的图示案例。最简单的例子：aaa 在一号流中的 value 和二号流的 value 相加，再输出到下游，如下图所示，一号流中的 value 存入 state，在二号流中取出并相加，将结果输出给下游：我有这个疑问：这个状态是全局的还是 每个并行度一份呀？于是我做了几个案例。

环境变量来设置 Java 运行时的选项，其中 -Dlog.file.name=my_fixed_log_name.log 设置了日志文件的名称为 my_fixed_log_name.log。在 Flink 的 YARN 会话模式（yarn-session）中，日志的名称通常包括随机生成的标识符，这是为了确保在多个任务和多个会话之间不发生日志名称冲突。如果我们已经设置了，那么就是我们设置的值，因为我们没有设置，而且如果你使用的是宿主机，那么这个位置是固定的。这些变量的组合形成了日志文件的名称。

这里看着所有的数据都是0，然后拒绝连接了，报错的位置位于runInCoordinatorThread。那么看看这个线程池是怎么做的，但是看着这个线程池最少有一个的，不清楚为啥报错。一个FLink程序报错。

这个错误表明在 PostgreSQL 复制和 Write-Ahead Logging（WAL）机制的上下文中出现了问题。看起来是在 Debezium PostgreSQL 连接器的使用过程中发生的。WAL 段是 PostgreSQL 复制机制的关键部分，用于跟踪对数据库的更改。在应用任何更改到生产系统之前，请在非生产环境中进行充分的测试。此外，请查阅 PostgreSQL 和 Debezium 的文档以获取更详细的信息和故障排除指南。

这段代码的主要目的是在内存使用超过阈值时生成警告消息，以提醒用户可能存在内存问题，特别是对网络吞吐量的影响。警告消息提供了一些建议，例如增加可用网络内存或减小网络缓冲池的配置大小。

有个现场的hadoop有问题，然后他们重建了Hadoop集群，但是flink运行一段时间就报错，主要报错ApplicationMaster is out of sync with ResourceManager, hence resyncing。这里看起来是Hadoop不稳定，然后ResourceManager不停的在切换主备状态，导致程序无法连接。故障转移尝试次数很高（例如，5278 次尝试），这表明系统无法与 ResourceManager 建立稳定连接。

但是这个异常又不影响程序运行。但是这个有什么影响呢？下面我来解释一下，这个是flink认证相关的，他说/tmp/jaas-3331740396007956723.conf 这个文件中不包含一个叫Client的配置。如果有的话，那么就会走认证相关的配置。如果你的环境没有开启kerbeos认证的话，那么是没有什么问题的。

这里按理说应该是返回我们的403，而且debug的时候，应该走到我们抛出AcessDeniedException异常的地方，但是实际上什么都没有调用，看起来没有到后端就被拦截了，跨域什么的。然后与前端约定，当出现这个异常的时候，我们把状态码改成403，然后前端发现是403的时候，统一跳转到登录界面。首先用户登录系统，然后查看数据，接口正常情况下，我们返回的是200状态码。然后这里触发了我，因为我是强制删除了缓存信息，是不是证书也被清理了呢？过了很久，都没有找到原因，而且界面看起来是跨域相关的报错。

每次出现这种错误，需要人工干预手动重启jobmanager才能解决，不然任务就不运行了。这个错误日志表明 Flink TaskManager 在向 ResourceManager 注册时超时，导致 TaskManager 被终止。具体来说，错误信息是，指示在规定的最大注册持续时间内无法在 ResourceManager 上完成注册。确保 TaskManager 能够与 ResourceManager 正常通信。检查网络配置，确保没有防火墙或其他网络问题导致通信中断。

一个K8S上部署的flink集群的问题，taskmanager运行一段时间pod就会error，报错日志是然后jobmanager中没有报错，只是有拒绝的提示这个报错也是Flink TaskManager 在向 ResourceManager 注册中间发生的错误。我前面刚刚排查了一个问题。

现在 Flink 中 Checkpoint 有两种模式，全量 Checkpoint 和增量 Checkpoint，其中全量 Checkpoint 会把当前的state 全部备份一次到持久化存储，而增量Checkpoint，则只备份上一次Checkpoint 中不存在的state，因此增量 Checkpoint 每次上传的内容会相对更好，在速度上会有更大的优势。对于 RocksDB 来说，则需要从本地读取文件，写入到远程的持久化存储上，所以不仅需要考虑网络的瓶颈，还需要考虑本地磁密的性能。

1. 细粒度滑动的影响当使用细粒度的滑动窗口 (窗口长度远远大于滑动步长）时，重叠的窗口过多，一个数据会属于多个窗口，性能会急剧下降。比如我们开了一天的窗口，滑动时间是1分钟，那么数据会有多少次重复呢？重复次数的计算是长度/ 步长。而且flink是每次回计算这个数据属于某个窗口，如果这个数据属于多个窗口中，那么这个数据会被放到多个状态中。在Spark中是有这样的优化的，比如如上图的重复，那么A窗口会正常计算，但是B窗口的计算是重叠的部分是会重复利用的。但是Flink目前没有办法做这个优化。

对对于实时的流式处理系统来说，我们需要关注数据输入、计算和输出的及时性，所以处理延迟是一个比较重要的监控指标，特别是在数据量大或者软硬件条件不佳的环境下。Flink提供了开箱即用的 LatencyMarker 机制来测量链路延迟。single：每个算子单独统计延迟；这个就是统计一个算子的验证，比如从A进入到A出去，这个一般没有多大意义。operator（默认值）：每个下游算子都统计自己与 Source 算子之间的延迟;相当于全局延迟，是比较有用的。subtask。

默认情况下，算子UID 是根据JobGraph 自动生成的，JobGraph 的更改可能会导致UUID 改变，手动指定算子UUID，可以让Flink 有效地将算子的状态从 savepoint 映射到作业修改后(拓扑图可能也有改变）的正确的算子上。严格地说，仅需要给有状态的算子设置就足的了。但是因为 Flink 的某些内置算子（如window）是有状态的，而有些是无状态的，可能用户不是很清楚哪些内置算子是有状态的，哪些不是所以从实践经验上来说，我们建议每个算子都指定上 UUID。

【Flink】Flink RocksDB 预定义优化合集。

RocksDB的参数有几百个，如果是没有一定基础的想做这个优化还是很难的，因此flink提供了一些预定义的配置合集，并且每个合集有固定的名称。Flink 针对不同的设置为 RocksDB 提供了一些预定义的选项集合,其中包含了后续提到的一些参数，如果调整预定义选项后还达不到预期，再去调整后面的 block、writebuffer等参数。

Flink 1.13 State 访问的性能监控，即latency trackig state。此功能不局限于 State Backend 的类型，自定义实现的 State Backend 也可以复用此功能。正常开启第一个参数即可。

这个跟上个问题一样，并没有统一的设置，要看实际情况自行设置。

那么按照我们现在的情况，我们一个taskmanager有2个槽位，那么应该是需要2个vcore。其实这是调度器引起的问题，我们要么使用容量调度器，要么使用公平调度器，如果你使用的是公平调度器那么应该不会遇到这个问题。然后现在就变成了4和10了，现在我们算一算这个怎么来的，3个TaskManager，每个占用3个，那么就是9个，然后JobManager是一个。我并行度是5，那么最少占用5个槽位才能跑，一个taskmanager是2个槽位，那么最少要启动3个taskmanager才能满足我们的需求。

距离上一次搞内存已经很久了，今天打算再次学一下。Flink 1.10对 Task Manager 内存模型做了较大改动Flink使用了堆上内存和堆外内存框架堆外内存、Task堆外内存、网络缓冲内存，都在堆外的直接内存里Flink使用内存=框架堆内和堆外内存+Task堆内和堆外内存 ＋网络缓冲内存＋管理内存逃程内存=Flink内存+JVM特有内存首先要知道一点就是FLink是既能使用堆内存、又能使用堆外内存的。

在Flink 当中有两种基本类型的State : Keyed State 和 Operator State。Keyed State：顾名思义就是基于 KeyedStream 上的状态，这个状态是跟特定的key 鄉定的，对 KeyedStream 流上的每一个key，都对应一个 state。如下图所示：假如输入流按照 id 为key 进行 keyBy 分组，形成一个 KeyedStream，数据流中所有id 为1的数据共享一个状态，可以访问和更新这个状态。以此类推，每个key 对应一个自己的状态。

今天有空来学习一下，可查询状态 Queryable State。在flink 当中．state 分为两种类型，keyed state 和 operator state。keyed state 是与特定的key 绑定的state。对keyedStream 流上的每一个key， 都对应一个 state;operator state 是与算子绑定的 state，整个operator 算子只对应一个 state。

其中， 是作业的 JobID，可以在 Flink 的 Web UI 或者日志中找到， 是 Savepoint 保存的目录。当执行 Flink 的 stop 命令并指定 --savepointPath 参数时，如果操作超时，可能是由于不同原因导致的。8.检查 Flink 的日志，特别是 JobManager 和 TaskManager 的日志，以查看是否有任何与 Savepoint 相关的错误或警告消息。有时，不同版本之间的兼容性问题可能导致异常。

flink on k8s吗，我在kubernetes application模式下运行，运行一段时间后就会出现这个报错，然后jobmanager就重启了。2、确保你的操作是基于最新版本的 ConfigMap 进行的，可以使用 kubectl get configmap 命令查看当前版本。这是一个 Kubernetes 的错误消息，意思是在进行 ConfigMap 操作时发生了锁定问题和版本冲突。4、对于持久性锁定问题，可以通过更新或重新部署相关的应用程序来解决。

一个环境flink读取kafka不消费数据或者偶然消费数据、消费组信息查不到。在数据源节点查看节点每秒消费速率为0，意味着没有消费数据查看topic内部topic都正常，下图为部分查看我们消费的目标topic也是正常的查看消费组信息最后一行为nuknow，这是我们自定义的，意思是查不到查看日志发现无报错信息给这个流新换一个消费组，因为不消费所以没有初始化消费组信息，我们也查不到但是后来不知道什么原因，偶然能消费数据了。

但是现场不知道哪个傻叉，配置了一个最简单的规则，然后导致所有的数据都产生告警了，然后当所有数据都是告警，然后这个流我们配置的消费能力不高，然后每秒产生了几十万的告警，那么查询的时候就发现时间一直没有变化，因为一秒内的数据都要好久才能消费完。这个延迟达到了几十亿，卧槽，最终破案了，原来我们这个是读取日志，然后分析日志，产生告警然后写入到Es,一般情况下，这个消费的数据多，然后生成的数据少，所以我们没有怀疑是延迟问题。因为我们已经是12月14日了，但是今天来查数据的时候，发现最新的数据还是16：48。

请注意，在生产环境中，你需要确保目标 Socket 服务器能够接收并处理来自 SocketClientSink 的数据，并根据需要进行相关的配置和验证。SocketClientSink 是 Flink 的一个输出连接器（sink），可以将数据发送到一个指定的 Socket 地址和端口。你将看到数据被发送到指定的 Socket 地址和端口，并在 Socket 服务器上接收到这些数据。在上面的示例中，我们创建了一个简单的数据流，并将数据发送到指定的 Socket 地址和端口。

flink 消费kafka,之前任务正常的，突然有个分区没法消费了，重启下任务久正常了。

这个的含义是：回滚到检查点/保存点的元数据失败。检查点/保存点状态与新程序之间的最大并行度不匹配。无法将最大并行度为32768的运算符58212cb79e8186067bdc9ae3681ec630映射到最大并行度为1的新程序。这表明在检查点之后以不兼容的方式更改了程序。最后问题发现：代码变更太多 不能读历史的保存点启动了。

我们有个现场，然后最近总是无缘无故不消费数据，看起来像是卡死了一样，但是日志里面有找不到报错，关键是刚刚启动任务是能消费的数据的，比如消费一段时间后，10分钟差不多的样子（大概消费了几十万数据），就开始无法消费数据了，我们修改消费组后，可以再次消费一段时间。后面经了解，由于kafka磁盘目录存储已满，故对kafka日志进行了清理，清理时使用命令对日志进行了清空操作。经我方研发运维测试发现，”echo”命令直接清理日志会导致任务启动失败。

本次也是这个环境，昨天还能运行，今天升级一下就不能运行了，报错如下本次原因是flink-dist版本冲突，版本使用的还是老的版本导致的。“Flink 启动报错 NoSuchFieldError EXECUTION_MODE” 这个错误通常表示您的 Flink 应用程序代码与您正在使用的 Flink 版本之间存在不兼容性。EXECUTION_MODE 是 Flink 中的一个字段，该字段可能在不同的 Flink 版本中发生了变化，导致了这个错误。

如果需要补充缺失的变更前事件，一个自然的思路是在 Flink 状态中缓存所有文档的当前版本快照；不过 Flink 框架会自动为 MongoDB 附加一个 Changelog Normalize 节点，补齐 update 事件的前镜像值（即 UPDATE_BEFORE 事件)，从而确保 CDC 数据的语义正确性。目前，Flink SQL Planner 会自动为 Upsert 类型的 Source 生成一个 ChangelogNormalize 节点，并按照上述操作将其转换为完整的变更流；

但是在默认的情况下，FlinkKafkaProducer011设置事务超时属性(transaction.timeout.ms)为1 hour, 超过默认transaction.max.timeout.ms15 minutes。因此在使用EXACTLY_ONCE语义的时候需要增大transaction.max.timeout.ms或者减小任务的transaction.timeout.ms的值。生产者设置事务超时不允许大于这个值，这个属性不允许为大于其值的。对应的kafka代码位置。

场景：flink checkpoint的时候报错，导致checkpoint失败，并报如下错误原因：由于flink写hdfs会导致很多小文件，尝试小文件合并的时候，误将正在写的小文件合并掉了。因此，flink将inprogress文件转为finished文件时，找不到原来的文件报错，导致checkpoint失败。解决：合并小文件时注意，正在写的小文件不能合并。