Flink Task退出流程与Failover机制

云服务器Checkpoint机制:存储、计算、网络与安全四重呼吸节律 Checkpoint是分布式系统中保障状态一致性的核心机制,本质是在时间维度上建立可恢复的‘记忆锚点’。其原理源于分布式共识协议(如Chandy-Lamport)与日志结构化设计(如WAL),技术价值在于实现EXACTLY_ONCE语义、支撑容错重启与时间点恢复。广泛应用于实时计算(Flink)、关系数据库(PostgreSQL)、渗透测试(HTB)及云原生网络状态管理等场景。本文深入解析Checkpoint在存储层的物理锚点、计算层的状态契约、网络层的连接守恒与安全层的权限快照四大落地形态,揭示其作为云服 阅读详情

1 TaskExecutor端Task退出逻辑

Task.doRun() 引导Task初始化并执行其相关代码的核心方法,
构造并实例化Task的可执行对象: AbstractInvokable invokable。
调用 AbstractInvokable.invoke() 开始启动Task包含的计算逻辑。
在这里插入图片描述
在这里插入图片描述

当AbstractInvokable.invoke()执行退出后,根据退出类型执行相应操作:

  1. 正常执行完毕退出:输出ResultPartition缓冲区数据,并关闭缓冲区,标记Task为Finished;
  2. 取消操作导致退出:标记Task为CANCELED,关闭用户代码;
  3. AbstractInvokable.invoke()执行过程中抛出异常退出:标记Task为FAILED,关闭用户代码,记录异常;
  4. AbstractInvokable.invoke()执行过程中JVM抛出错误:强制终止虚拟机,退出当前进程。

紧接着释放Task相关的网络、内存、文件系统资源。最后通过Task->TaskManager->JobMaster的传递链路将Task的终止状态通知给Leader JobMaster线程。

Task.notifyFinalState() -> TaskManagerActions.updateTaskExecutionState(TaskExecutionState) -> JobMasterGateway.updateTaskExecutionState(TaskExecutionState)

  • TaskExecutionState携带的关键信息:
TaskExecutionState {
    JobID // 任务ID
    ExecutionAttemptID  // Task执行的唯一ID,标示每次执行
    ExecutionState  // 枚举值,Task执行状态
    SerializedThrowable // 若Task抛出异常,该字段记录异常堆栈信息
    ...
}
  • Task 执行状态转换:
   CREATED  -> SCHEDULED -> DEPLOYING -> RUNNING -> FINISHED
      |            |            |          |
      |            |            |   +------+
      |            |            V   V
      |            |         CANCELLING -----+----> CANCELED
      |            |                         |
      |            +-------------------------+
      |
      |                                   ... -> FAILED
      V
  RECONCILING  -> RUNNING | FINISHED | CANCELED | FAILED

2 JobMaster端failover流程

2.1 Task Execute State Handle

JobMaster收到TaskManager通过rpc发送的task执行状态变更信息,将通知当前Flink作业的调度器(SchedulerNG)处理,因为都是通过同个线程调用,后续对ExecutionGraph(运行时执行计划)、failover计数等有状态实例的read/write操作都不会出现线程安全问题。

JobMaster的核心处理逻辑在SchedulerBase.updateTaskExecutionState(TaskExecutionStateTransition) 中(TaskExecutionStateTransition主要是TaskExecutionState的可读性封装)。
处理逻辑:尝试将收到的Task执行状态信息更新到ExecutionGraph中。若更新成功且target状态为FINISHED,根据具体的SchedulingStrategy实现策略,选择可消费的结果分区并调度相应的消费者Task;若更新成功且target状态为FAILED,进入具体的failover流程。

  • SchedulerBase.updateTaskExecutionState(TaskExecutionStateTransition) :
    public final boolean updateTaskExecutionState(
            final TaskExecutionStateTransition taskExecutionState) {
        final Optional<ExecutionVertexID> executionVertexId =
                getExecutionVertexId(taskExecutionState.getID());

        boolean updateSuccess = executionGraph.updateState(taskExecutionState);

        if (updateSuccess) {
            checkState(executionVertexId.isPresent());
            if (isNotifiable(executionVertexId.get(), taskExecutionState)) {
                updateTaskExecutionStateInternal(executionVertexId.get(), taskExecutionState);
            }
            return true;
        } else {
            return false;
        }
    }

  • ExecutionGraph.updateState(TaskExecutionStateTransition): 在当前的物理执行拓扑中找不到目标ExecutionAttemptID 时,将更新失败。需要注意的是这个ID用于唯一标示一个Execution,而Execution则代表ExecutionVertex(代表拓扑顶点的一个subTask计划)的一次执行实例,ExecutionVertex可以重复多次执行。这意味着当有subTask重新运行,currentExecutions将不再持有上一次执行的ID信息。
   /**
     * Updates the state of one of the ExecutionVertex's Execution attempts. If the new status if
     * "FINISHED", this also updates the accumulators.
     *
     * @param state The state update.
     * @return True, if the task update was properly applied, false, if the execution attempt was
     *     not found.
     */
    public boolean updateState(TaskExecutionStateTransition state) {
       assertRunningInJobMasterMainThread();
        final Execution attempt = currentExecutions.get(state.getID());
        if (attempt != null) {
            try {
                final boolean stateUpdated = updateStateInternal(state, attempt);
                maybeReleasePartitions(attempt);
                return stateUpdated;
            } catch (Throwable t) {
                ......
                return false;
            }
        } else {
            return false;
        }
    }

  • JobMaster: 负责一个任务拓扑的中心操作类,涉及作业调度,资源管理,对外通讯等…

  • SchedulerNG:负责调度作业拓扑。所有对该类对象方法的调用都会通过ComponentMainThreadExecutor触发,将不会出现并发调用的情况。

  • ExecutionGraph: 当前执行拓扑的中心数据结构,协调分布在各个节点上的Execution。描述了整个任务的各个SubTask及其分区数据,并与其保持通讯。

2.2 Job Failover

2.2.1 Task Failure Handle

  • Task异常的主要流程在 DefaultScheduler.handleTaskFailure(ExecutionVertexID, Throwable), 根据RestartBackoffTimeStrategy判断是重启还是failed-job;根据FailoverStrategy选择需要重启的SubTask;最后根据任务当前的SchedulingStrategy执行相应的调度策略重启相应的Subtask。
    private void handleTaskFailure(
            final ExecutionVertexID executionVertexId, @Nullable final Throwable error) {
        // 更新当前任务异常信息
        setGlobalFailureCause(error);
        // 如果相关的算子(source、sink)存在coordinator,同知其进一步操作
        notifyCoordinatorsAboutTaskFailure(executionVertexId, error);
        // 应用当前的restart-stratege并获取FailureHandlingResult
        final FailureHandlingResult failureHandlingResult =
                executionFailureHandler.getFailureHandlingResult(executionVertexId, error);
        // 根据结果重启Task或将任务失败
        maybeRestartTasks(failureHandlingResult);
    }


    public class FailureHandlingResult {
        //恢复所需要重启的所有SubTask
          Set<ExecutionVertexID> verticesToRestart;
        //重启延迟
          long restartDelayMS;
        //万恶之源
          Throwable error;
        //是否全局失败
          boolean globalFailure;
    }

  • ExecutionFailureHandler:处理异常信息,根据当前应用策略返回异常处理结果。
    public FailureHandlingResult getFailureHandlingResult(
            ExecutionVertexID failedTask, Throwable cause) {
        return handleFailure(
                cause, 
                failoverStrategy.getTasksNeedingRestart(failedTask, cause),  // 选择出需要重启的SubTask
                false); 
    }

    private FailureHandlingResult handleFailure(
            final Throwable cause,
            final Set<ExecutionVertexID> verticesToRestart,
            final boolean globalFailure) {

        if (isUnrecoverableError(cause)) {
            return FailureHandlingResult.unrecoverable(
                    new JobException("The failure is not recoverable", cause), globalFailure);
        }

        restartBackoffTimeStrategy.notifyFailure(cause);
        if (restartBackoffTimeStrategy.canRestart()) {
            numberOfRestarts++;

            return FailureHandlingResult.restartable(
                    verticesToRestart, restartBackoffTimeStrategy.getBackoffTime(), globalFailure);
        } else {
            return FailureHandlingResult.unrecoverable(
                    new JobException(
                            "Recovery is suppressed by " + restartBackoffTimeStrategy, cause),
                    globalFailure);
        }
    }

  • FailoverStrategy: 故障转移策略。

    • RestartAllFailoverStrategy: 使用该策略,当出现故障,将重启整个作业,即重启所有Subtask。
    • RestartPipelinedRegionFailoverStrategy:当出现故障,重启故障出现Subtask所在的的Region。
    • RestartBackoffTimeStrategy: 当Task发生故障时,决定是否重启以及重启的延迟时间。
  • FixedDelayRestartBackoffTimeStrategy:允许任务以指定延迟重启固定次数。

    • FailureRateRestartBackoffTimeStrategy:允许在固定失败频率内,以固定延迟重启。
    • NoRestartBackoffTimeStrategy:不重启。
  • SchedulingStrategy: Task执行实例的调度策略

    • EagerSchedulingStrategy: 饥饿调度,同时调度所有Task。
    • LazyFromSourcesSchedulingStrategy:当消费的分区数据都准备好后才开始调度其后续Task,用于批处理任务。
    • PipelinedRegionSchedulingStrategy:以pipline链接的Task为一个Region,作为其调度粒度。

2.2.2 Restart Task


    private void maybeRestartTasks(final FailureHandlingResult failureHandlingResult) {
        if (failureHandlingResult.canRestart()) {
            restartTasksWithDelay(failureHandlingResult);
        } else {
            failJob(failureHandlingResult.getError());
        }
    }

    private void restartTasksWithDelay(final FailureHandlingResult failureHandlingResult) {
        final Set<ExecutionVertexID> verticesToRestart =
                failureHandlingResult.getVerticesToRestart();

        final Set<ExecutionVertexVersion> executionVertexVersions =
                new HashSet<>(
                        executionVertexVersioner
                                .recordVertexModifications(verticesToRestart)
                                .values());
        final boolean globalRecovery = failureHandlingResult.isGlobalFailure();

        addVerticesToRestartPending(verticesToRestart);

        // 取消所有需要重启的SubTask
        final CompletableFuture<?> cancelFuture = cancelTasksAsync(verticesToRestart);

        delayExecutor.schedule(
                () ->
                        FutureUtils.assertNoException(
                                cancelFuture.thenRunAsync(   // 停止后才能重新启动
                                        restartTasks(executionVertexVersions, globalRecovery), 
                                        getMainThreadExecutor())),
                failureHandlingResult.getRestartDelayMS(),
                TimeUnit.MILLISECONDS);
    }


2.2.3 Cancel Task:

  • 取消正在等待Slot分配的SubTask,若已经处于部署/运行状态,则需要通知TaskExecutor执行停止操作并等待操作完成。
    private CompletableFuture<?> cancelTasksAsync(final Set<ExecutionVertexID> verticesToRestart) {
        // clean up all the related pending requests to avoid that immediately returned slot
        // is used to fulfill the pending requests of these tasks
        verticesToRestart.stream().forEach(executionSlotAllocator::cancel); // 取消可能正处于等待分配Slot的SubTask

        final List<CompletableFuture<?>> cancelFutures =
                verticesToRestart.stream()
                        .map(this::cancelExecutionVertex) // 开始停止SubTask
                        .collect(Collectors.toList());

        return FutureUtils.combineAll(cancelFutures);
    }

    public void cancel() {
        while (true) { // 状态变更失败则重试
            ExecutionState current = this.state;
            if (current == CANCELING || current == CANCELED) {
                // already taken care of, no need to cancel again
                return;
            }
            else if (current == RUNNING || current == DEPLOYING) {
                // 当前状态设为CANCELING,并向TaskExecutor发送RPC请求停止SubTask
                if (startCancelling(NUM_CANCEL_CALL_TRIES)) {
                    return;
                }
            } else if (current == FINISHED) {
                // 即使完成运行,后续也无法消费,释放分区结果
                sendReleaseIntermediateResultPartitionsRpcCall();
                return;
            } else if (current == FAILED) {
                return;
            } else if (current == CREATED || current == SCHEDULED) {
                // from here, we can directly switch to cancelled, because no task has been deployed
                if (cancelAtomically()) {
                    return;
                }
            } else {
                throw new IllegalStateException(current.name());
            }
        }
    }

  • 操作完毕后又会执行Task退出流程通知ExecutionGraph执行相应数据更新: ExecutionGraph.updateState(TaskExecutionStateTransition)->ExecutionGraph.updateStateInternal(TaskExecutionStateTransition, Execution) -> Execution.completeCancelling(…) -> Execution.finishCancellation(boolean) -> ExecutionGraph.deregisterExecution(Execution) 。在deregisterExecution操作会在currentExecutions中移除已停止的执行ExecutionTask。

2.2.4 Start Task

        private Runnable restartTasks(
                final Set<ExecutionVertexVersion> executionVertexVersions,
                final boolean isGlobalRecovery) {
            return () -> {
                final Set<ExecutionVertexID> verticesToRestart =
                        executionVertexVersioner.getUnmodifiedExecutionVertices(
                                executionVertexVersions);
    
                removeVerticesFromRestartPending(verticesToRestart);
                // 实例化新的SubTask执行实例(Execution)
                resetForNewExecutions(verticesToRestart);
    
                try {
                    // 恢复状态
                    restoreState(verticesToRestart, isGlobalRecovery);
                } catch (Throwable t) {
                    handleGlobalFailure(t);
                    return;
                }
                // 开始调度,申请Slot并部署
                schedulingStrategy.restartTasks(verticesToRestart);
            };
        }

3 Task失败的自动重启策略

Task 级别的故障重启,是系统自动进行的;

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

实时计算框架选型决策地图:Hadoop、Storm、Spark、Flink、Samza深度对比 实时计算是现代数据架构的核心能力,其本质是时间语义、状态管理与容错机制的协同设计。从批处理(Hadoop)到低延迟流式(Storm),再到统一引擎(Spark)和原生流处理(Flink),不同框架代表差异化的‘时间观’与工程权衡。Hadoop提供高吞吐存储与YARN资源调度基础;Storm以亚毫秒级响应适配事件驱动场景;Spark凭借SQL兼容性与批流双模降低开发门槛;Flink通过精确一次(exactly-once)状态一致性支撑金融级实时风控;Samza则深度绑定Kafka实现轻量状态恢复。技术选型不应 阅读详情

相关推荐

【Flink实战系列】Flink 任务发生 failover 的常见原因及解决办法

在生产环境中,经常会遇到 Flink 任务发生 failover ,发生 failover 的原因有很多,今天就来总结一下常见的几种情况 资源不足问题 2022-02-09 10:22:18​ org.apache.flink.runtime.jobmanager.scheduler.NoResourceAvailableException: Could not allocate all requires slots within timeout of 300000 ms. Slots required:.

JasonLee实时计算 2498

flink任务失败restart策略和failover策略

一、restart策略 Flink在任务失败恢复重启时支持多种重启策略,同时配置支持两个级别,可以通过设置flink全局配置文件flink-conf.yaml来指定全局重启策略,也可以通过编程的方式指定单个job的重启策略,极端情况下可以为每一个任务都指定一个重启策略;一般情况下,编程方式指定的单个job重启策略会将全局策略覆盖。 在检查点机制未开启的情况下,flink默认会采取No Restart Strategy策略,即失败不重启;在检查点机制开启状态下,默认会采取Fixed Delay Resta

赶路人儿 7576

空0025

25。

Direction_Wind的博客 1222

Flink——Task退出流程与Failover机制

Flink——Task退出流程与Failover机制 目录Flink——Task退出流程与Failover机制1 TaskExecutor端Task退出逻辑2 JobMaster端failover流程2.1 Task Execute State Handle2.2 Job Failover2.2.1 Task Failure Handle2.2.2 Restart Task2.2.3 Cancel Task:2.2.4 Start Task 1 TaskExecutor端Task退出逻辑 Task.doRu

qq_30708747的博客 3208

Flink / Kafka 异常 - 6.Recovery is suppressed by FixedDelayRestartBackoffTimeStrategy 排查与修复

使用 Flink - Kafka 接数据 Source 时程序报错:org.apache.flink.runtime.JobException: Recovery is suppressed by FixedDelayRestartBackoffTimeStrategy,任务每次启动后持续10min左右,然后 RUNNING -> FAILED,如此重启失败了多次。

BITDDD小栈 6234

【Flink】故障恢复和重启策略

Flink在实际运行环境中,我们会遇到各种各样的问题从而导致应用挂掉,例如异常数据,网络抖动,连接第三方中间件失败。 为解决这一问题,Flink 提供了强大的可配置故障恢复和重启策略来进行自动恢复。Flink客户端在conf目录下flink-conf.yaml种定义了 jobmanager.execution.failover-strategy,如下图所示 jobmanager.execution.failover-strategy 的可配置项有两种...

一杯咖啡半杯糖的博客 5347

深入理解 Flink 容错机制

本文作者:Paul Lin本文链接:2019/07/28/深入理解-Flink-容错机制/版权声明:本博客所有文章除特别声明外,均采用 CC BY-NC-SA 3.0 CN 许可协议。...

张普的专栏 879

Agisoft Metashape相机标定笔记

使用Metashape进行自动相机标定是可能的。(可选:使用打印的棋盘格图案,但需保证它是平坦的且单元格是正方形)。相机标定步骤支持全相机标定矩阵的估计,包含非线性的畸变参数。相机模型的细节请参照附录D——相机模型板块。:在通用的工作流程中,相机标定步骤可以跳过。因为Metashape会在图像定向过程中进行相机自标定。但是,如果定向结果不稳定,例如,由于影像之间缺乏连接点,额外进行单独的相机标定步骤也许是有用的。

天桥飞熊的博客 3981

Flink(四十一)—— 深入理解 Flink 容错机制

作为分布式系统,尤其是对延迟敏感的实时计算引擎,Apache Flink 需要有强大的容错机制,以确保在出现机器故障或网络分区等不可预知的问题时可以快速自动恢复并依旧能产生准确的计算结果。事实上,Flink 有一套先进的快照机制来持久化作业状态[1],确保中间数据不会丢失,这通常需要和错误恢复机制(作业重启策略或 failover 策略)配合使用。在遇到错误时,Flink 作业会根据重启策略自动重启并从最近一个成功的快照(checkpoint)恢复状态。合适的重启策略可以减少作业不可用时间和避免人工介入处理

weixin_42073629的博客 1008

uCOS中的消息邮箱(:task与task之间传递一个数据(数据缓冲区))

程序需求,需要完成task与task之间  字符数组的数据传输 比如:在ucos中,串口2接收的字符数组是不定时的&不定长的;只有当接收到数据的时候_才将数据赋值给新数组 具体的程序示意如下: 图1:消息邮箱测试中的     向消息邮箱发送消息(OSMboxPost(Str_Box,(void*)rec);//发送消息--(向 消息邮箱_msg_key发送消息) ),实际项目需求的

faguoduifangui的博客 4540

DOSBOX 0.74模拟器安装Windows 95

DosBox本身带有5.0版的DOS系统,启动后虚拟一个Z盘存放有Dosbox特有的外部指令,如config.com、imgmount.com等,经测试,可以顺利安装各版本的windows 3.1系统,但是不能安装win95,需要用原版的dos镜像启动才能安装。1. 获取启动盘镜像文件 下载Win95启动软盘镜像文件,名为boot.img,放到DosBox 0.74的目录下。2. 制作硬盘镜像文件

xjnzhidao的博客 9313

flink 三种时间机制_深入理解 Flink 容错机制

本文由来自网易游戏的林小铂(社区ID:Paul Lam)投稿,文章质量很高,欢迎阅读。 作为分布式系统,尤其是对延迟敏感的实时计算引擎,Apache Flink 需要有强大的容错机制,以确保在出现机器故障或网络分区等不可预知的问题时可以快速自动恢复并依旧能产生准确的计算结果。事实上,Flink 有一套先进的快照机制来持久化作业状态[1],确保中间数据不会丢失,这通常需要和错误恢复机制(作...

weixin_29022115的博客 330

Spatio-Temporal Graph Convolutional Networks: A Deep Learning Framework for Traffic Forecasting 论文笔记

Spatio-Temporal Graph Convolutional Networks: A Deep Learning Framework for Traffic Forecasting 论文笔记-----GCN在交通领域的应用(二) 一、论文翻译: 1、摘要: 及时准确地交通预测对于城市交通控制和指导具有至关重要的意义。由于交通流量的非线性和复杂性,传统的方法不能满足中长期预测任务的需求,并且往往会忽略时空数据的时间和空间依赖特性。在这篇论文中,为了处理在交通领域的时间序列预测问题...

cy_believ的博客 1916

Flink的容错机制了解

本文介绍下Flink的容错机制,目的主要是了解下如果Flink环境发生异常,会不会对计算结果造成影响。 JobManager的容错: Flink JobManager的HA仅支持StandAlone和Yarn Cluster两种集群模式。 StandAlone和Yarn Cluster模式下的HA实现方式各不相同: Standalone 集群的 JobManager 高可用性的概念是,任何时候都有一个主 JobManager 和 多个备 JobManagers,在主JobM...

淡定一生2333的博客 1977

OPC DCOM详细配置方法 - 不关防火墙不换登陆用户

1. 前言   OPC DCOM的设置是实现跨网络OPC通信的基础,现有的一些OPC DCOM配置教程虽然讲解了如何配置DCOM,但没有讲清楚为什么要这么做,而且各个教程涉及的配置方法也不尽相同。   为了彻底搞清楚OPC DCOM的配置过程,我重新做了两台机器的系统,一台是Windows 7 32位,一台是Windows 10 64位,并且重零开始完整的测试了正常运行OPC DCOM所需的最少的...

steventian72的博客 3万+

三维重建笔记_光束平差法(Bundle Adjustment, BA)

目录 1 光束平差法(Bundle Adjustment, BA) 1.1 SFM (Structure‐from‐Motion) 定义 问题描述 1.2 重投影误差 (Reprojection Error) 目标函数 1.3 使用 Levenberg‐Marquardt Algorithm 进行优化 问题描述 简化目标函数 参考 Gauss‐Newton Method ...

惊鸿一博 2万+

带你认识Flink容错机制的两大方面:作业执行和守护进程

摘要:Flink 容错机制主要有作业执行的容错以及守护进程的容错两方面,前者包括 Flink runtime 的 ExecutionGraph 和Execution的容错,后者则包括 JobManager 和 TaskManager 的容错。

华为云官方博客 4558

STM32硬件SPI驱动W5500以太网模块全流程(附避坑指南)

本文详细介绍了STM32硬件SPI驱动W5500以太网模块的全流程,包括硬件架构设计、SPI接口选型、官方驱动移植、网络协议栈配置与优化等关键步骤。通过实战案例和性能对比数据,帮助开发者快速实现稳定高效的网络连接,特别提供了常见问题排查指南和性能调优技巧。

weixin_29194693的博客 269

大数据开发:Flink作业执行容错机制

对于实时计算引擎而言,可靠的容错机制是非常关键的,在面对各种可能出现的故障和不可预知的问题时,容错机制能够确保快速恢复并产生准确的计算结果,这是非常重要的。今天的大数据开发分享,我们来讲讲Flink在作业执行层面的容错机制。 Flink作业执行的容错,通常来说,包括Flink runtime的ExecutionGraph和Execution的容错。Flink作业执行容错 众所周知,用户使用Flink编程API(DataStream/DataSet/Table/SQL)编写的作业最终会被翻译为JobGraph

shuimuzh123的博客 241

lvgl 9虚拟键盘控件 (lv_keyboard) 使用指南

是 LittlevGL 提供的一个虚拟键盘控件,适用于在图形界面中输入文本。与按钮矩阵类似,虚拟键盘预定义了多个键位布局,支持多种模式和自定义键位映射,能够满足各种文本输入需求。通过与文本区域 (Text Area) 的结合,键盘能够自动将输入的字符传送到指定区域。控件是 LittlevGL 提供的强大虚拟键盘解决方案,适用于任何需要文本输入的界面。通过预定义的键盘模式、自定义键位映射和文本区域自动填充功能,可以大大提升用户输入体验。无论是在嵌入式系统的用户界面中,还是在其他需要虚拟键盘的应用中,

m0_62599305的博客 2187

win10 跳过U8环境检测的IE WebControls.rar

win10 安装u8的时候 提示IE WebControls 不通过,这个工具可以欺骗u8的检查。 跳过U8环境检测的IE WebControls。提示导入失败后,重新检测通过。

Flink Run time解析

整体架构 以上是flink的整体架构,今天我们一起来学习一下Flink的Runtime这一层。 Runtime架构 这个是runtime的架构,基本上一目了然。 图中可以看到, 1.client向cluster Management(standalone、yarn、messos、K8S)提交app请求。同时,client也会完成作业的编译以及优化的过程,譬如哪些task可以连在一...

lvwenyuan_1的博客 746

STM32F407中文手册

STM32f407中文手册 本参考手册面向应用开发人员,提供有关使用 STM32F405xx/07xx、STM32F415xx/17xx、 STM32F42xxx 和 STM32F43xxx 微控制器存储器与外设的完整信息。STM32F405xx/07xx、STM32F415xx/17xx、STM32F42xxx 和 STM32F43xxx 构成一个微 控制器系列,各产品具有不同的存储器大小、封装和外设。有关订购信息以及器件的机械与电气特性,请参见数据手册。有关 ARM Cortex™-M4F 内核的信息,请参见《Cortex™-M4F 技术参考手册》。

Flink重启策略(restart-strategy)优化

Flink重启策略(restart-strategy)优化 indexFlink重启策略(restart-strategy)优化背景问题分析结论优化 背景 1、实时任务依赖Zookeeper做高可用,当Zookeeper节点重启,会导致相当一部分任务挂掉; 2、依赖DCache、HBase这类外部系统的任务,稳定性较差,当外部系统抖动很容易就导致任务运行失败。 理想情况下,我们希望在外部依赖出现波动时,任务能重新连接/连接其他服务节点,而实际上,Flink本身也提供了任务自动重启的支持,我们默认使用的是fa

qq_30708747的博客 1922

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

Apache Flink 入门 (第三篇)(在YARN上运行Flink任务)

运行 Flink 应用 1. 基本概念 运行 Flink 应用其实非常简单,但是在运行 Flink 应用之前,还是有必要了解 Flink 运行时的各个组件,因为这涉及到 Flink 应用的配置问题。 下图所示,这是用户用 DataStream API 写的一个数据处理程序。可以看到,在一个 DAG 图中不能被 Chain 在一起的 Operator 会被分隔到不同的 Task 中,也就是说 Task 是 Flink 中资源调度的最小单位。 Flink 实际运行时包括两类进程: JobManager(又

zhiwen 1017
上一篇: flink sql 实战实例 及延伸问题:聚合/数据倾斜/DAU/Hive流批一体 等
下一篇: Flink Sql 自定义实现 kudu connector
Direction_Wind
博客等级 码龄8年 6438粉丝 102原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Direction_Wind

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值