汕头网站优化找谁seo免费诊断联系方式

当前位置： 首页 > news >正文

汕头网站优化找谁,seo免费诊断联系方式,wordpress考试插件,更新wordpressFlink 详解#xff08;二#xff09;#xff1a;核心篇 Ⅲ 29、Flink 通过什么实现可靠的容错机制#xff1f; Flink 使用 轻量级分布式快照#xff0c;设计检查点#xff08;checkpoint#xff09;实现可靠容错。 30、什么是 Checkpoin 检查点#xff1f; Checkpoint … Flink 详解二核心篇 Ⅲ 29、Flink 通过什么实现可靠的容错机制 Flink 使用 轻量级分布式快照设计检查点checkpoint实现可靠容错。 30、什么是 Checkpoin 检查点 Checkpoint 被叫做 检查点是 Flink 实现容错机制最核心的功能是 Flink 可靠性的基石它能够根据配置周期性地基于 Stream 中各个 Operator 的 状态 来生成 Snapshot 快照从而将这些状态数据定期持久化存储下来当 Flink 程序一旦意外崩溃时重新运行程序时可以有选择地从这些 Snapshot 进行恢复从而修正因为故障带来的程序数据状态中断。 Flink 的 Checkpoint 机制原理来自 Chandy-Lamport algorithm 算法一种分布式快照算法。 注意区分 State 和 Checkpoint 1.State 一般指一个具体的 Task/Operator 的状态Operator 的状态表示一些算子在运行的过程中会产生的一些中间结果。State 数据默认保存在 Java 的堆内存中 / TaskManage 节点的内存中。State 可以被记录在失败的情况下数据还可以恢复。 2.Checkpoint 表示了一个 FlinkJob 在一个特定时刻的一份全局状态快照即包含了所有 Task/Operator 的状态。 可以理解为 Checkpoint 是把 State 数据定时持久化存储了。 比如 KafkaConsumer 算子中维护的 Offset 状态当任务重新恢复的时候可以从 Checkpoint 中获取。 31、什么是 Savepoint 保存点 保存点 在 Flink 中叫作 Savepoint是基于 Flink 检查点机制的应用完整快照备份机制用来保存状态可以在另一个集群或者另一个时间点从保存的状态中将作业恢复回来。适用于 应用升级、集群迁移、 Flink 集群版本更新、A/B 测试 以及 假定场景、暂停和重启、归档 等场景。保存点可以视为一个算子 ID → State的 Map对于每一个有状态的算子Key 是算子 IDValue 是算子 State。 32、什么是 CheckpointCoordinator 检查点协调器 Flink 中检查点协调器叫作 CheckpointCoordinator负责协调 Flink 算子的 State 的分布式快照。当触发快照的时候CheckpointCoordinator 向 Source 算子中注入 Barrier 消息 然后等待所有的 Task 通知检查点确认完成同时持有所有 Task 在确认完成消息中上报的 State 句柄。 33、Checkpoint 中保存的是什么信息 检查点里面到底保存着什么信息呢我们以 Flink 消费 Kafka 数据 Wordcount 为例 1、我们从 Kafka 读取到一条条的日志从日志中解析出 app_id然后将统计的结果放到内存中一个 Map 集合app_id 做为 key对应的 pv 做为 value每次只需要将相应 app_id 的 pv 值 1 1 1 后 put 到 Map 中即可 2、kafka topictest 3、Flink 运算流程如下 kafka topic 有且只有一个分区。 假设 kafka 的 topic-test 只有一个分区flink 的 Source task 记录了当前消费到 kafka test topic 的所有 partition 的 offset。 例01000表示 0 号 partition 目前消费到 offset 为 1000 的数据。Flink 的 pv task 记录了当前计算的各 app 的 pv 值为了方便讲解我这里有两个 appapp1、app2。 例app150000app210000 表示 app1 当前 pv 值为 50000 表示 app2 当前 pv 值为 10000 每来一条数据只需要确定相应 app_id将相应的 value 值 1 后 put 到 map 中即可。该案例中CheckPoint 保存的其实就是 第 n 次 CheckPoint 消费的 offset 信息和各 app 的 pv 值信息记录一下发生 CheckPoint 当前的状态信息并将该状态信息保存到相应的状态后端。图下代码注状态后端是保存状态的地方决定状态如何保存如何保障状态高可用我们只需要知道我们能从状态后端拿到 offset 信息和 pv 信息即可。状态后端必须是高可用的否则我们的状态后端经常出现故障会导致无法通过 checkpoint 来恢复我们的应用程序。 chk-100 offset01000 pvapp150000app210000 该状态信息表示第 100 次 CheckPoint 的时候 partition 0 offset 消费到了 1000pv 统计。34、当作业失败后检查点如何恢复作业 Flink 提供了 应用自动恢复机制 和 手动作业恢复机制。 1、应用自动恢复机制 Flink 设置有作业失败重启策略包含三种 定期恢复策略fixed-delay固定延迟重启策略会尝试一个给定的次数来重启 Job如果超过最大的重启次数Job 最终将失败在连续两次重启尝试之间重启策略会等待一个固定时间默认 Integer.MAX_VALUE 次。 失败比率策略failure-rate失败比率重启策略在 Job 失败后重启但是超过失败率后Job 会最终被认定失败在两个连续的重启尝试之间重启策略会等待一个固定的时间。 直接失败策略None失败不重启。
2、手动作业恢复机制 因为 Flink 检查点目录分别对应的是 JobId每通过 flink run 方式 / 页面提交方式恢复都会重新生成 JobIdFlink 提供了在启动之时通过设置 -s 参数指定检查点目录的功能让新的 Jobld 读取该检查点元文件信息和状态信息从而达到指定时间节点启动作业的目的。 启动方式如下 /bin/flink -s /flink/checkpoints/03112312a12398740a87393/chk-50/_metadata35、当作业失败后从保存点如何恢复作业 从保存点恢复作业并不简单尤其是在作业变更如修改逻辑、修复 Bug的情况下 需要考虑如下几点: 算子的顺序改变。如果对应的 UID 没变则可以恢复如果对应的 UID 变了恢复失败。作业中添加了新的算子。如果是无状态算子没有影响可以正常恢复如果是有状态的算子跟无状态的算子一样处理。从作业中删除了一个有状态的算子。默认需要恢复保存点中所记录的所有算子的状态如果删除了一个有状态的算子从保存点恢复的时候被删除的 OperatorID 找不到所以会报错可以通过在命令中添加 –allowNonReStoredSlale(short: -n) 跳过无法恢复的算子 。添加和删除无状态的算子。如果手动设置了 UID 则可以恢复保存点中不记录无状态的算子。如果是自动分配的 UID 那么有状态算子的可能会变Flink 一个单调递增的计数器生成 UIDDAG 改变计数器极有可能会变很有可能恢复失败。 36、Flink 如何实现轻量级异步分布式快照 要实现分布式快照最关键的是能够将数据流切分。Flink 中使用 屏障Barrier来切分数据流。 Barrierr 会周期性地注入数据流中作为数据流的一部分从上游到下游被算子处理。Barrier 会严格保证顺序不会超过其前边的数据。Barrier 将记录分割成记录集两个 Barrier 之间的数据流中的数据隶属于同一个检查点。每一个 Barrier 都携带一个其所属快照的 ID 编号。Barrier 随着数据向下流动不会打断数据流因此非常轻量。 在一个数据流中可能会存在多个隶属于不同快照的 Barrier 并发异步地执行分布式快照如下图所示 Barrier 会在数据流源头被注人并行数据流中。Barrier n n n 所在的位置就是恢复时数据重新处理的起始位置。 例如在 Kafka 中这个位置就是最后一个记录在分区内的偏移量offset作业恢复时会根据这个位置从这个偏移量之后向 Kafka 请求数据这个偏移量就是 State 中保存的内容之一。 Barrier 接着向下游传递。当一个非数据源算子从所有的输入流中收到了快照 n n n 的 Barrier 时该算子就会对自己的 State 保存快照并向自己的下游 广播发送 快照 n n n 的 Barrier。一旦 Sink 算子接收到 Barrier有两种情况 如果是引擎内严格一次处理保证当 Sink 算子已经收到了所有上游的 Barrie n n n 时 Sink 算子对自己的 State 进行快照然后通知检查点协调器CheckpointCoordinator。当所有的算子都向检查点协调器汇报成功之后检查点协调器向所有的算子确认本次快照完成。如果是端到端严格一次处理保证当 Sink 算子已经收到了所有上游的 Barrie n n n 时 Sink 算子对自己的 State 进行快照并 预提交事务两阶段提交的第一阶段再通知检查点协调器CheckpointCoordinator检查点协调器向所有的算子确认本次快照完成Sink 算子 提交事务两阶段提交的第二阶段本次事务完成。 我们接着 33 33 33 的案例来具体说一下如何执行分布式快照 对应到 pv 案例中就是Source Task 接收到 JobManager 的编号为 chk-100从最近一次恢复的 CheckPoint 触发请求后发现自己恰好接收到 Kafka offset(0,1000) 处的数据所以会往 offset(0,1000) 数据之后offset(0,1001) 数据之前安插一个 Barrier然后自己开始做快照也就是将 offset(0,1000) 保存到状态后端 chk-100 中。然后 Barrier 接着往下游发送当统计 pv 的 task 接收到 Barrier 后也会暂停处理数据将自己内存中保存的 pv 信息 (app150000)、(app210000) 保存到状态后端 chk-100 中。OKFlink 大概就是通过这个原理来保存快照的。 统计 pv 的 task 接收到 Barrier就意味着 Barrier 之前的数据都处理了所以说不会出现丢数据的情况。 37、什么是 Barrier 对齐 上图从左至右分别表示开始对齐对齐执行检查点继续处理数据。 一旦 operator 从输入流接收到 checkpoint barrier n n n它就不能处理来自该流的任何数据记录直到它从其他所有输入接收到 barrier n n n 为止。否则它会混合属于快照 n n n 的记录和属于快照 n 1 n 1 n1 的记录 如上图所示 图 1 1 1算子收到数字流的 Barrier字母流对应的 Barrier 尚未到达。图 2 2 2算子收到数字流的 Barrier会继续从数字流中接收数据但这些流只能被搁置记录不能被处理而是放入缓存中等待字母流 Barrier 到达。在字母流到达前 1 、 2 、 3 1、2、3 1、2、3 数据已经被缓存。图 3 3 3字母流到达算子开始对齐 State 进行异步快照并将 Barrier 向下游广播并不等待快照执行完毕。图 4 4 4算子做异步快照首先处理缓存中积压数据然后再从输入通道中获取数据。 38、什么是 Barrier 不对齐 Checkpoint 是要等到所有的 Barrier 全部都到才算完成。 上述图 2 2 2 中当还有其他输入流的 Barrier 还没有到达时会把已到达的 Barrier 之后的数据 1 、 2 、 3 1、2、3 1、2、3 搁置在缓冲区等待其他流的 Barrier 到达后才能处理。 Barrier 不对齐就是指当还有其他流的 Barrier 还没到达时为了不影响性能也不用理会直接处理 Barrier 之后的数据。等到所有流的 Barrier 的都到达后就可以对该 Operator 做 Checkpoint 了。 39、为什么要进行 Barrier 对齐不对齐到底行不行 Exactly Once 时必须 Barrier 对齐如果 Barrier 不对齐就变成了 At Least Once。 Checkpoint 的目的就是为了保存快照如果不对齐那么在 chk-100 快照之前已经处理了一些 chk-100 对应的 offset 之后的数据当程序从 chk-100 恢复任务时chk-100 对应的 offset 之后的数据还会被处理一次所以就出现了重复消费。 41、要实现 Exactly-Once 需具备什么条件 流系统要实现 Exactly-Once需要保证上游 Source 层、中间计算层和下游 Sink 层三部分同时满足端到端严格一次处理如下图 Source 端数据从上游进入 Flink必须保证消息严格一次消费。同时 Source 端必须满足可重放replay。否则 Flink 计算层收到消息后未计算却发生 failure 而重启消息就会丢失。 Flink 计算层利用 Checkpoint 机制把状态数据定期持久化存储下来Flink 程序一旦发生故障的时候可以选择状态点恢复避免数据的丢失、重复。 Sink 端Flink 将处理完的数据发送到 Sink 端时通过 两阶段提交协议 即 TwoPhaseCommitSinkFunction 函数。该 SinkFunction 提取并封装了两阶段提交协议中的公共逻辑保证 Flink 发送 Sink 端时实现严格一次处理语义。同时Sink 端必须支持事务机制能够进行数据回滚或者满足幂等性。 回滚机制即当作业失败后能够将部分写入的结果回滚到之前写入的状态。幂等性就是一个相同的操作无论重复多少次造成的结果和只操作一次相等。即当作业失败后写入部分结果但是当重新写入全部结果时不会带来负面结果重复写入不会带来错误结果。 42、什么是两阶段提交协议 两阶段提交协议Two-Phase Commit2PC是解决分布式事务问题最常用的方法它可以保证在分布式事务中要么所有参与进程都提交事务要么都取消即实现 A C I D ACID ACID 中的 A A A原子性。 两阶段提交协议中有两个重要角色协调者Coordinator和 参与者Participant其中协调者只有一个起到分布式事务的协调管理作用参与者有多个。 两阶段提交阶段分为两个阶段投票阶段Voting和 提交阶段Commit。 1投票阶段 协调者向所有参与者发送 prepare 请求和事务内容询问是否可以准备事务提交等待参与者的响应。参与者执行事务中包含的操作并记录 undo 日志用于回滚和 redo 日志用于重放但不真正提交。参与者向协调者返回事务操作的执行结果执行成功返回 yes失败返回 no。 2提交阶段 分为成功与失败两种情况。若所有参与者都返回 yes说明事务可以提交 协调者向所有参与者发送 commit 请求。参与者收到 commit 请求后将事务真正地提交上去并释放占用的事务资源并向协调者返回 ack。协调者收到所有参与者的 ack 消息事务成功完成如下图 若有参与者返回 no 或者超时未返回说明事务中断需要回滚 协调者向所有参与者发送 rollback 请求。参与者收到 rollback 请求后根据 undo 日志回滚到事务执行前的状态释放占用的事务资源并向协调者返回 ack。协调者收到所有参与者的 ack 消息事务回滚完成。 43、Flink 如何保证 Exactly-Once 语义 Flink 通过 两阶段提交协议 来保证 Exactly-Once 语义。 对于 Source 端Source 端严格一次处理比较简单因为数据要进入 Flink 中所以 Flink 只需要保存消费数据的偏移量offset即可。如果 Source 端为 KafkaFlink 将 Kafka Consumer 作为 Source可以将偏移量保存下来如果后续任务出现了故障恢复的时候可以由连接器重置偏移量重新消费数据保证一致性。 对于 Sink 端Sink 端是最复杂的因为数据是落地到其他系统上的数据一旦离开 Flink 之后Flink 就监控不到这些数据了所以严格一次处理语义必须也要应用于 Flink 写入数据的外部系统故这些外部系统必须提供一种手段允许提交或回滚这些写入操作同时还要保证与 Flink Checkpoint 能够协调使用Kafka 0.11 0.11 0.11 版本已经实现精确一次处理语义。 我们以 Kafka - Flink - Kafka 为例 说明如何保证 Exactly-Once 语义。 如上图所示Flink 作业包含以下算子。 一个 Source 算子从 Kafka 中读取数据即 KafkaConsumer一个窗口算子基于时间窗口化的聚合运算即 windowwindow 函数一个 Sink 算子将结果写会到 Kafka即 KafkaProducer Flink 使用 两阶段提交协议即 预提交Pre-commit阶段和 提交Commit阶段保证端到端严格一次。 1、预提交阶段 1当 Checkpoint 启动时进入预提交阶段JobManager 向 Source Task 注入检查点分界线CheckpointBarrierSource Task 将 CheckpointBarrier 插入数据流向下游广播开启本次快照如下图所示 2Source 端Flink Data Source 负责保存 KafkaTopic 的 offset 偏移量当 Checkpoint 成功时 Flink 负责提交这些写入否则就终止取消掉它们当 Checkpoint 完成位移保存它会将 Checkpoint Barrier检查点分界线 传给下一个 Operator然后每个算子会对当前的状态做个快照保存到 状态后端State Backend。 对于 Source 任务而言就会把当前的 offset 作为状态保存起来。下次从 Checkpoint 恢复时Source 任务可以重新提交偏移量从上次保存的位置开始重新消费数据如下图所示 3Slink 端从 Source 端开始每个内部的 Transformation 任务遇到 Checkpoint Barrier检查点分界线时都会把状态存到 Checkpoint 里。数据处理完毕到 Sink 端时Sink 任务首先把数据写入外部 Kafka这些数据都属于预提交的事务还不能被消费此时的 Pre-commit 预提交阶段下 Data Sink 在保存状态到状态后端的同时还必须预提交它的外部事务如下图所示 2、提交阶段 4当所有算子任务的快照完成所有创建的快照都被视为是 Checkpoint 的一部分也就是这次的 Checkpoint 完成时JobManager 会向所有任务发通知确认这次 Checkpoint 完成此时 Pre-commit 预提交阶段才算完成。才正式到两阶段提交协议的第二个阶段Commit 阶段。该阶段中 JobManager 会为应用中每个 Operator 发起 Checkpoint 已完成的回调逻辑。 本例中的 Data Source 和窗口操作无外部状态因此在该阶段这两个 Opeartor 无需执行任何逻辑但是 Data Sink 是有外部状态的此时我们必须提交外部事务当 Sink 任务收到确认通知就会正式提交之前的事务Kafka 中未确认的数据就改为 “已确认”数据就真正可以被消费了如下图所示 注Flink 由 JobManager 协调各个 TaskManager 进行 Checkpoint 存储Checkpoint 保存在 StateBackend状态后端 中默认 StateBackend 是内存级的也可以改为文件级的进行持久化保存。 44、数的很好很清楚那你对 Flink 端到端 严格一次 Exactly-Once 语义做个总结。