转载请提前与本人联系，如有侵权必追究责任！

本文正在参与「技能专题19期 闲谈数据库技能」活动, 我是新人loserwang，希望大家多多支撑和交流。

checkpoint

如果体系每次收到写入恳求后，等候数据彻底写入耐久化存储再回来成果，这样数据丢失的可能性大大削减，可是一般耐久化操作都是磁盘IO操作(甚至网络IO操作），处理的耗时比较长，这样读写的功率就会很低。（write through)

为了确保读写的功率，一般咱们都会经过异步的方式来写数据，即先把数据写入内存，回来恳求成果，然后再将数据异步写入。可是如果异步写入之前，体系宕机，会导致内存中的数据丢失。(write back)

当体系呈现毛病重启后，通常要对前面的操作进行replay。可是从头开端价值太高了，所以经过checkpoint来削减进行replay的操作数。checkpiont机制确保在某一时刻，体系运转地点的易失性存储数据与耐久化存储的数据保持彻底同步，当体系呈现毛病进行重启的时分，从这一点开端康复（replay)，从而确保 At-Least 语义.

接下来总结一下我遇到的运用checkpoint的东西（后续遇到再不断添加)。

数据库checkpoint

能够数据库毛病康复与查看点来学习checkpoint机制, 以下内容参阅《数据库体系基础讲义》


事务对数据可进行操作时：先写运转日志；写成功后，在与数据库缓冲区进行信息交流。

数据一致性离不开的checkpoint机制

如果发生数据库体系毛病可经过运转日志来康复。依据运转日志记载的事物操作次序重做事务（当事务发生毛病时已正确结束）或吊销事务（当事物在发生毛病时未结束）。
可是毛病康复是需求时刻的。运转日志保存了若干天的记载，当发生体系毛病时应从哪一点开端康复呢？

数据一致性离不开的checkpoint机制

DBMS在运转日志中定期的设置和更新查看点。查看点是这样的时刻：在该时刻，DBMS强制使内存DB Buffer中的内容与DB中的内容保持一致，即将DB Buffer中更新的一切内容写回DB中。即在查看点之前内存中数据与介质中数据是保持一致的。
所以体系毛病的康复：

  • 查看点之前结束的事物不需求康复（现已写入DB)

  • 查看点之后结束或许正在发生的事务需求依据运转日志进行康复(不能确认是否写回DB）：毛病点结束前结束的重做，毛病时刻未结束的吊销。=>重做在kafka中的一种方式为：Follower依据hw切断，并从头fetch

数据一致性离不开的checkpoint机制

而对介质毛病对康复经过备份完成的。在某一时刻，对数据库在其他介质存储上发生的另一份同等记载。当发生介质毛病时，用副本替换被破环的数据库。由于介质康复影响全面，在用副本康复后还需求依据运转日志进行康复。
数据一致性离不开的checkpoint机制

经过转储点来确认备份的时刻，转储点的设置有以下留意点:

  • 备份转储周期与运转日志的巨细密切相关，应留意避免衔接不畅而引起的漏洞。

  • 过频，会影响体系工作功率;过疏，会形成运转日志过大，也影响体系运转功能。


数据一致性离不开的checkpoint机制

Kafka checkpoint

Kafka的根目录下有四个查看点文件：

  • replication-offset-checkpoint：对应HW，有守时任务刷写，由broker端参数 replica.high.watermark.checkpoint.interval.ms来装备
  • recovery-point-offset-checkpoint：对应LEO，有守时任务刷写，由broker端参数 replica.flush.offset.checkpoint.interval.ms 来装备
  • log-start-offset-checkpoint: 对应LogStartOffset,有守时任务刷写，由broker端参数 log.flush.start.offset.checkpoint.interval.ms 来装备
  • cleaner-offset-checkpoint: 整理查看点文件，用来记载每个主题的每个分区已整理的偏移量。

StackOverFlow上从checkpiont机制的视点来进行解释：

  • recovery-point-offset-checkpoint is the internal broker log where Kafka tracks which messages (from-to offset) were successfully checkpointed to disk. 即 recovery-point-offset-checkpoint 表明成功checkpoint到磁盘的偏移量，重启后需求从这一点康复，将后边的消息切断。
  • replication-offset-checkpoint is the internal broker log where Kafka tracks which messages (from-to offset) were successfully replicated to other brokers. 即 replication-offset-checkpoint 表明成功checkpoint到其他broker上面的消息，Follower重启后将其设为hw, 从这一点执行切断，避免呈现数据不一致。

Flink checkpoint

参阅 flink官方文档

首先看整体看一下，Flink容错机制的中心思维：

The central part of Flink’s fault tolerance mechanism is drawingconsistent snapshotsof the distributed data stream and operator state. These snapshots act as consistent checkpoints to which the system can fall back in case of a failure.

Flink implements fault tolerance using a combination ofstream replayandcheckpointing. A checkpoint marks a specific point in each of the input streams along with the corresponding state for each of the operators. A streaming dataflow can be resumed from a checkpoint while maintaining consistency (exactly-once processing semantics) by restoring the state of the operators and replaying the records from the point of the checkpoint.

  • 容错机制经过持续创立分布式数据流和算子状况的快照来完成。这需求寄存状况的耐久化存储，通常为分布式文件体系（比如 HDFS、 S3、 GFS、 NFS、 Ceph 等）
  • 在遇到程序毛病时（如机器、网络、软件等毛病），Flink 中止分布式数据流。体系重启一切 operator ，重置其到最近成功的 checkpoint，在依据checkpoint找到对应的快照来康复state。
  • 依据state中保存的信息，进行stream replay。

即Flink 容错机制的中心部分是经过持续创立分布式数据流和算子状况的快照。这些快照充任一致的查看点（(snapshots)），体系能够在发生毛病时回退到这些查看点(checkpoints)。

A checkpoint in Flink is a consistent snapshot of:

  1. The current state of an application
  2. The position in an input stream

Flink 运用 Chandy-Lamport algorithm 算法的一种变体，称为异步 barrier 快照（asynchronous barrier snapshotting）。当 checkpoint coordinator（job manager 的一部分）指示 task manager 开端 checkpoint 时，它会让一切 sources 记载它们的偏移量，并将编号的 checkpoint barriers 刺进到它们的流中。这些 barriers 流经 job graph，标示每个 checkpoint 前后的流部分。

数据一致性离不开的checkpoint机制

Checkpoint n 将包括每个 operator 的 state，这些 state 是对应的 operator 消费了严格在 checkpoint barrier n之前的一切事情，而且不包括在此（checkpoint barrier n）后的任何事情后而生成的状况。

当 job graph 中的每个 operator 接收到 barriers 时，它就会记载下其状况。 拥有两个输入流的 Operators（例如 CoProcessFunction）会执行 barrier 对齐（barrier alignment） 以便当前快照能够包括消费两个输入流 barrier 之前（但不超过）的一切 events 而发生的状况。

数据一致性离不开的checkpoint机制

Flink 的 state backends 利用写时复制（copy-on-write）机制允许当异步生成旧版本的状况快照时，能够不受影响地持续流处理。只有当快照被耐久保存后，这些旧版本的状况才会被作为垃圾回收。

原理：有状况的流 & chinglog的关系 The Log: What every software engineer should know about real-time data’s unifying abstraction有时刻再详细叙说

GFS checkpoint

参阅《google file system》

操作日志(operate log) 保存了要害的元数据改变历史记载。它是GFS的中心: 不仅仅由于这是仅有耐久化的元数据记载，而且也是由于操作记载作为逻辑时刻基线，定义了并行操作的次序。 由于操作日志是极要害的，咱们有必要将其可靠保存。在元数据改变而且耐久化之前，关于客户端来说都是不可见的（也就是说确保原子性）。否则，就算是chunkserver完好的情况下，咱们也可能会丢失整个文件体系，或许最近的客户端操作。因而，咱们把这个文件保存在多个不同的主机上，而且只有当改写这个相关的操作记载到本地和远程磁盘之后，才会给客户端操作应对。master能够每次改写一批日志记载，以削减改写和复制这个日志导致的体系吞吐量。

master经过replay操作日志康复本身文件体系状况。为了削减发动时刻，咱们有必要尽量削减操作日志的巨细。master在日志增长超过某一个巨细的时分，执行checkpoint动作保存自己的状况，这样能够使下次发动的时分从本地硬盘读出这个最新的checkpoint，然后replay有限记载数。checkpoint是一个类似B-树的格局，能够直接映射到内存，而不需求额外的分析。这更进一步加快了康复的速度，提高了可用性。

由于树立一个checkpoint可能会花一点时刻，所以咱们这样设定master的内部状况: 新树立的checkpoint能够不堵塞新的状况改变。master切换到一个新的log文件，而且在一个独立的线程中创立新的checkpoint。 新的checkpoint包括了在切换到新log文件之前的状况改变。当这个集群有数百万文件的时分，创立新的checkpoint会花上几分钟的时刻。当checkpoint树立结束，会写到本地和远程的磁盘。

关于master的康复，只需求最新的checkpoint以及后续的log文件。旧的checkpoint及其log文件能够删掉了，虽然咱们还是保存几个checkpoint以及log，用来避免比较大的毛病发生。在checkpoint的时分得毛病并不会导致正确性受到影响，由于康复的代码会查看而且跳过不完整的checkpoint。

参阅

  • flink官方文档
  • 《google file system》
  • 中国大学mooc-数据库体系