精华内容
下载资源
问答
  • 停止点检查记录
    千次阅读
    2021-12-22 10:28:47

    办公室一台电脑的共享打印机突然无法打印,提示打印服务已停止,打开服务发现print spooler服务已经停止,同时打印机列表中打印机记录也全部消失。右键启动服务,打印机列表出现,但是刷新后发现print spooler服务又已经停止。

    根据网上的解决方法,有人认为是打印服务的注册表被第三方软件干扰,更改了注册表的键值,导致打印服务被停止。解决方法如下:

      开始->运行,输入regedit打开注册表编辑器

      找到以下键值:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Spooler

      选定Spooler这个文件夹,在右边窗口里找DependOnService这个键值

      双击打开,里面多了个HTTP,把数据改为RPCSS,确定后退出注册表编辑器,重启计算机。


    按照此方法解决后,发现print spooler服务依然会自动停止,对比打印服务正常电脑的注册表发现键值为PRCSS HTTP。所以说明这个键值被修改不是导致print spooler服务自动停止的原因。

    网上还有其他解决方法,具体如下:

    (1)删除 C:\WINDOWS\system32\spool\PRINTERS 目录下的所有文件,因为正常的电脑此文件夹为空。

    (2)点击运行,输入regedit,找到注册表编辑器,点击删除

    HKEY_LOCAL_MACHINE\SYSTEM\ControlSetoo1\Control\Print\Printers

    目录下的所需要打印机。

    (3)重启电脑,再次找到Print Spooler,确定其已启动。

    (4)重新安装所需要的打印机。


    尝试后未解决问题,print spooler服务依然会自动停止。

    找不到原因的情况下,无奈重装了系统,可是在重装之后,再次出现该问题,说明此问题应该不是系统故障,是在运行中,有其他程序或操作干扰了print spooler服务。

    所以尝试检查window系统日志,方法:右键点击计算机,打开管理->windows日志->应用程序,发现确实提示spooler.exe意外停止的提示,但无具体提示。点击windows日志->安全,发现在spooler.exe意外停止的相同时间段内,有大量审核失败的记录存在。

    打开记录可以看到,有一台同工作组内的电脑在试图连接该电脑,但是审核失败。猜测该电脑打印服务自动停止与此有关,可能是其他电脑试图连接该电脑上共享的打印机失败而导致。禁用该电脑网卡,重新启动print spooler服务,发现恢复正常。所以想到解决办法如下:

    1、删除连接该共享打印机的电脑上的打印机记录

    2、更换该打印机所连接电脑的ip地址

    3、重新共享该打印机

    第二天再次出现这种错误,结合之前的猜测和现象:有其他程序或操作干扰了print spooler服务,断网后重启服务正常。锁定问题是有网络进程在干扰print spooler服务,检查系统防火墙,发现有两个未知程序会通过防火墙,程序名称乱码,拦截这两个程序,重新启动print spooler服务,服务正常运行,没有再次出现问题。

    更多相关内容
  •   flink将之前某个时间所有的状态保存下来,这份就是所谓的检查点(checkpoint)。检查点是 Flink 容错机制的核心。检查是针对故障恢复的结果而言的:故障恢复之后继续处理的结果,应该与发生故障前完全一致。...


    1. 检查点(Checkpoint)

      flink将之前某个时间点所有的状态保存下来,这份存档就是所谓的检查点(checkpoint)。检查点是 Flink 容错机制的核心。检查是针对故障恢复的结果而言的:故障恢复之后继续处理的结果,应该与发生故障前完全一致。所以有时又会把 checkpoint 叫作一致性检查点


    1.1 检查点的保存

    (1) 周期性的触发保存

      检查点作为应用状态的一份存档,其实就是所有任务状态在同一时间点的一个快照(snapshot),它的触发是周期性的。每隔一段时间检查点保存操作被触发时,就把每个任务当前的状态复制一份,按照一定的逻辑结构放在一起持久化保存起来,就构成了检查点

    (2) 保存的时间点

      当所有任务都恰好处理完一个相同的输入数据的时候,将它们的状态保存下来。首先,这样避免了除状态之外其他额外信息的存储,提高了检查点保存的效率。其次,一个数据要么就是被所有任务完整地处理完,状态得到了保存;要么就是没处理完,状态全部没保存:这就相当于构建一个事务(transaction)。如果出现故障,恢复到之前保存的状态,故障时正在处理的所有数据都需要重新处理;所以只需要让源(source)任务向数据源重新提交偏移量、请求重放数据就可以了。这需要源任务可以把偏移量作为算子状态保存下来,而且外部数据源能够重置偏移量;(典型应用 Kafka)


    1.2 从检查点恢复状态

      当发生故障时,需要找到最近一次成功保存的检查点来恢复状态
    在这里插入图片描述
    具体的步骤为:

    (1)重启应用

      遇到故障之后,第一步当然是重启,所有任务的状态会清空
    在这里插入图片描述

    (2)读取检查点,重置状态

      找到最近一次保存的检查点,从中读出每个算子任务状态的快照,分别填充到对应的状态中。这样,Flink 内部所有任务的状态,就恢复到了保存检查点的那一时刻
    在这里插入图片描述

    (3)重放数据

      从检查点恢复状态后如果直接继续处理数据,那么保存检查点之后、到发生故障这段时间内的数据就相当于丢掉了;这会造成计算结果的错误。为了不丢数据,应该从保存检查点后开始重新读取数据,这可以通过 Source 任务向外部数据源重新提交偏移量(offset)来实现。这样,整个系统的状态已经完全回退到了检查点保存完成的那一时刻
    在这里插入图片描述

    (4)继续处理数据

    在这里插入图片描述

    注:
      想要正确地从检查点中读取并恢复状态,必须知道每个算子任务状态的类型和先后顺序(拓扑结构);因此为了可以从之前的检查点中恢复状态,在改动程序、修复 bug 时要保证状态的拓扑顺序和类型不变。状态的拓扑结构在 JobManager 上可以由 JobGraph 分析得到,而检查点保存的定期触发也是由 JobManager 控制的;所以故障恢复的过程需要 JobManager 的参与


    1.3 检查点算法

      在不暂停整体流处理的前提下,将状态备份保存到检查点。在 Flink中,采用了基于 Chandy-Lamport 算法的分布式快照

    (1)检查点分界线(Barrier)

      借鉴水位线(watermark)的设计,在数据流中插入一个特殊的数据结构,专门用来表示触发检查点保存的时间点。收到保存检查点的指令后,Source 任务可以在当前数据流中插入这个结构;之后的所有任务只要遇到它就开始对状态做持久化快照保存。由于数据流是保持顺序依次处理的,因此遇到这个标识就代表之前的数据都处理完了,可以保存一个检查点;而在它之后的数据,引起的状态改变就不会体现在这个检查点中,而需要保存到下一个检查点。这种特殊的数据形式,把一条流上的数据按照不同的检查点分隔开,所以就叫作检查点的分界线(Checkpoint Barrier)。检查点分界线中带有一个检查点 ID,这是当前要保存的检查点的唯一标识
    在这里插入图片描述
      在 JobManager 中有一个检查点协调器(checkpoint coordinator),专门用来协调处理检查点的相关工作。检查点协调器会定期向 TaskManager 发出指令,要求保存检查点(带着检查点 ID);TaskManager 会让所有的 Source 任务把自己的偏移量(算子状态)保存起来,并将带有检查点 ID 的分界线(barrier)插入到当前的数据流中,然后像正常的数据一样像下游传递;之后 Source 任务就可以继续读入新的数据了。每个算子任务只要处理到这个 barrier,就把当前的状态进行快照;在收到 barrier 之前,还是正常地处理之前的数据,完全不受影响

    (2)分布式快照算法

      通过在流中插入分界线(barrier)需要保持顺序一致,在一条单一的流上,数据依次进行处理,顺序保持不变;不过对于分布式流处理来说,想要保持数据的顺序就不是那么容易了。
      Flink 使用了 Chandy-Lamport 算法的一种变体,被称为异步分界线快照(asynchronous barrier snapshotting)算法。算法的核心就是两个原则:当上游任务向多个并行下游任务发送 barrier 时,需要广播出去;而当多个上游任务向同一个下游任务传递 barrier 时,需要在下游任务执行分界线对齐(barrier alignment)操作,也就是需要等到所有并行分区的 barrier 都到齐,才可以开始状态的保存

    在这里插入图片描述
    具体过程:
    (1)JobManager 发送指令,触发检查点的保存;Source 任务保存状态,插入分界线
      JobManager 会周期性地向每个 TaskManager 发送一条带有新检查点 ID 的消息,通过这种方式来启动检查点。收到指令后,TaskManger 会在所有 Source 任务中插入一个分界线(barrier),并将偏移量保存到远程的持久化存储中
    在这里插入图片描述
    (2)状态快照保存完成,分界线向下游传递
      状态存入持久化存储之后,会返回通知给 Source 任务;Source 任务就会向 JobManager 确认检查点完成,然后像数据一样把 barrier 向下游任务传递
    在这里插入图片描述
    (3)向下游多个并行子任务广播分界线,执行分界线对齐
      对于下一个检查点要保存的内容,不应立即处理,而是要缓存起来、等到状态保存之后再做处理
    在这里插入图片描述
    (4)分界线对齐后,保存状态到持久化存储
    在这里插入图片描述
    (5)先处理缓存数据,然后正常继续处理
      完成检查点保存之后,任务就可以继续正常处理数据。这时如果有等待分界线对齐时缓存的数据,需要先做处理;然后再按照顺序依次处理新到的数据

    注:
      当 JobManager 收到所有任务成功保存状态的信息,就可以确认当前检查点成功保存。之后遇到故障就可以从这里恢复
      由于分界线对齐要求先到达的分区做缓存等待,一定程度上会影响处理的速度;当出现背压(backpressure)时,下游任务会堆积大量的缓冲数据,检查点可能需要很久才可以保存完毕。为了应对这种场景,Flink 1.11 之后提供了不对齐的检查点保存方式,可以将未处理的缓冲数据(in-flight data)也保存进检查点。这样,当我们遇到一个分区 barrier 时就不需等待对齐,而是可以直接启动状态的保存了


    1.4 检查点配置

    (1) 启用检查点

      默认情况下,Flink 程序是禁用检查点的。如果想要为 Flink 应用开启自动保存快照的功能,需要在代码中显式地调用执行环境的.enableCheckpointing()方法:

    StreamExecutionEnvironment env = 
    StreamExecutionEnvironment.getExecutionEnvironment();
    // 每隔 1 秒启动一次检查点保存
    env.enableCheckpointing(1000);
    

    (2)检查点存储(Checkpoint Storage)

      检查点具体的持久化存储位置,取决于检查点存储(CheckpointStorage)的设置。默认情况下,检查点存储在 JobManager 的堆(heap)内存中。而对于大状态的持久化保存,Flink也提供了在其他存储位置进行保存的接口,这就是 CheckpointStorage。具 体 可以通过调用检查点配置的 .setCheckpointStorage() 来 配 置 , 需 要 传 入 一 个CheckpointStorage 的实现类。Flink 主要提供了两种 CheckpointStorage:作业管理器的堆内存(JobManagerCheckpointStorage)和文件系统(FileSystemCheckpointStorage)

    // 配置存储检查点到 JobManager 堆内存
    env.getCheckpointConfig().setCheckpointStorage(new 
    JobManagerCheckpointStorage());
    // 配置存储检查点到文件系统
    env.getCheckpointConfig().setCheckpointStorage(new 
    FileSystemCheckpointStorage("hdfs://namenode:40010/flink/checkpoints"));
    

    (3)其他高级配置

    (1)检查点模式(CheckpointingMode)
      设置检查点一致性的保证级别,有精确一次(exactly-once)和至少一次(at-least-once)两个选项。默认级别为 exactly-once,而对于大多数低延迟的流处理程序,at-least-once 就够用了,而且处理效率会更高

    (2)超时时间(checkpointTimeout)
      用于指定检查点保存的超时时间,超时没完成就会被丢弃掉。传入一个长整型毫秒数作为参数,表示超时时间

    (3)最小间隔时间(minPauseBetweenCheckpoints)
      用于指定在上一个检查点完成之后,检查点协调器(checkpoint coordinator)最快等多久可以发出保存下一个检查点的指令。这就意味着即使已经达到了周期触发的时间点,只要距离上一个检查点完成的间隔不够,就依然不能开启下一次检查点的保存。这就为正常处理数据留下了充足的间隙。当指定这个参数时,maxConcurrentCheckpoints 的值强制为 1

    (4)最大并发检查点数量(maxConcurrentCheckpoints)
      用于指定运行中的检查点最多可以有多少个。由于每个任务的处理进度不同,完全可能出现后面的任务还没完成前一个检查点的保存、前面任务已经开始保存下一个检查点了。这个参数就是限制同时进行的最大数量。如果前面设置了 minPauseBetweenCheckpoints,则 maxConcurrentCheckpoints 这个参数就不起作用了

    (5)开启外部持久化存储(enableExternalizedCheckpoints)
      用于开启检查点的外部持久化,而且默认在作业失败的时候不会自动清理,如果想释放空间需要自己手工清理。里面传入的参数 ExternalizedCheckpointCleanup 指定了当作业取消的时候外部的检查点该如何清理。
    DELETE_ON_CANCELLATION:在作业取消的时候会自动删除外部检查点,但是如果是作业失败退出,则会保留检查点。
    RETAIN_ON_CANCELLATION:作业取消的时候也会保留外部检查点

    (6)检查点异常时是否让整个任务失败(failOnCheckpointingErrors)
      用于指定在检查点发生异常的时候,是否应该让任务直接失败退出。默认为 true,如果设置为 false,则任务会丢弃掉检查点然后继续运行

    (7)不对齐检查点(enableUnalignedCheckpoints)
      不再执行检查点的分界线对齐操作,启用之后可以大大减少产生背压时的检查点保存时间。这个设置要求检查点模式(CheckpointingMode)必须为 exctly-once,并且并发的检查点个数为 1


    1.5 保存点(Savepoint)

      原理和算法与检查点完全相同,只是多了一些额外的元数据。事实上,保存点就是通过检查点的机制来创建流式作业状态的一致性镜像(consistent image)的。保存点中的状态快照,是以算子 ID 和状态名称组织起来的,相当于一个键值对。从保存点启动应用程序时,Flink 会将保存点的状态数据重新分配给相应的算子任务

    (1)使用保存点

    (1)创建保存点
      要在命令行中为运行的作业创建一个保存点镜像,只需要执行:

    bin/flink savepoint :jobId [:targetDirectory]
    

      对于保存点的默认路径,可以通过配置文件 flink-conf.yaml 中的 state.savepoints.dir 项来设定:

    state.savepoints.dir: hdfs:///flink/savepoints
    

      对于单独的作业,可以在程序代码中通过执行环境来设置:

    env.setDefaultSavepointDir("hdfs:///flink/savepoints");
    

      由于创建保存点一般都是希望更改环境之后重启,所以创建之后往往紧接着就是停掉作业的操作。除了对运行的作业创建保存点,可以在停掉一个作业时直接创建保存点:

    bin/flink stop --savepointPath [:targetDirectory] :jobId
    

    (2)从保存点重启应用

      提交启动一个 Flink 作业,使用的命令是 flink run;现在要从保存点重启一个应用,其实本质是一样的:

    bin/flink run -s :savepointPath [:runArgs]
    

    2. 状态一致性

    2.1 状态一致性的三种级别

    最多一次(AT-MOST-ONCE)
      当任务发生故障时,最简单的做法就是直接重启,别的什么都不干;既不恢复丢失的状态,也不重放丢失的数据。每个数据在正常情况下会被处理一次,遇到故障时就会丢掉,所以就是最多处理一次

    至少一次(AT-LEAST-ONCE)
      在实际应用中,希望至少不要丢掉数据。这种一致性级别就叫作至少一次(at-least-once),就是说是所有数据都不会丢,肯定被处理了;不过不能保证只处理一次,有些数据会被重复处理。
      在有些场景下,重复处理数据是不影响结果的正确性的,这种操作具有幂等性。如 UV
      为了保证达到 at-least-once 的状态一致性,需要在发生故障时能够重放数据。最常见的做法是,可以用持久化的事件日志系统,把所有的事件写入到持久化存储中。这时只要记录一个偏移量,当任务发生故障重启后,重置偏移量就可以重放检查点之后的数据了。Kafka 就是这种架构的一个典型实现

    精确一次(EXACTLY-ONCE)
      最难实现的状态一致性语义。exactly-once 意味着所有数据不仅不会丢失,而且只被处理一次,不会重复处理。也就是说对于每一个数据,最终体现在状态和输出结果上,只能有一次统计
      


    2.2 端到端的状态一致性

      在实际应用中,一般要保证从用户的角度看来,最终消费的数据是正确的。而用户或者外部应用不会直接从 Flink 内部的状态读取数据,往往需要将处理结果写入外部存储中。这就要求不仅要考虑 Flink 内部数据的处理转换,还涉及从外部数据源读取,以及写入外部持久化系统,整个应用处理流程从头到尾都应该是正确的。所以完整的流处理应用,应该包括了数据源、流处理器和外部存储系统三个部分。这个完整应用的一致性,就叫作端到端(end-to-end)的状态一致性,它取决于三个组件中最弱的那一环。一般来说,能否达到 at-least-once 一致性级别,主要看数据源能够重放数据;而能否达到 exactly-once 级别,流处理器内部、数据源、外部存储都要有相应的保证机制


    3. 端到端精确一次(end-to-end exactly-once)

      由于检查点保存的是之前所有任务处理完某个数据后的状态快照,所以重放的数据引起的状态改变一定不会包含在里面,最终结果中只处理了一次。所以,端到端一致性的关键点,就在于输入的数据源端和输出的外部存储端

    3.1 输入端保证

      数据源可重放数据,或者说可重置读取数据偏移量,加上 Flink 的 Source 算子将偏移量作为状态保存进检查点,就可以保证数据不丢。这是达到 at-least-once 一致性语义的基本要求,也是实现端到端 exactly-once 的基本要求


    3.2 输出端保证

      为了实现端到端 exactly-once,我们还需要对外部存储系统、以及 Sink 连接器有额外的要求。保证 exactly-once 一致性的写入方式有两种:

    (1)幂等(idempotent)写入

      一个操作可以重复执行很多次,但只导致一次结果更改

    (2)事务(transactional)写入

      事务(transaction)是应用程序中一系列严密的操作,所有操作必须成功完成,否则在每个操作中所做的所有更改都会被撤消。事务有四个基本特性:原子性(Atomicity)、一致性(Correspondence)、隔离性(Isolation)和持久性(Durability)。
      用一个事务来进行数据向外部系统的写入,事务与检查点绑定。当 Sink 任务遇到 barrier 时,开始保存状态的同时就开启一个事务,接下来所有数据的写入都在这个事务中;待到当前检查点保存完毕时,将事务提交,所有写入的数据就真正可用了。如果中间过程出现故障,状态会回退到上一个检查点,而当前事务没有正常关闭(因为当前检查点没有保存完),所以也会回滚,写入到外部的数据就被撤销了

    (1)预写日志(write-ahead-log,WAL)
    ①先把结果数据作为日志(log)状态保存起来
    ②进行检查点保存时,也会将这些结果数据一并做持久化存储
    ③在收到检查点完成的通知时,将所有结果一次性写入外部系统

    (2)两阶段提交(two-phase-commit,2PC)
    真正基于事务的,它需要外部系统提供事务支持
    ①当第一条数据到来时,或者收到检查点的分界线时,Sink 任务都会启动一个事务。
    ②接下来接收到的所有数据,都通过这个事务写入外部系统;这时由于事务没有提交,所以数据尽管写入了外部系统,但是不可用,是预提交的状态。
    ③当 Sink 任务收到 JobManager 发来检查点完成的通知时,正式提交事务,写入的结果真正可用


    展开全文
  • Flink 检查点(checkpoint)

    千次阅读 2020-03-25 17:35:00
    它使用一种被称为"检查点"(checkpoint)的特性,在出现故障时将系统重置回正确状态。下面通过简单的类比来解释检查点的作用。 假设你和两位朋友正在数项链上有多少颗珠子,如下图所示。你捏住珠子,边数边拨,每拨...

    Flink具体如何保证exactly-once呢? 它使用一种被称为"检查点"(checkpoint)的特性,在出现故障时将系统重置回正确状态。下面通过简单的类比来解释检查点的作用。

    假设你和两位朋友正在数项链上有多少颗珠子,如下图所示。你捏住珠子,边数边拨,每拨过一颗珠子就给总数加一。你的朋友也这样数他们手中的珠子。当你分神忘记数到哪里时,怎么办呢? 如果项链上有很多珠子,你显然不想从头再数一遍,尤其是当三人的速度不一样却又试图合作的时候,更是如此(比如想记录前一分钟三人一共数了多少颗珠子,回想一下一分钟滚动窗口)。

    于是,你想了一个更好的办法: 在项链上每隔一段就松松地系上一根有色皮筋,将珠子分隔开; 当珠子被拨动的时候,皮筋也可以被拨动; 然后,你安排一个助手,让他在你和朋友拨到皮筋时记录总数。用这种方法,当有人数错时,就不必从头开始数。相反,你向其他人发出错误警示,然后你们都从上一根皮筋处开始重数,助手则会告诉每个人重数时的起始数值,例如在粉色皮筋处的数值是多少。

    Flink检查点的作用就类似于皮筋标记。数珠子这个类比的关键点是: 对于指定的皮筋而言,珠子的相对位置是确定的; 这让皮筋成为重新计数的参考点。总状态(珠子的总数)在每颗珠子被拨动之后更新一次,助手则会保存与每根皮筋对应的检查点状态,如当遇到粉色皮筋时一共数了多少珠子,当遇到橙色皮筋时又是多少。当问题出现时,这种方法使得重新计数变得简单。

    1、Flink的检查点算法

    Flink检查点的核心作用是确保状态正确,即使遇到程序中断,也要正确。记住这一基本点之后,Flink为用户提供了用来定义状态的工具。

     1 val dataDS: DataStream[String] = env.readTextFile("input/data.txt")
     2 
     3 val mapDS: DataStream[(String, String, String)] = dataDS.map(data => {
     4     val datas = data.split(",")
     5     (datas(0), datas(1), datas(2))
     6 })
     7 val keyDS: KeyedStream[(String, String, String), Tuple] = mapDS.keyBy(0)
     8 
     9 keyDS.mapWithState{
    10     case ( t, buffer ) => {
    11         (t, buffer)
    12     }
    13 }

     

    我们用一个例子来看检查点是如何运行的:

    以下这个Scala程序按照输入记录的第一个字段(一个字符串)进行分组并维护第三个字段的计数状态.

     1 env.enableCheckpointing(1000, CheckpointingMode.EXACTLY_ONCE)
     2 
     3 val dataDS: DataStream[String] = env.readTextFile("input/data.txt")
     4 
     5 val mapDS: DataStream[(String, String, Int)] = dataDS.map(data => {
     6     val datas = data.split(",")
     7     (datas(0), datas(1), datas(2).toInt)
     8 })
     9 val keyDS: KeyedStream[(String, String, Int), Tuple] = mapDS.keyBy(0)
    10 
    11 val mapStateDS = keyDS.mapWithState[(String, String, Int), Int] {
    12     case (t:(String, String, Int), buffer:Option[Int]) => {
    13         val i: Int = buffer.getOrElse(0)
    14         println("buffer>>>" + i)
    15         (t, Option(t._3 + i))
    16     }
    17 }
    18 mapStateDS.print()

     

    该程序有两个算子: keyBy算子用来将记录按照第一个元素(一个字符串)进行分组,根据该key将数据进行重新分区,然后将记录再发送给下一个算子: 有状态的map算子(mapWithState)。map算子在接收到每个元素后,将输入记录的第三个字段的数据加到现有总数中,再将更新过的元素发送出去。下图表示程序的初始状态: 输入流中的6条记录被检查点分割线(checkpoint barrier)隔开,所有的map算子状态均为0(计数还未开始)。所有key为sensor_1的记录将被顶层的map算子处理,所有key为b的记录将被中间层的map算子处理,所有key为c的记录则将被底层的map算子处理。

    上图是程序的初始状态。注意,a、b、c三组的初始计数状态都是0,即三个圆柱上的值。ckpt表示检查点分割线(checkpoint barriers)。每条记录在处理顺序上严格地遵守在检查点之前或之后的规定,例如["b",2]在检查点之前被处理,["a",2]则在检查点之后被处理。

    当该程序处理输入流中的6条记录时,涉及的操作遍布3个并行实例(节点、CPU内核等)。那么,检查点该如何保证exactly-once呢?

    检查点分割线和普通数据记录类似。它们由算子处理,但并不参与计算,而是会触发与检查点相关的行为。当读取输入流的数据源(在本例中与keyBy算子内联)遇到检查点屏障时,它将其在输入流中的位置保存到持久化存储中。如果输入流来自消息传输系统(Kafka),这个位置就是偏移量。Flink的存储机制是插件化的,持久化存储可以是分布式文件系统,如HDFS。下图展示了这个过程。

    当Flink数据源(在本例中与keyBy算子内联)遇到检查点分界线(barrier)时,它会将其在输入流中的位置保存到持久化存储中。这让 Flink可以根据该位置重启。

    检查点像普通数据记录一样在算子之间流动。当map算子处理完前3条数据并收到检查点分界线时,它们会将状态以异步的方式写入持久化存储,如下图所示。

    位于检查点之前的所有记录(["b",2]、["b",3]和["c",1])被map算子处理之后的情况。此时,持久化存储已经备份了检查点分界线在输入流中的位置(备份操作发生在barrier被输入算子处理的时候)。map算子接着开始处理检查点分界线,并触发将状态异步备份到稳定存储中这个动作。

    当map算子的状态备份和检查点分界线的位置备份被确认之后,该检查点操作就可以被标记为完成,如下图所示。我们在无须停止或者阻断计算的条件下,在一个逻辑时间点(对应检查点屏障在输入流中的位置)为计算状态拍了快照。通过确保备份的状态和位置指向同一个逻辑时间点,后文将解释如何基于备份恢复计算,从而保证exactly-once。值得注意的是,当没有出现故障时,Flink检查点的开销极小,检查点操作的速度由持久化存储的可用带宽决定。回顾数珠子的例子: 除了因为数错而需要用到皮筋之外,皮筋会被很快地拨过。

    检查点操作完成,状态和位置均已备份到稳定存储中。输入流中的所有数据记录都已处理完成。值得注意的是,备份的状态值与实际的状态值是不同的。备份反映的是检查点的状态。

    如果检查点操作失败,Flink可以丢弃该检查点并继续正常执行,因为之后的某一个检查点可能会成功。虽然恢复时间可能更长,但是对于状态的保证依旧很有力。只有在一系列连续的检查点操作失败之后,Flink才会抛出错误,因为这通常预示着发生了严重且持久的错误。 现在来看看下图所示的情况: 检查点操作已经完成,但故障紧随其后。

     

    在这种情况下,Flink会重新拓扑(可能会获取新的执行资源),将输入流倒回到上一个检查点,然后恢复状态值并从该处开始继续计算。在本例中,["a",2]、["a",2]和["c",2]这几条记录将被重播。

    下图展示了这一重新处理过程。从上一个检查点开始重新计算,可以保证在剩下的记录被处理之后,得到的map算子的状态值与没有发生故障时的状态值一致。

    Flink将输入流倒回到上一个检查点屏障的位置,同时恢复map算子的状态值。然后,Flink从此处开始重新处理。这样做保证了在记录被处理之后,map算子的状态值与没有发生故障时的一致。

    Flink检查点算法的正式名称是异步分界线快照(asynchronous barrier snapshotting)。该算法大致基于Chandy-Lamport分布式快照算法

    检查点是Flink最有价值的创新之一,因为它使Flink可以保证exactly-once,并且不需要牺牲性能

    2、Flink+Kafka如何实现端到端的Exactly-once语义

    我们知道,端到端的状态一致性的实现,需要每一个组件都实现,对于Flink + Kafka的数据管道系统(Kafka进、Kafka出)而言,各组件怎样保证exactly-once语义呢?

    • 内部 —— 利用checkpoint机制,把状态存盘,发生故障的时候可以恢复,保证内部的状态一致性
    • source —— kafka consumer作为source,可以将偏移量保存下来,如果后续任务出现了故障,恢复的时候可以由连接器重置偏移量,重新消费数据,保证一致性
    • sink —— kafka producer作为sink,采用两阶段提交 sink,需要实现一个 TwoPhaseCommitSinkFunction

    Flink由JobManager协调各个TaskManager进行checkpoint存储,checkpoint保存在 StateBackend中,默认StateBackend是内存级的,也可以改为文件级的进行持久化保存。

    当 checkpoint 启动时,JobManager 会将检查点分界线(barrier)注入数据流;barrier会在算子间传递下去。

    每个算子会对当前的状态做个快照,保存到状态后端。对于source任务而言,就会把当前的offset作为状态保存起来。下次从checkpoint恢复时,source任务可以重新提交偏移量,从上次保存的位置开始重新消费数据。

    每个内部的 transform 任务遇到 barrier 时,都会把状态存到 checkpoint 里。

    sink 任务首先把数据写入外部 kafka,这些数据都属于预提交的事务(还不能被消费);当遇到 barrier 时,把状态保存到状态后端,并开启新的预提交事务。

    当所有算子任务的快照完成,也就是这次的 checkpoint 完成时,JobManager 会向所有任务发通知,确认这次 checkpoint 完成。

    当sink 任务收到确认通知,就会正式提交之前的事务,kafka 中未确认的数据就改为“已确认”,数据就真正可以被消费了。

    执行过程实际上是一个两段式提交,每个算子执行完成,会进行“预提交”,直到执行完sink操作,会发起“确认提交”,如果执行失败,预提交会放弃掉。

    具体的两阶段提交步骤总结如下:

    (1)第一条数据来了之后,开启一个Kafka的事务(Transaction),正常写入Kafka分区日志,但是标记未提交,这就是“预提交”

    (2)JobManager触发checkpoint操作,barrier从source开始向下传递,遇到barrier的算子将状态存入状态后端,并通知JobManager

    (3)Sink连机器收到barrier,保存当前状态,存入checkpoint,通知JobManager,并开启下一阶段的事务,用于提交下一个检查点的数据

    (4)JobManager收到所有任务的通知,发出确认信息,表示checkpoint完成

    (5)sink任务收到JobManager的确认信息,正式提交这段时间的数据

    (6)外部Kafka关闭事务,提交的数据可以正常消费

    以下来自:官网:end-to-end-exactly-once-apache-flink

    Let’s discuss how to extend a TwoPhaseCommitSinkFunction on a simple file-based example. We need to implement only four methods and present their implementations for an exactly-once file sink:

    1. beginTransaction - to begin the transaction, we create a temporary file in a temporary directory on our destination file system. Subsequently, we can write data to this file as we process it.
    2. preCommit - on pre-commit, we flush the file, close it, and never write to it again. We’ll also start a new transaction for any subsequent writes that belong to the next checkpoint.
    3. commit - on commit, we atomically move the pre-committed file to the actual destination directory. Please note that this increases the latency in the visibility of the output data.
    4. abort - on abort, we delete the temporary file.
    展开全文
  • 一、检查点检查点屏障跟普通记录一样。它们由算子处理,但并不参与计算,而是会触发与检查点相关的行为。会在算子之间流动。当读取输入流的数据源遇到检查点屏障时,它将其在输入流中的位置保存到稳定存储中。如果...

    一、检查点:检查点屏障跟普通记录一样。它们由算子处理,但并不参与计算,而是会触发与检查点相关的行为。会在算子之间流动。当读取输入流的数据源遇到检查点屏障时,它将其在输入流中的位置保存到稳定存储中。如果输入流来自消息传输系统(Kafka 或 MapR Streams),这个位置就是偏移量。Flink 的存储机制是插件化的,稳定存储可以是分布式文件系统,如HDFS、S3 或 MapR-FS

    如图所示,位于检查点之前的所有记录(["b",2]、["b",3] 和 ["c",1])被 map 算子处理之后的情况。此时,稳定存储已经备份了检查点屏障在输入流中的位置(备份操作发生在检查点屏障被输入算子处理的时候)。map 算子接着开始处理检查点屏障,并触
    发将状态异步备份到稳定存储中这个动作

    当 map 算子的状态备份和检查点屏障的位置备份被确认之后,该检查点操作就可以被标记为完成,如下图所示。我们在无须停止或者阻断计算的条件下,在一个逻辑时间点(对应检查点屏障在输入流中的位置)为计算状态拍了快照。通过确保备份的状态和位置指向同一个逻辑时间点,后文将解释如何基于备份恢复计算,从而保证 exactly-once。值得注意的是,当没有出现故障时,Flink 检查点的开销极小,检查点操作的速度由稳定存储的可用带宽决定。

    检查点操作完成,状态和位置均已备份到稳定存储中。输入流中的所有记录都已处理完成。值得注意的是,备份的状态值与实际的状态值是不同的。备份反映的是检查点的状态

     

    Flink 将输入流倒回到上一个检查点屏障的位置,同时恢复 map 算子的状态值。然后,Flink 从此处开始重新处理。这样做保证了在记录被处理之后,map 算子的状态值与没有发生故障时的一致

    二、保存点:

    保存点与检查点的工作原理一致,只不过检查点是自动触发的,而保存点需要命令行触发或者web控制台触发。和检查点一样,保存点也保存到稳定存储当中,用户可以从保存点重启作业,而不用从头开始

    保存点的作用:(1) 应用程序代码升级:假设你在已经处于运行状态的应用程序中发现了一个 bug,并且希望之后的事件都可以用修复后的新版本来处理。通过触发保存点并从该保存点处运行新版本,下游的应用程序并不会察觉到不同(当然,被更新的部分除外)。
    (2) Flink 版本更新:Flink 自身的更新也变得简单,因为可以针对正在运行的任务触发保存点,并从保存点处用新版本的 Flink 重启任务。
    (3) 维护和迁移:使用保存点,可以轻松地“暂停和恢复”应用程序。这对于集群维护以及向新集群迁移的作业来说尤其有用。此外,它还有利于开发、测试和调试,因为不需要重播整个事件流。
    (4) 假设模拟与恢复:在可控的点上运行其他的应用逻辑,以模拟假设的场景,这样做在很多时候非常有用。
    (5) A/B 测试:从同一个保存点开始,并行地运行应用程序的两个版本,有助于进行 A/B 测试。

     

    展开全文
  • supervisor管理进程停止异常问题记录

    千次阅读 2017-10-25 23:30:49
    Python写的程序直接使用supervisor管理,正常启动后多次停止进行代码调整,结果发现CPU飙高,ps检查后发现是这个python程序存在多个进程。问题分析: supervisor在管理时没能真正停止进程,kill -9 杀死所有进程...
  • Flink检查点问题

    千次阅读 2019-04-28 19:18:26
    Flink检查点问题问题简介扫盲什么是检查点如何配置检查点路径如何启用检查点如何使用检查点解决思路小结 问题简介 Cannot find meta data file '_metadata' in directory 'hdfs://nn-HA-service/flink/flink-...
  • 远程桌面连接已停止工作解决方法

    千次阅读 2021-07-31 07:38:46
    前几天在使用3389远程连接云服务器的时候出现提示:远程桌面连接已停止工作,最终无法正常登录Windows远程服务器,下面就将解决方法和原因分享给大家!对于此类应用程序故障,通常可以在事件查看器中的应用事件日志...
  • "会话"循环内核上下文记录器"因以下错误而停止:0xc0000188" 即使对此特定事件查看器错误消息进行少量研究,也会揭示出一个事实,即它被认为是一个相当常见的 Windows 错误消息,没有什么可担心的。然而,当与受...
  • 其他 2019/08/03 苹果手机自带的Safari浏览器如何开启网页检查器 苹果手机自带的Safari浏览器如何开启网页检查器 Safari上的网页检查器可以检测访问的网站是否正常.那么如何开启网页检查器呢?今天就跟大家介绍一下...
  • 关于这几种文件和命令对mysql服务的启动和停止的使用,本文会分别进行介绍,还有一些关键的事项,比如生产环境对于MySQL服务的启动和停止是非常谨慎的一件事,不是每一种方式都适合生产使用的,需要搞清楚再使用,...
  • Loadrunner常见的检查点函数

    千次阅读 2016-05-17 13:29:12
    LoadRunner中执行Web性能测试,很重要的一点,是需要对Web网站的响应进行一些检查,以决定请求是否成功,这很重要,如果设置不好,就会出现请求大面积失败,性能却非常高的情况。 一般,在Loadrunner中检查点有两...
  • AA记录: 将域名指向一个IPv4地址(例如:100.100.100.100),需要增加A记录 NS NS记录: 域名解析服务器记录,如果要将子域名指定某个域名服务器来解析,需要设置NS记录 SOA SOA记录: SOA叫做起始授权机构记录,...
  • loadrunner插入检查点详解

    万次阅读 2014-07-17 09:13:12
    LR检查点  设置检查点的目的不只是为了验证我们的脚本没有错误,而更重要的是一个规范问题,如何使得测试结果更具有说服力,因此建议所有的测试脚本中都添加检查点设置。  推荐最好在录制过程中添加Text/Image...
  • 电脑开机黑屏并弹出Windows 资源管理器已停止工作该怎么办?出现了一个问题,导致程序停止正常工作。如果有可用的解决方案,Windows将关闭程序并通知您。出现这样的问题,是因为操作系统异常,还需要用户自行回忆...
  • ArcMap进行数据拓扑检查

    千次阅读 2021-08-20 10:16:53
    创建地理数据库拓扑,检查数据问题,修正数据问题,验证地理数据库拓扑。
  • Oracle停止Expdp/Impdp任务

    千次阅读 2019-09-21 23:25:44
    由于数据泵导入/导出命令是在数据库中生成了job运行,所以Oracle停止Expdp/Impdp任务时,是不可以如同exp/imp一样直接单单使用Ctrl+C的方式进行终止的,因为发送了Ctrl+C命令后,数据泵任务依旧是在后台执行的 ...
  • 智华天成保密检查工具【产品功能】1)检查涉密计算机是否上过互联网(能够检查出已删除或者格式化过的上网信息)。2)检查非涉密计算机上是否...5)检查上网记录(历史上网记录、IE缓存、cookies文件夹、收藏夹等)。6)检查...
  • 检查点不仅可以真实地标记 Extract进程捕获的要进行同步的数据变化以及 Replicat进程应用到 target数据库的数据变化,防止进程进行冗余的数据处理,还可以提供容错机制,防止在系统、网络或 Oracle GoldenGate...
  • 使用Limit参数优化MySQL查询 在找到一个记录后将停止查询
  • 如何清除 Linux 命令行历史记录

    千次阅读 2021-11-08 20:48:07
    要解决此问题,您可以使用以下命令: ln -sf /dev/null ~/.bash_history && history -c && exit 3) 关闭 bash 历史记录 您可以使用以下两种方式之一停止记录历史记录:为所有用户关闭它,或为单个用户关闭记录历史...
  • LoadRunner检查点使用小结

    万次阅读 2016-02-13 18:49:15
    在loadrunner中可以添加检查点,以检查从服务器返回的内容是否正确。  添加检查点方法:将脚本切换到Tree View,右键单击要检查的内容,选择Insert After或Insert Before,在弹出窗口中选择Web Checks-Image Check...
  • Oracle的启动和停止

    万次阅读 2018-01-12 18:55:06
    控制文件相互镜像,丢失其中一个控制文件可以在数据库停止状况下进行拷贝另外一份进行克隆。但是如果控制文件全部丢失,数据库mount过程中将会报错: SQL> alter database mount; alter database mount ...
  • flink检查点checkpoint失败问题总结-2

    万次阅读 2019-03-21 15:08:53
    检查点checkpoint失败问题总结(2): 问题描述:检查点刚开始是可以的做checkpoint的,后期越来越不能够做checkpoint的情况总结: 一.反压问题 1.什么是反压(如下图1所示)? 图2-1 部分算子反压表现(web ui) 2....
  • DataNode起不来检查记录

    千次阅读 2015-12-17 10:42:57
    今天开机启动HDFS,发现一个DataNode在界面上是停止的,尝试手工再次重启,直接报错,但是界面上输出日志不明显。 然后看日志输出目录(有点忘了日志目录了,查查配置) putty去到目录:查看,...
  • goldengate 检查点的理解

    千次阅读 2015-04-22 21:18:20
    检查点不仅可以真实地标记 Extract进程捕获的要进行同步的数据变化以及 Replicat进程应用到 target数据库的数据变化,防止进程进行冗余的数据处理,还可以提供容错机制,防止在系统、网络或 Oracle GoldenGate...
  • 文章目录一、windows基线检查选项及风险等级1.系统已安装最新的service pack2.系统已经安装了最新的安全补丁二、本地安全策略检查选项及风险等级1.引入库2.读入数据总结 一、windows基线检查选项及风险等级 1.系统...
  • 解决 Win10 打开图片卡死:程序 Microsoft.Photos.exe 版本 2020.20070.10002.0 已停止与 Windows 交互并关闭 解决 Win10 打开图片卡死:程序 Microsoft.Photos.exe 版本 2020.20070.10002.0 已停止与 Windows 交互...
  • 网关作为流量的入口,承上启下的中枢,对上游节点的健康状态监测是比不可少的;若上游节点异常,网关需要动态摘除此节点,避免流量... 目前本人负责的网关是基于orange二次开发的,health_check健康检查功能是基于插...
  • 摘要: 在分布式系统中,经常需要利用健康检查机制来检查服务的可用性,防止其他服务调用时出现异常。自 1.12 版本之后,Docker 引入了原生的健康检查实现。本文将介绍Docker容器健康检查机制,以及在Docker Swarm ...
  • 应用权限测试 应用权限分配不合理 1、使用反编译工具反反编译 2、打开源码后,检查应用 AndoridManifest.xml 文件,将应用权限和业务功能需要权限做对比,检查申请应用权限是否大于业务需要权限,有即存在安全隐患...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 230,785
精华内容 92,314
热门标签
关键字:

停止点检查记录