Flink中的容错机制

 一.容错机制

在Flink中,有一套完整的容错机制来保证故障后的恢复,其中最重要的就是检查点。

1.1 检查点(Checkpoint

在流处理中,我们可以用存档读档的思路,将之前某个时间点的所有状态保存下来,这份存档就被称为“检查点(CkeckPoint)”。

当Flink程序异常重启时,我们就可以在检查点中“读档”,恢复出异常之前的状态。

 1.1.1 检查点的保存

(1) 周期性的触发保存

在Flink中,检查点的保存是周期性触发的,间隔时间可以进行设置。但是不建议保存太频繁,会消耗很多资源来做检查点。

(2) 保存的时间点

我们应该在所有任务(算子)都恰好处理完一个相同的输入数据的时候,将它们的状态保存下来。

这样做可以实现一个数据被所有任务(算子)完整地处理完,状态得到了保存。

如果出现故障,我们恢复到之前保存的状态,故障时正在处理的所有数据都需要重新处理;我们只需要让源(source)任务向数据源重新提交偏移量、请求重放数据就可以了(即重新将故障时的数据读入Flink)。当然这需要源任务可以把偏移量作为算子状态保存下来,而且外部数据源能够重置偏移量;kafka就是满足这些要求的一个最好的例子。

(3) 保存的具体流程

检查点的保存,最关键的就是要等所有任务将“同一个数据”处理完毕。

例如词频统计,依次输入“hello”,“world”,“hello”,“flink”,“hello”,“world”,“hello”,“flink”…

例如每个任务算子都处理完“hello”之后,可以保存自己的状态。

1.1.2 从检查点恢复状态

(1)检查点的保存具体流程

接着上面的例子,当我们需要保存检查点时,就是在所有任务算子将“同一个数据”处理完毕后,对所有状态进行快照并保存。例如输入“hello”,“world”,“hello”,“flink”,“hello”,“world”,“hello”,“flink”…在第三个数据“hello”被所有任务处理完时,做了检查点,保存了当前所有状态。

(2) 处理数据过程发生故障

当发生故障时,就需要找到最近一次成功保存的检查点来恢复状态。

例如在第三条数据“hello”处理完后保存了一次检查点,然后继续运行,正常处理了第四条数据“flink”,随即在处理第五条数据“hello”时发生故障。

此时,source任务处理完毕,偏移量为5,map任务也处理完毕,处理到KeyBy时发生故障,此时状态未保存。

(3) 重启应用 -> 读取检查点,重置状态 

1.重启应用

遇到故障后,需要重启Flink程序,届时,重启后的所有任务的状态会被清空

2.读取检查点,重置状态 

找到最近一次保存的检查点,从中读出每个算子的快照,并分别填充到对于的算子状态中,这样Flink内部算子的状态就恢复到了保存检查点的那一刻,就是处理完第三条数据时。

3.重置偏移量

 此时从检查点恢复状态后还存在一个问题,如果接着处理故障后的数据也就是第6、7条数据,那么从最后一次检查点到故障前的数据(第4、5条的“flink”,“hello”)则被丢弃了,就造成了计算结果错误。

为了不丢数据,我们应该从最后一次保存的检查点后重新读取数据(重放),这可以通过Source任务向外部系统提交偏移量(offset)来解决。

这样,整个系统的状态已经完全回退到了检查点保存完成的那一时刻。

4.继续处理数据

接下来继续处理重放的第4、5条数据,接着处理后续的数据。

在处理完上次发生故障的数据时,就已经完全恢复了正常,似乎没有发生过故障,也没有造成重复计算导致计算错误,这就保证了计算结果的准确性。在分布式系统中,这叫做实现了“精准一次”(exactly-once)的状态一致性保证。 

1.1.3 检查点算法

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

1.1.3.1 检查点分界线(Barrier)

借鉴水位线的设计,在数据流中插入一个特殊的数据结构,专门用来表示触发检查点保存的时间点。收到保存检查点的指令后,Source任务可以在当前数据流中插入这个结构;之后的所有任务只要遇到它就开始对状态做持久化快照保存。由于数据流是保持顺序依次处理的,因此遇到这个标识就代表之前的数据都处理完了,可以保存一个检查点;而在它之后的数据,引起的状态改变就不会体现在这个检查点中,而需要保存到下一个检查点。

这种特殊的数据形式,把一条流上的数据按照不同的检查点分隔开,所以就叫做检查点的“分界线”(Checkpoint Barrier)。

具体实现:

在JobManager中有一个“检查点协调器”,专门用来协调处理检查点相关的工作。检查点协调器会定期向TaskManager发出指令,要求保存检查点(携带检查点ID)。TaskManager会让所有的Source任务把自己的偏移量(Source任务状态)保存起来,并将带有检查的ID的分界线插入当前数据流中,然后该分界线会像正常数据一样向下游传递,当下游算子任务遇到分界线则保存自己的状态。

简单来说,就是在该需要保存检查点时,JobManager中的“检查点协调器”会向TaskManager发出指令要求保存检查点,这时,TaskManager会在会让所有的Source任务保存自己的状态,并在当前流插入一个特殊的数据(分界线),分界线会依次向下游传递,当下游的算子遇到分界线就保存自己的状态,这个分界线后面到达的数据则属于下一个检查点的数据了。这也是很符合“流”的概念。

1.1.3.2 分布式快照算法(Barrier对齐的精准一次) 

barrier指示的是“之前所有数据的状态更改保存入当前检查点”:其实是一个“截止时间”的标志。所以在处理多个分区的传递时,也要以是否还会有数据到来作为一个判断标准。

具体实现上,Flink使用了Chandy-Lamport算法的一种变体,被称为“异步分界线快照”算法。算法的核心就是两个原则:

  1. 当上游任务向多个并行下游任务发送barrier时,需要广播出去;
  2. 而当多个上游任务向同一个下游任务传递分界线时,需要在下游任务执行“分界线对齐”操作,也就是需要等到所有并行分区的barrier都到齐,才可以开始状态的保存。

检查点算法的并行场景 

当前应用全局并行度为2,Source也有两个并行任务,分别读取两条数据流,流中数据都是一个一个的单词。此时第一条流读了三条数据,Source偏移量为3.;第二条流读了一条数据,Source偏移量为1。

检查点保存算法具体过程为:

(1)触发检查点:JobManager向Source发送Barrier;

        JobManager发送指令,触发检查点保存;所有的Source任务中插入一个Barrier(分界线),并保存Source的偏移量(状态)。

        说明:检查点保存时,只会保存分界线到来前的所有状态。并且该操作并不会影响其上下游算子任务的正常运行。 

(2)Barrier发送:向下游广播发送;

        Source状态保存完成后,会返回通知给Source任务,随后Source任务会像JobManager发送ACK来确认检查点完成,然后继续将Barrier(分界线)向下游传递

        此时,由于Source算子和Map算子是一对一的关系,可以直接将Barrier传递给Map算子。

(3)向下游多个并行算子广播分界线,执行分界线对齐;

        Map算子没有状态,则直接将Barrier继续向下游传递。这时由于进行到了KeyBy分区操作,会将Barrier广播到下游并行的两个Sum任务,这时,Sum算子可能会收到来自上游两个并行Map任务的Barrier,所以需要执行“分界线对齐”操作。

        此时,Sum2接收到了上游Map传来的两个Barrier,说明第一条流的三条数据和第二条流的一条数据都已经处理完毕,则可以进行状态保存。而Sum1只收到了一个Barrier,则必须等待Barrier到齐才可以保存状态,此时Sum1分界线后的数据则会被缓存起来,等到当前检查点保存后再处理。分界线前的所有状态才会被保存。

(4)状态保存:有状态的算子将状态保存至持久化。

        各个分区的分界线到齐后,就可以对当前状态做快照,保存到持久化存储。存储完成后,同样继续将Barrier向下游继续传递,并通知JobManager检查点保存完毕。

在这个过程中,每个任务保存自己的状态都是相对独立的,互不影响,并且不影响流中其他算子的正常运行。 

说明:

        由于分界线对齐要求先到达的分区做缓存等待,一定程度上会影响处理的速度;当出现背压时,下游任务会堆积大量的缓冲数据,检查点可能需要很久才可以保存完毕。

        为了应对这种场景,Barrier对齐中提供了至少一次语义以及Flink 1.11之后提供了不对齐的检查点保存方式,可以将未处理的缓冲数据也保存进检查点。这样,当我们遇到一个分区barrier时就不需等待对齐,而是可以直接启动状态的保存了。

1.1.3.3 分布式快照算法(Barrier对齐的至少一次) 

之前的精准一次中,在进行“分界线对齐”时,下游算子必须等待上游算子发来的所有的Barrier到齐才可以进行状态保存,并且Barrier后到达的数据都会被缓存起来,不会被当前检查点所计算和保存。

而Barrier对齐的至少一次指的是,但在等待所有的Barrier到齐之前,到达该分区的数据会被直接计算,并被保存至此检查点。这样的话,如果程序重启,数据重放时,介于两个Barrier之间到达的数据会被再次计算。(至少一次)

优点:数据无需阻塞,也就不需要额外的空间对其存储。

缺点:程序重启可能会造成数据重复计算。

1.1.3.4 分布式快照算法(非Barrier对齐的精准一次)

知识:数据会先进入算子的输入缓冲区,处理完毕后进入该算子的输出缓存区,再发往下游算子的输入缓冲区。

非Barrier对齐的精准一次指的就是,当下游算子接收到一个Barrier时(到达输入缓冲区时),会直接将第一个Barrier放到输入缓冲区末端,继续向下游传递。被第一个Barrier越过的输入缓冲区和输出缓冲区的数据以及在其他Barrier之前的数据会被标记,在进行状态保存时,这些被标记的数据和状态都会被保存进检查点,在进行恢复时,则直接恢复这些数据和状态。

优点:数据无需阻塞

缺点:增大IO压力

1.1.3.5 检查点算法总结

1.Barrier对齐:一个Task等待所有上游发送同编号Barrier到齐后,才对自己的本地状态做备份。

        精准一次:在Barrier对齐过程中,Barrier后面的数据阻塞等待(被缓存),不会越过Barrier。

        至少一次:在Barrier对齐过程中,第一个Barrier后的数据不阻塞,接着计算。

2.非Barrier对齐:一个Task收到第一个Barrier时,开始执行备份,最后一个Barrier到达时结束备份。

        先到的Barrier,将本地状态备份,后面的数据接着计算

        未到的Barrier,之前的数据接着计算,同时将这些数据保存到备份中

        最后一个Barrier到达时,该Task备份结束

1.1.4 检查点配置

检查点的作用是为了故障恢复,我们不能因为保存检查点占据了大量时间、导致数据处理性能明显降低。为了兼顾容错性和处理性能,我们可以在代码中对检查点进行各种配置。

1.1.4.1 检查点常用配置

启用检查点

// 启用检查点,周期性保存(5s),默认Barrier对齐,精准一次
env.enableCheckpointing(1000);

获取检查点配置,后续配置都需要基于checkPointConfig

CheckpointConfig checkpointConfig = env.getCheckpointConfig();

指定检查点存储位置

// 指定检查点存储位置,可以是HDFS,也可以是本地路径
checkpointConfig.setCheckpointStorage("hdfs://hadoop:8001/checkpoint");

检查点执行超时时间

// checkPoint执行超时时间,超时则认为失败(默认十分钟)
checkpointConfig.setCheckpointTimeout(60000);

checkPoint最大并行数量

// 最大同时运行的checkPoint数量,推荐为1,减少程序压力
checkpointConfig.setMaxConcurrentCheckpoints(1);

checkPoint最小等待间隔 

// 最小等待间隔,指的是 上一轮checkPoint结束 到 下次checkPoint开始之间的间隔,大于0,则checkPoint最大数量为1
checkpointConfig.setMinPauseBetweenCheckpoints(1000);

取消作业时(Cancel),checkPoint的数据是否保存在外部存储系统中

checkpointConfig.setExternalizedCheckpointCleanup(CheckpointConfig.ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION
);// DELETE_ON_CANCELLATION:任务主动取消,不保留checkPoint;程序异常退出,则不会删除
// RETAIN_ON_CANCELLATION:任务主动取消,保留checkPoint

允许checkPint连续失败次数

// 允许checkPint连续失败次数,默认为0 ,超过时任务会挂掉
checkpointConfig.setTolerableCheckpointFailureNumber(10);

开启非对齐检查点(barrier非对齐)

// 开启非对齐检查点(barrier非对齐)
// 开启要求:checkPoint最大并发为1,并且checkPoint模式为精准一次
checkpointConfig.enableUnalignedCheckpoints();// 设置对齐超时时间
// 默认为0,默认直接使用非Barrier对齐
// 当对齐超时时间>1时,会先使用Barrier对齐,对齐时间超过这个参时,则切换为非Barrier对齐
checkpointConfig.setAlignedCheckpointTimeout(Duration.ofSeconds(1000));
1.1.4.2 最终检查点

如果数据源是有界的,就可能出现部分Task已经处理完所有数据,变成finished状态,不继续工作。从 Flink 1.14 开始,这些finished状态的Task,也可以继续执行检查点。自 1.15 起默认启用此功能,并且可以通过功能标志禁用它(不推荐禁用):

Configuration config = new Configuration();
config.set(ExecutionCheckpointingOptions.ENABLE_CHECKPOINTS_AFTER_TASKS_FINISH, false);
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(config);

1.1.5 保存点(Savepoint)

除了检查点外,Flink还提供了另一个非常独特的镜像保存功能——保存点(savepoint)。

从名称就可以看出,这也是一个存盘的备份,它的原理和算法与检查点完全相同,只是多了一些额外的元数据。

1.1.5.1 保存点的用途

保存点与检查点最大的区别,就是触发的时机。检查点是由Flink自动管理的,定期创建,发生故障之后自动读取进行恢复,这是一个“自动存盘”的功能;而保存点不会自动创建,必须由用户明确地手动触发保存操作,所以就是“手动存盘”。

保存点可以当作一个强大的运维工具来使用。我们可以在需要的时候创建一个保存点,然后停止应用,做一些处理调整之后再从保存点重启。它适用的具体场景有:

  • 版本管理和归档存储
  • 更新Flink版本
  • 更新应用程序
  • 调整并行度
  • 暂停应用程序

需要注意的是,保存点能够在程序更改的时候依然兼容,前提是状态的拓扑结构和数据类型不变。我们知道保存点中状态都是以算子ID-状态名称这样的key-value组织起来的,算子ID可以在代码中直接调用SingleOutputStreamOperator的.uid()方法来进行指定:

DataStream<String> stream = env.addSource(new StatefulSource()).uid("source-id") // 指定算子Uid.map(new StatefulMapper()).uid("mapper-id").print();

对于没有设置ID的算子,Flink默认会自动进行设置,所以在重新启动应用后可能会导致ID不同而无法兼容以前的状态。所以为了方便后续的维护,强烈建议在程序中为每一个算子手动指定ID。

 1.1.5.2 使用保存点

保存点的使用非常简单,我们可以使用命令行工具来创建保存点,也可以从保存点恢复作业。

1.创建保存点

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

bin/flink savepoint :jobId [:targetDirectory]

这里jobId需要填充要做镜像保存的作业ID,目标路径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]

这里只要增加一个-s参数,指定保存点的路径就可以了,其它启动时的参数还是完全一样的,如果是基于yarn的运行模式还需要加上 -yid application-id。当使用web UI进行作业提交时,可以填入的参数除了入口类、并行度和运行参数,还有一个“Savepoint Path”,这就是从保存点启动应用的配置。

1.1.5.3 使用保存点切换状态后端

在命令行重新恢复作业时,在命令行中添加以下命令以切换状态后端

-D state.backend=rocksdb

1.2  状态一致性

1.2.1 一致性的概念和级别

一致性其实就是结果的正确性,一般从数据丢失、数据重复来评估。

流式计算本身就是一个一个来的,所以正常处理的过程中结果肯定是正确的;但在发生故障、需要恢复状态进行回滚时就需要更多的保障机制了。我们通过检查点的保存来保证状态恢复后结果的正确,所以主要讨论的就是“状态的一致性”。

一般说来,状态一致性有三种级别:

  • 最多一次(At-Most-Once
  • 至少一次(At-Least-Once
  • 精确一次(Exactly-Once

1.2.2 端到端的状态一致性

在Flink中可以通过检查点机制来保障内部状态的一致性,但往往在实际应用中,Flink是从外部系统(Source)中读取数据,最终输出到外部系统(Sink)中,并不是Flink可以做到精确一次,整个程序在异常时就不会出现如何问题。例如外部数据源并不支持数据重放。这就要求我们不仅要考虑Flink内部数据的处理转换,还涉及到从外部数据源读取,以及写入外部持久化系统,整个应用处理流程从头到尾都应该是正确的。

所以完整的流处理应用,应该包括了数据源、流处理器和外部存储系统三个部分。这个完整应用的一致性,就叫做“端到端(end-to-end)的状态一致性”,它取决于三个组件中最弱的那一环。一般来说,能否达到at-least-once一致性级别,主要看数据源能够重放数据;而能否达到exactly-once级别,流处理器内部、数据源、外部存储都要有相应的保证机制。

1.3 端到端精确一次(End-To-End Exactly-Once 

实际应用中,最难做到、也最希望做到的一致性语义,无疑就是端到端(end-to-end)的“精确一次”。我们知道,对于Flink内部来说,检查点机制可以保证故障恢复后数据不丢(在能够重放的前提下),并且只处理一次,所以已经可以做到exactly-once的一致性语义了。

所以端到端一致性的关键点,就在于输入的数据源端和输出的外部存储端。

1.3.1 输入端保证 

输入端主要指的就是Flink读取的外部数据源。对于一些数据源来说,并不提供数据的缓冲或是持久化保存,数据被消费之后就彻底不存在了,例如socket文本流。对于这样的数据源,故障后我们即使通过检查点恢复之前的状态,可保存检查点之后到发生故障期间的数据已经不能重发了,这就会导致数据丢失。所以就只能保证at-most-once的一致性语义,相当于没有保证。

想要在故障恢复后不丢数据,外部数据源就必须拥有重放数据的能力。例如Fafka可以重置偏移量来达到数据重放,这也是实现端到端exactly-once的基本要求。

1.3.2 输出端保证

有了Flink的检查点机制,以及可重放数据的外部数据源,我们已经能做到at-least-once了。但是想要实现exactly-once却有更大的困难:数据有可能重复写入外部系统。

为了防止数据重复写入外部系统,保证exactly-once一致性的写入方式有两种:

  • 幂等写入
  • 事务写入

1.幂等(Idempotent)写入

所谓“幂等”操作,就是说一个操作可以重复执行很多次,但只导致一次结果更改。也就是说,后面再重复执行就不会对结果起作用了。

例如使用Redis中的键值存储、MySQL中的唯一约束等。

2.事务(Transactional)写入

事务有两种实现方式:预写日志(WAL)和两阶段提交(2PC)

1)预写日志(write-ahead-logWAL

我们发现,事务提交是需要外部存储系统支持事务的,否则没有办法真正实现写入的回撤。那对于一般不支持事务的存储系统,能够实现事务写入呢?

预写日志(WAL)就是一种非常简单的方式。具体步骤是:

①先把结果数据作为日志(log)状态保存起来

②进行检查点保存时,也会将这些结果数据一并做持久化存储

③在收到检查点完成的通知时,将所有结果一次性写入外部系统。

④在成功写入所有数据后,在内部再次确认(ack)相应的检查点,将确认信息也进行持久化保存。这才代表着检查点的真正完成。

我们会发现,这种方式类似于检查点完成时做一个批处理,一次性的写入会带来一些性能上的问题;而优点就是比较简单,由于数据提前在状态后端中做了缓存,所以无论什么外部存储系统,理论上都能用这种方式一批搞定。在Flink中DataStream API提供了一个模板类GenericWriteAheadSink,用来实现这种事务型的写入方式。

需要注意的是,预写日志这种一批写入的方式,有可能会写入失败;所以在执行写入动作之后,必须等待发送成功的返回确认消息。在成功写入所有数据后,在内部再次确认相应的检查点,这才代表着检查点的真正完成。这里需要将确认信息也进行持久化保存,在故障恢复时,只有存在对应的确认信息,才能保证这批数据已经写入,可以恢复到对应的检查点位置。

但这种“再次确认”的方式,也会有一些缺陷。如果我们的检查点已经成功保存、数据也成功地一批写入到了外部系统,但是最终保存确认信息时出现了故障,Flink最终还是会认为没有成功写入。于是发生故障时,不会使用这个检查点,而是需要回退到上一个;这样就会导致这批数据的重复写入。

2)两阶段提交(two-phase-commit2PC

前面提到的各种实现exactly-once的方式,多少都有点缺陷;而更好的方法就是两阶段提交(2PC)

顾名思义,它的想法是分成两个阶段:先做“预提交”,等检查点完成之后再正式提交。这种提交方式是真正基于事务的,它需要外部系统提供事务支持

具体的实现步骤为:

①当第一条数据到来时,或者收到检查点的分界线时,Sink任务都会启动一个事务。

②接下来接收到的所有数据,都通过这个事务写入外部系统;这时由于事务没有提交,所以数据尽管写入了外部系统,但是不可用,是“预提交”的状态。

③当Sink任务收到JobManager发来检查点完成的通知时,正式提交事务,写入的结果就真正可用了。

简单来说,就是第一条数据达到,或者分界线到达的时候开启事务,数据被写入外部系统(预提交)。检查点保存成功,则提交事务,此时数据真正可用;否则事务回滚,外部系统的数据也被回滚。

当事务中发生故障时,事务将会回滚,被写入外部系统的数据也应该被撤回。两阶段提交充分的利用了Flink的检查点机制,当分界线到来时,则开启一个事务;当检查点成功时,则提交该事务,并且该方法不用预写日志的批处理,减少了很多开销。

在我们使用Flink官方提供的连接器时,无需自己实现两阶段提交(P2P)。

不过两阶段提交虽然精巧,却对外部系统有很高的要求。这里将2PC对外部系统的要求列举如下:

  • 外部系统必须提供事务支持,或者Sink任务必须能够模拟外部系统上的事务。
  • 在检查点的间隔期间里,必须能够开启一个事务并接受数据写入。
  • 在收到检查点完成的通知之前,事务必须是“等待提交”的状态。在故障恢复的情况下,这可能需要一些时间。如果这个时候外部系统关闭事务(例如超时了),那么未提交的数据就会丢失。
  • Sink任务必须能够在进程失败后恢复事务(持久化事务至检查点)。
  • 提交事务必须是幂等操作。也就是说,事务的重复提交应该是无效的。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/243928.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

JAVA 学习 面试(六)数据类型与方法

数据类型 基本数据类型 为什么float3.4报错 3.4 默认是浮点double类型的&#xff0c;如果赋值给float是向下转型&#xff0c;会出现精度缺失&#xff0c;&#xff0c;需要强制转换 Switch支持的数据类型&#xff1f; byte、short、int、char 、 enum 、 String 基本类型与包…

使用 Swift 代码优化项目编译速度

引言 软件的性能是评价一个软件质量的重要指标&#xff0c;尤其在今天这个时代&#xff0c;性能已成为大型项目不可或缺的考虑因素之一。对于用户量极大的软件&#xff0c;如网银系统、在线购物商城等&#xff0c;更是必须保证其高效稳定的性能。在这种背景下&#xff0c;优化…

Python-基础篇-类与对象/面向对象程序设计-py脚本

面向对象基础 第一个面向对象 class Cat:def eat(self):print("小猫爱吃鱼")def drink(self):print("小猫要喝水")# 创建猫对象 tom Cat()tom.eat() tom.drink()print(tom)addr id(tom) print("%x" % addr)新建两个猫对象 class Cat:def ea…

Dockerfile-xxxx

1、Dockerfile-server FROM openjdk:8-jdk-alpine WORKDIR /app COPY . . CMD java -Xms1536M -Xmx1536M -XX:UseG1GC -jar -Dlog4j2.formatMsgNoLookupstrue -Dloader.pathresources,lib -Duser.timezoneGMT-05 /app/server-main-1.0.0.jar 2、Dockerfile-bgd #FROM openjdk…

MySQL-SQL-DQL

DQL-介绍 DQL-语法 基本查询 1、查询多个字段 2、设置别名 3、去除重复记录 条件查询 1、语法 2、条件 聚合函数 1、介绍 2、常见的聚合函数 3、语法 分组查询 1、语法 2、where与having区别 排序查询 1、语法 2、排序方式 分页查询 1、语法 DQL-执行顺序

【代码随想录】刷题笔记Day54

前言 差单调栈就结束代码随想录一刷啦&#xff0c;回家二刷打算改用python补充进博客&#xff0c;小涛加油&#xff01;&#xff01;&#xff01; 647. 回文子串 - 力扣&#xff08;LeetCode&#xff09; 双指针法 中心点外扩&#xff0c;注意中心点可能有一个元素可能有两个…

MacOS受欢迎的数据库开发工具 Navicat Premium 15 中文版

Navicat Premium 15 Mac是一款数据库管理工具&#xff0c;提供了一个全面的解决方案&#xff0c;用于连接、管理和维护各种数据库系统。以下是Navicat Premium 15 Mac的一些主要功能和特点&#xff1a; 软件下载&#xff1a;Navicat Premium 15 中文版下载 多平台支持&#xff…

PLC从HTTP服务端获取JSON文件,解析数据到寄存器

智能网关IGT-DSER集成了多种PLC协议&#xff0c;方便实现各种PLC与HTTP服务端之间通讯。通过网关的参数配置软件绑定JSON文件的字段与PLC寄存器地址&#xff0c;配置URL&#xff0c;即可采用POST命令&#xff0c;将JSON文件提交给HTTP的服务端&#xff1b; 服务端有返回的JSON&…

从 Context 看 Go 设计模式:接口、封装和并发控制

文章目录 Context 的基本结构Context 的实现和传递机制为什么 Context 不直接传递指针案例&#xff1a;DataStore结论 在 Go 语言中&#xff0c; context 包是并发编程的核心&#xff0c;用于传递取消信号和请求范围的值。但其传值机制&#xff0c;特别是为什么不通过指针传递…

RTDETR 引入 UniRepLKNet:用于音频、视频、点云、时间序列和图像识别的通用感知大卷积神经网络 | DRepConv

大卷积神经网络(ConvNets)近来受到了广泛研究关注,但存在两个未解决且需要进一步研究的关键问题。1)现有大卷积神经网络的架构主要遵循传统ConvNets或变压器的设计原则,而针对大卷积神经网络的架构设计仍未得到解决。2)随着变压器在多个领域的主导地位,有待研究ConvNets…

Ubuntu Desktop 隐藏 / 显示文件和文件夹

Ubuntu Desktop 隐藏 / 显示文件和文件夹 1. GUI hot key2. Show hidden and backup filesReferences 1. GUI hot key Ctrl H: 隐藏 / 显示文件和文件夹 2. Show hidden and backup files Edit -> Preferences -> Views References [1] Yongqiang Cheng, https://yo…

【分布式技术】消息队列Kafka

目录 一、Kafka概述 二、消息队列Kafka的好处 三、消息队列Kafka的两种模式 四、Kafka 1、Kafka 定义 2、Kafka 简介 3、Kafka 的特性 五、Kafka的系统架构 六、实操部署Kafka集群 步骤一&#xff1a;在每一个zookeeper节点上完成kafka部署 ​编辑 步骤二&#xff1a…

【数据结构】 链栈的基本操作 (C语言版)

目录 一、链栈 1、链栈的定义&#xff1a; 2、链栈的优缺点&#xff1a; 二、链栈的基本操作算法&#xff08;C语言&#xff09; 1、宏定义 2、创建结构体 3、链栈的初始化 4、链栈的进栈 5、链栈的出栈 6、获取栈顶元素 7、栈的遍历输出 8、链栈的判空 9、求链…

一周时间,开发了一款封面图生成工具

介绍 这是一款封面图的制作工具&#xff0c;根据简单的配置即可生成一张好看的封面图&#xff0c;目前已有七款主题可以选择。做这个工具的初衷来自平时写文章&#xff0c;都为封面图发愁&#xff0c;去图片 网站上搜索很难找到满意的&#xff0c;而且当你要的图如果要搭配上文…

Eureka整合seata分布式事务

文章目录 一、分布式事务存在的问题二、分布式事务理论三、认识SeataSeata分布式事务解决方案1、XA模式2、AT模式3、SAGA模式4.SAGA模式优缺点&#xff1a;5.四种模式对比 四、微服务整合Seata AT案例Seata配置微服务整合2.1、父工程项目创建引入依赖 2.2、Eureka集群搭建2.3、…

02-编程猜谜游戏

上一篇&#xff1a;01-开始Rust之旅 本章通过演示如何在实际程序中使用 Rust&#xff0c;你将了解 let 、 match 、方法、关联函数、外部crate等基础知识。 本章将实现一个经典的初学者编程问题&#xff1a;猜谜游戏。 工作原理如下&#xff1a;程序将随机生成一个介于 1 和 10…

Qt —— 自定义飞机仪表控件(附源码)

示例效果 部署环境 本人亲测版本Vs2017+Qt5.12.4,其他版本应该也可使用。 源码1 qfi_ADI::qfi_ADI( QWidget *parent ) :QGraphicsView ( parent ),m_scene ( nullptr )

牛客周赛 Round 18 解题报告 | 珂学家 | 分类讨论计数 + 状态DP

前言 整体评价 前三题蛮简单的&#xff0c;T4是一个带状态的DP&#xff0c;这题如果用背包思路去解&#xff0c;不知道如何搞&#xff0c;感觉有点头痛。所以最后还是选择状态DP来求解。 欢迎关注 珂朵莉 牛客周赛专栏 珂朵莉 牛客小白月赛专栏 A. 游游的整数翻转 这题最好…

.NET国产化改造探索(七)、更改大金仓数据库认证方式

随着时代的发展以及近年来信创工作和…废话就不多说了&#xff0c;这个系列就是为.NET遇到国产化需求的一个闭坑系列。接下来&#xff0c;看操作。 之前安装人大金仓数据库的时候&#xff0c;连接数据库所使用的加密方式选择的是scram-sm3&#xff0c;权限管理框架的ORM使用的…

k8s集群异常恢复

前提、我自己的k8s采用的是单master节点两个从节点部署&#xff0c;我针对单master情况进行恢复说明 场景一&#xff1a;正常开关虚拟机&#xff0c;可直接重启kubelet进行恢复 1、1、一般重启后三个节点都需要检查&#xff0c;输入命令检查kubelet&#xff1a; systemctl s…