fakak详解(2)

Kafka和Flume整合

Kafka与flume整合流程

Kafka整合flume流程图

flume主要是做日志数据(离线或实时)地采集。

图-21 数据处理

图-21显示的是flume采集完毕数据之后,进行的离线处理和实时处理两条业务线,现在再来学习flume和kafka的整合处理。

配置flume.conf文件

配置如下:

//为我们的source channel  sink起名

a1.sources = r1

a1.channels = c1

a1.sinks = k1

//指定我们的source收集到的数据发送到哪个管道

a1.sources.r1.channels = c1

//指定我们的source数据收集策略

a1.sources.r1.type = spooldir

a1.sources.r1.spoolDir = /opt/module/flumedata

a1.sources.r1.deletePolicy = never

a1.sources.r1.fileSuffix = .COMPLETED

a1.sources.r1.ignorePattern = ^(.)*\\.tmp$

a1.sources.r1.inputCharset = UTF-8

//指定我们的channel为memory,即表示所有的数据都装进memory当中

a1.channels.c1.type = memory

//指定我们的sink为kafka  sink,并指定我们的sink从哪个channel当中读取数据

a1.sinks.k1.channel = c1

a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink

a1.sinks.k1.kafka.topic = hadoop

a1.sinks.k1.kafka.bootstrap.servers = hadoop101:9092,hadoop102:9092,hadoop103:9092

a1.sinks.k1.kafka.flumeBatchSize = 20

a1.sinks.k1.kafka.producer.acks = 1

启动flume和kafka的整合测试

1)消费者监听读取的数据。

[root@hadoop102 kafka]$ bin/kafka-console-consumer.sh \

--topic test \

--bootstrap-server hadoop101:9092,hadoop102:9092,hadoop103:9092 \

--from-beginning

2)启动flume-agent。

[root@hadoop101 flume]$ bin/flume-ng agent --conf conf --conf-file conf/flume_kafka.conf --name a1 -Dflume.root.logger=INFO,console

3)发送与接收数据验证。

4)验证结果:显示的发送与接收数据,可以说明flume和kafka的整合成功。

Kafka架构

Kafka内部分析

Kafka架构图

通常,一个典型的Kafka集群中包含若干Producer(可以是web前端产生的Page View,或者是服务器日志,系统CPU、Memory等),若干broker(Kafka支持水平扩展,一般broker数量越多,集群吞吐率越高),若干Consumer Group,以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置,选举leader,以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker,Consumer使用pull模式从broker订阅并消费消息,如图-22所示。

图-22 kafka架构

Kafka分布式模型

kafka分布式主要是指分区被分布在多台server(broker)上,同时每个分区都有leader和follower(不是必须),即老大和小弟的角色,这儿是老大负责处理,小弟负责同步,小弟可以变成老大,形成分布式模型。

kafka的分区日志(message)被分布在kafka集群的服务器上,每一个服务器处理数据和共享分区请求。每一个分区是被复制到一系列配置好的服务器上来进行容错。

每个分区有一个server节点来作为leader和零个或者多个server节点来作为followers。leader处理指定分区的所有读写请求,同时follower被动复制leader。如果leader失败,follwers中的一个将会自动地变成一个新的leader。每一个服务器都能作为分区的一个leader和作为其它分区的follower,因此kafka集群能被很好地平衡。kafka集群是一个去中心化的集群。官网:http://kafka.apache.org/intro.html//intro_distribution

kafka消费的并行度就是kaka topic分区的个数,或者分区的个数决定了同一时间同一消费者组内最多可以有多少个消费者消费数据。

如图-23所示。

图-23 kafka生产消费模型

Kafka文件存储

Kafka文件存储结构,可以通过图-24说明清楚。

图-24 kafka文件存储模型

在kafka集群中,分单个broker和多个broker。每个broker中有多个topic,topic数量可以自己设定。在每个topic中又有1到多个partition,每个partition为一个分区。kafka分区命名规则为topic的名称+有序序号,这个序号从0开始依次增加。

每个partition中有多个segment file。创建分区时,默认会生成一个segment file,kafka默认每个segment file的大小是1G。当生产者往partition中存储数据时,内存中存不下了,就会往segment file里面刷新。在存储数据时,会先生成一个segment file,当这个segment file到1G之后,再生成第二个segment file 以此类推。每个segment file对应两个文件,分别是以.log结尾的数据文件和以.index结尾的索引文件。在服务器上,每个partition是一个目录,每个segment是分区目录下的一个文件。

每个segment file也有自己的命名规则,每个名字有20个字符,不够用0填充。每个名字从0开始命名,下一个segment file文件的名字就是,当前segment file中.log文件中第一条数据的offset。

在.index文件中,存储的是key-value格式的,key代表在.log中按顺序开始第n条消息,value代表该消息的位置偏移。但是在.index中不是对每条消息都做记录,它是每隔一些消息记录一次,避免占用太多内存。即使消息不在index记录中,在已有的记录中查找,范围也大大缩小了。

.index中存放的消息索引是一个稀疏索引列表。

topic中的partition

为什么要分区

可以想象,如果一个topic就一个分区,要是这个分区有1T数据,那么kafka就想把大文件划分到更多的目录来管理,这就是kafka所谓的分区。

分区的好处

1)方便在集群中扩展。因为一个topic由一个或者多个partition构成,而每个节点中通常可以存储多个partition,这样就方便分区存储与移动,也就增加其扩展性。同时也可以增加其topic的数据量。

2)可以提高并发。因为一个主题多个partition,而每个主题读写数据时,其实就是读写不同的partition,所以增加其并发。

单节点partition的存储分布

Kafka集群只有一个broker,默认/var/log/kafka-log为数据文件存储根目录,在Kafka broker中server.properties文件配置(参数log.dirs=/opt/module/kafka/data),例如创建2个topic名称分别为test-1、test-2, partitions数量都为partitions=4。

存储路径和目录规则为:

 |--test-1-0  

 |--test-1-1

 |--test-1-2

 |--test-1-3

 |--test-2-0

 |--test-2-1

 |--test-2-2

 |--test-2-3

在Kafka文件存储中,同一个topic下有多个不同partition,每个partition为一个目录,partiton命名规则为:topic名称+分区编号(有序),第一个partiton序号从0开始,序号最大值为partitions数量减1。

多节点partition存储分布

Kafka多节点partition存储分布如图-25所示。

图-25 kafka多节点partition存储

数据分配策略

前面已经讲过了。

1)如果指定了partition,进入该partition。

2)如果没有指定该partition,但是指定key,通过key的字节数组信息的hashcode值和partition数求模确定partition。

3)如果都没有指定,通过轮询方式进入对应的partition。

Kafka的发送与存储策略

partition中文件存储

如图-26是一个partition-0的一个存储示意图。

图-26 partition存储

1)每个分区一个目录,该目录中是一堆segment file(默认一个segment是1G),该目录和file都是物理存储于磁盘。

2)每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等,这种特性方便old segment file快速被删除。

3)每个partiton只需要支持顺序读写就行了,segment文件生命周期由服务端配置参数决定。

4)这样做的好处就是能快速删除无用文件,有效提高磁盘利用率。

kafka分区中的segemnt

通过上一节我们知道Kafka文件系统是以partition方式存储,下面深入分析partitiion中segment file组成和物理结构,如图-27和图-28。

图-27 partition物理目录组成

索引文件与数据文件的关系

既然它们是一一对应成对出现,必然有关系。索引文件中元数据指向对应数据文件中message的物理偏移地址

比如索引文件中3,497代表:数据文件中的第三个message,它的偏移地址为497。再来看数据文件中,Message 368772表示:在全局partiton中是第368772个message。

注:segment index file采取稀疏索引存储方式,它减少索引文件大小,通过mmap可以直接内存操作,稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间,但查找起来更耗时。

图-28 segment文件物理结构

通过上面两张图,我们已经知道topic、partition、segment、.log、.index等文件的关系,下面深入看看segment相关组成原理。

1)segment file组成:由2大部分组成,分别为index file和log file(即数据文件),这2个文件一一对应,成对出现,后缀".index"和“.log”分别表示为segment索引文件、数据文件。

2)segment文件命名规则:partition全局的第一个segment从0开始,后续每个segment文件名为当前segment文件段.log文件当中第一条数据的offset。数值最大为64位long大小,20位数字字符长度,不够的左边用0填充。

3)查看segment文件内容如下:

查看.log脚本:

${KAFKA_HOME}/bin/kafka-run-class.sh kafka.tools.DumpLogSegments \

--files 00000000000000000000.log --print-data-log

结果:

Starting offset: 0

offset: 0 position: 0 CreateTime: 1577994283622 isvalid: true keysize: -1 valuesize: 1 magic: 2 compresscodec: NONE producerId: -1 producerEpoch: -1 sequence: -1 isTransactional: false headerKeys: [] payload: a

offset: 1 position: 69 CreateTime: 1577994466159 isvalid: true keysize: -1 valuesize: 1 magic: 2 compresscodec: NONE producerId: -1 producerEpoch: -1 sequence: -1 isTransactional: false headerKeys: [] payload: 1

offset: 2 position: 138 CreateTime: 1577994474463 isvalid: true keysize: -1 valuesize: 1 magic: 2 compresscodec: NONE producerId: -1 producerEpoch: -1 sequence: -1 isTransactional: false headerKeys: [] payload: 4

查看.index脚本:

${KAFKA_HOME}/bin/kafka-run-class.sh kafka.tools.DumpLogSegments \

--files 00000000000000000000.index --print-data-log

结果:

Dumping 00000000000000000000.index

offset: 0 position: 0

Kafka中的push和pull

一个较早问题是我们应该考虑是消费者从broker中pull数据还是broker将数据push给消费者。kakfa遵守传统设计和借鉴很多消息系统,这儿kafka选择producer向broker去push消息,并由consumer从broker pull消息。一些logging-centric system,比如Facebook的Scribe和Cloudera的Flume,采用非常不同的push模式。事实上,push模式和pull模式各有优劣。

1)push模式很难适应消费速率不同的消费者,因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息,但是这样很容易造成consumer来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

2)pull模式不足之处是,如果kafka没有数据,消费者可能会陷入循环中,一直返回空数据。针对这一点,Kafka的消费者在消费数据时会传入一个时长参数timeout,如果当前没有数据可供消费,consumer会等待一段时间之后再返回,这段时长即为timeout。

kafka中数据发送保障

为保证producer发送的数据,能可靠的发送到指定的topic,topic的每个partition收到producer发送的数据后,都需要向producer发送ack(acknowledgement确认收到),如果producer收到ack,就会进行下一轮的发送,否则重新发送数据,如图-29所示。

图-29 数据发送流程

副本数据同步策略:

表-1 同步策略

方案

优点

缺点

半数以上完成同步,就发送ack

延迟低

选举新的leader时,容忍n台节点的故障,需要2n+1个副本

全部完成同步,才发送ack

选举新的leader时,容忍n台节点的故障,需要n+1个副本

延迟高

Kafka选择了第二种方案,原因如下:

1)同样为了容忍n台节点的故障,第一种方案需要2n+1个副本,而第二种方案只需要n+1个副本,而Kafka的每个分区都有大量的数据,第一种方案会造成大量数据的冗余。

2)虽然第二种方案的网络延迟会比较高,但网络延迟对Kafka的影响较小。

ISR:采用第二种方案之后,设想以下情景:leader收到数据,所有follower都开始同步数据,但有一个follower,因为某种故障,迟迟不能与leader进行同步,那leader就要一直等下去,直到它完成同步,才能发送ack。这个问题怎么解决呢?

Leader维护了一个动态的in-sync replica set (ISR),意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后,leader就会给Producer发送ack。如果follower长时间未向leader同步数据,则该follower将被踢出ISR,该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后,就会从ISR中选举新的leader。

需要注意的是:

1)生产者发送到特定主题分区的消息是将按照发送的顺序来追加。也就是说,如果消息M1和消息M2由相同的生产者发送,并且M1是先发送的,那么M1的偏移量将比M2低,并出现在日志的前面。

2)消费者是按照存储在日志中记录顺序来查询消息。

3)对于具有n个副本的主题,我们将容忍最多N-1个服务器失败故障,从而不会丢失提交到日志的任何消息记录。

ack应答机制

对于某些不太重要的数据,对数据的可靠性要求不是很高,能够容忍数据的少量丢失,所以没必要等ISR中的follower全部接收成功。

所以Kafka为用户提供了三种可靠性级别,用户根据对可靠性和延迟的要求进行权衡,选择以下的配置,如图-30所示。

图-30 ack应答机制

故障处理细节,如图-31所示。

图-31 故障处理机制

故障机制分为了follower和leader故障,如图-31所示的,具体解释如下:

1)follower故障:follower发生故障后会被临时踢出ISR,待该follower恢复后,follower会读取本地磁盘记录的上次的HW,并将log文件高于HW的部分截取掉,从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW,即follower追上leader之后,就可以重新加入ISR了。

2)leader故障:leader发生故障之后,会从ISR中选出一个新的leader,之后,为保证多个副本之间的数据一致性,其余的follower会先将各自的log文件高于HW的部分截掉,然后从新的leader同步数据。

注意:这只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。

Kafka msg flush and retention

Flush策略

# Log Flush Policy

# Messages are immediately written to the filesystem but by default we only fsync() to sync

# the OS cache lazily. The following configurations control the flush of data to disk.

# There are a few important trade-offs here:

# 1. Durability: Unflushed data may be lost if you are not using replication.

# 2. Latency: Very large flush intervals may lead to latency spikes when the flush does occur as there will be a lot of data to flush.

# 3. Throughput: The flush is generally the most expensive operation, and a small flush interval may lead to excessive seeks.

# The settings below allow one to configure the flush policy to flush data after a period of time or

# every N messages (or both). This can be done globally and overridden on a per-topic basis.

# The number of messages to accept before forcing a flush of data to disk

// 每当每一个topic接收到10000条message的时候,就会将数据flush到磁盘

log.flush.interval.messages=10000

# The maximum amount of time a message can sit in a log before we force a flush

//每隔1s flush一次数据

log.flush.interval.ms=1000

为了提供kafka的读写数据能力,首先接收数据到kafka内存,不可能无限制的保存在内存,所以必然会将数据flush到磁盘(partition的segement)文件,在flush的时候做了Durability(持久性)和Latency(延迟)和Throughput(吞吐量)的权衡与取舍。

Retention策略

# Log Retention Policy

# The following configurations control the disposal of log segments. The policy can

# be set to delete segments after a period of time, or after a given size has accumulated.

# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens

# from the end of the log.

# The minimum age of a log file to be eligible for deletion due to age

// 日志最小的保留时间:7天,超过这个时间,数据可能会被清理掉

log.retention.hours=168

//log.retention.days=7

# A size-based retention policy for logs. Segments are pruned(裁剪) from the log unless the remaining

# segments drop below log.retention.bytes. Functions independently of log.retention.hours.

// segement文件如果超过log.retention.bytes的配置,将会可能被裁剪,直到小于log.retention.bytes配置

#log.retention.bytes=1073741824

# The maximum size of a log segment file. When this size is reached a new log segment will be created.

// 一个segment文件最大的大小,超过log.segment.bytes一个G,将会创建一个新的segment文件

log.segment.bytes=1073741824

# The interval at which log segments are checked to see if they can be deleted according

# to the retention policies

// 每隔5分钟,检测一次retention策略是否达到

log.retention.check.interval.ms=300000

partition对应的文件,就保存在一个个的segment文件中,每一个文件默认大小是1G,但是log.retention.check.interval.ms监测频率是5分钟一次。

所以segment文件可能会超过1G,此时就会启动retion策略,将文件裁剪到log.retention.bytes配置,如果超过了log.segment.bytes=1G配置,将会创建一个新的segment文件;默认情况,segment文件会保留7天。

Kafka高性能之道

Kafka高性能原因

高效使用磁盘

1)顺序写磁盘,顺序写磁盘性能高于随机写内存。

2)Append Only 数据不更新,无记录级的数据删除(只会整个segment删s除)。读操作可直接在page cache内进行。如果进程重启,JVM内的cache会失效,但page cache仍然可用。

3)充分利用Page Cache:I/O Scheduler将连续的小块写组装成大块的物理写从而提高性能。I/O Scheduler会尝试将一些写操作重新按顺序排好,从而减少磁盘头的移动时间。

4)充分利用所有空闲内存(非JVM内存):应用层cache也会有对应的page cache与之对应,直接使用pagecache可增大可用cache,如使用heap内的cache,会增加GC负担

5)可通过如下参数强制flush,但并不建议这么做。

log.flush.interval.messages=10000

log.flush.interval.ms=1000

6)支持多Directory(目录)。

零拷贝

传统方式实现:

先读取、再发送,实际经过 1~4 四次 copy。

分别是:

第一次:将磁盘文件,读取到操作系统内核缓冲区;

第二次:将内核缓冲区的数据,copy 到 application 应用程序的 buffer;

第三步:将 application 应用程序 buffer 中的数据,copy 到 socket 网络发送缓冲区(属于操作系统内核的缓冲区);

第四次:将 socket buffer 的数据,copy 到网卡,由网卡进行网络传输。

kafka 作为 MQ 也好,作为存储层也好,无非是两个重要功能,一是 Producer 生产的数据存到 broker,二是 Consumer 从 broker 读取数据;我们把它简化成如下两个过程:

网络数据持久化到磁盘 (Producer 到 Broker)

磁盘文件通过网络发送(Broker 到 Consumer)

批处理和压缩

1)Producer和Consumer均支持批量处理数据,从而减少了网络传输的开销。

2)Producer可将数据压缩后发送给broker,从而减少网络传输代价。目前支持Snappy,Gzip和LZ4压缩。

Partition

1)通过Partition实现了并行处理和水平扩展。

2)Partition是Kafka(包括kafka Stream)并行处理的最小单位。

3)不同Partition可处于不同的Broker,充分利用多机资源。

4)同一Broker上的不同Partition可置于不同的Directory。

ISR

1)ISR(in-sync-replica)实现了可用性和一致性的动态平衡。

//如果这个时间内follower没有发起fetch请求,被认为dead,从ISR移除

replica.log.time.max.ms=10000

//如果follower相比leader落后这么多以上消息条数,会被从ISR移除

replica.log.max.messages=4000

2)ISR可容忍更多的节点失败:Majority Quorum如果要容忍f个节点失败,至少需要2f+1个节点(zookeeper,journalnode)。ISR如果要容忍f个节点失败,至少需要f+1个节点。

3)如何处理Replica Crach:Leader crash后,ISR中的任何replica皆可竞选成为Leader。如果所有replica都crash,可选择让第一个recover的replica或者第一个在ISR中的replica成为leader。unclean.leader.election.enable=true

Kafka性能影响因子

性能影响因子

1)Producer:

图-35 性能影响因子之producer

如图-35所示,producer个数和吞吐量成正比。

2)Consumer:

图-36 性能影响因子之consumer

如图-36所示,consumer个数在没有达到partition个数之前,和消费的吞吐量成正比。

3)Partition:

图-37 性能影响因子之partition

如图-37所示,分区个数和生产的吞吐量,在一定范围内,先增长,当达到某一个值之后趋于稳定,在上下浮动。

4)Message-size:

图-38 性能影响因子之message

如图-38所示,随着message size的增大,生产者对应的每秒生成的记录数在成下降趋势,生产的数据体积成上升趋势。

5)Replication:

图-39 性能影响因子之replication

如图-39所示,副本越大,自然需要同步数据的量就越多,自然kafka的生成的吞吐量就越低。

性能检测方式

可以借助kafka脚本来查看kafka集群性能。

1)kafka-producer-perf-test.sh:通过该脚本查看kafka生产者的性能,如图-40所示。

图-40 生产性能评估

bin/kafka-producer-perf-test.sh --topic hadoop \

--num-records 100000 \ -->测试生成多少条记录

--throughput 10000 \ --->生产者的吞吐量,约等于messages/sec

--record-size 10 \ -->每条消息的大小

--producer.config config/producer.properties

2)kafka-consumer-perf-test.sh:通过该脚本查看kafka消费者的性能,如图-41所示。

图-41 生产性能评估

读取到的结果:

start.time=2019-08-06 02:31:23:738 --->开始时间

end.time=2019-08-06 02:31:24:735 --->结束时间

data.consumed.in.MB=0.9534 --->总共消费的数据体积

MB.sec=0.9562     --->每秒钟消费数据体积

data.consumed.in.nMsg=100000 --->总共消费的数据记录数

nMsg.sec=100300.9027 --->每秒钟消费记录数

rebalance.time.ms=47 --->进行rebalance的时间

fetch.time.ms=950 --->抓取这10w条数据总共花费多长时间

fetch.MB.sec=1.0035 --->每秒钟抓取数据体积

fetch.nMsg.sec=105263.1579 --->每秒钟抓取数据记录数

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

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

相关文章

微信小程序开发工具的使用,各个配置文件详解,小程序开发快速入门

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,…

redis单线程模型

工作原理 在Redis中,当两个客户端同时发送相同的请求时,Redis采用单线程模型来处理所有的客户端请求,会依次处理这些请求,每个请求都会按照先后顺序被执行,不会同时处理多个请求。使得Redis能够避免多线程并发访问数据…

大语言模型应用指南:以ChatGPT为起点,从入门到精通的AI实践教程

目录 前言ChatGPT问世和发展展望未来大语言模型应用指南 特点大语言模型应用指南 主要内容 前言 在20世纪末和21世纪初,人类经历了两次信息革命的浪潮。 第一次是互联网时代的兴起,将世界各地连接在一起,改变了人们获取信息和交流的方式。 …

函数式接口及Stream流式计算

一、什么是函数式接口 只有一个方法的接口,例如 FunctionalInterface public interface Runnable { public abstract void run(); }二、Function函数式接口:有一个输入参数,有一个输出 三、断定型接口:有一个输入参数&#xf…

《ElementPlus 与 ElementUI 差异集合》el-select 显示下拉列表在 Cesium 场景中无法监听关闭

前言 仅在 Element UI 时有此问题,Element Plus 由于内部结构差异较大,不存在此问题。详见《el-select 差异点,如:高、宽、body插入等》; 问题 点击空白处,下拉列表可监听并关闭;但在 Cesium…

【js】解决自动生成颜色时相邻颜色视觉相似问题的技术方案

解决自动生成颜色时相邻颜色视觉相似问题的技术方案 在进行大规模颜色生成时,特别是在数据可视化、用户界面设计等应用领域,一个常见的挑战是确保相邻颜色在视觉上具有足够的区分度。本文介绍的方法通过结合黄金分割比与饱和度、亮度的周期性变化&#…

数据分析_时间维度对比及变化可视化分析(Pandas和Matplotlib)

数据分析_时间维度对比及变化可视化分析(Pandas和Matplotlib) 分析维度包括: 各年度合计销量 各年度合计销售额 各年度平均每公斤销售额 各月度销量对比 各月度销售额变化 构建测试数据 这里你可以了解到: 如何生成时间相关的数据。 如何从列表(可迭代对象…

Linux多进程(二)进程通信方式一 管道

管道的是进程间通信(IPC - InterProcess Communication)的一种方式,管道的本质其实就是内核中的一块内存(或者叫内核缓冲区),这块缓冲区中的数据存储在一个环形队列中,因为管道在内核里边,因此我们不能直接…

Vue 双向绑定、diff和nextTick原理

前言 什么是虚拟dom virtual DOM 虚拟DOM,用普通js对象来描述DOM结构,因为不是真实DOM,所以称之为虚拟DOM。 虚拟 dom 是相对于浏览器所渲染出来的真实 dom而言的,在react,vue等技术出现之前,我们要改变页面…

LabVIEW专栏八、类

该章目的是可以开发仪器类。 一、类的概述 一般来说类有三大特性,封装,继承和多态。 在实际项目中,最主要是继承和多态,要搞清楚这两者的概念和在LabVIEW中是怎样应用的。在LabVIEW中,面向对象编程用到的就是LabVIE…

SAM在低阶自适应航空土地覆盖分类中的应用2024.01

GEOSCIENCE AND REMOTE SENSING LETTERS 2024.01 提出了一种新的语义分割模型,该模型结合了SAM的图像编码器和低秩自适应方法(LoRA),用于航空图像的特征提取和微调。我们还使用了一个辅助CNN编码器来促进下游适应,并补充ViT编码器在密集视觉…

机器学习模型效果不好及其解决办法

当训练出来的机器学习模型效果不佳时,可能涉及多个方面的原因。为了改善模型的效果,需要系统地检查和分析问题的根源,并采取相应的措施进行优化。 一、数据问题 数据质量 检查数据是否干净、完整,是否存在噪声、异常值或缺失值。…

【MySQL】A01、性能优化-语句分析

1、数据库优化方向 A、SQL及索引优化 根据需求写出良好的SQL,并创建有效的索引,实现某一种需求可以多种写法,这时候我们就要选择一种效率最高的写法。这个时候就要了解sql优化 B、数据库表结构优化 根据数据库的范式,设计表结构&…

从C向C++14——STL初识及函数对象

一.STL初识 1.STL的诞生 长久以来,软件界一直希望建立一种可重复利用的东西C的面向对象和泛型编程思想,目的就是复用性的提升多情况下,数据结构和算法都未能有一套标准,导致被迫从事大量重复工作为了建立数据结构和算法的一套标准,诞生了ST…

详解汽车充电桩主板的硬件设计与软件系统

随着电动汽车时代的到来,充电桩逐渐成为城市新地标。而在每一个充电桩的核心,隐藏着一颗强大的“心脏”——充电桩主板。 充电桩主板是充电桩的核心部件,决定着充电桩的充电效率、安全和用户体验。今天,我们将深入探索汽车充电桩主…

分布式版本控制工具 Git 的使用方式

文章目录 Git简介下载安装基本使用起始配置Git 的三个区域基本操作流程查看仓库状态删除(撤销暂存区)差异对比查看版本日志版本回退修改提交日志分支概念:创建分支与切换分支合并分支(快速合并)合并分支(提…

北京筑龙当选中招协第二届招标采购数字化专业委员会执行主任单位

4月18-19日,中国招标投标协会(以下简称中招协)2024年年会在宁波召开,北京筑龙作为中招协理事会员单位受邀出席会议。会议期间举行了“电子招标采购专业委员会换届会议暨第二届第一次工作会议”,北京筑龙当选第二届招标…

用代码给孩子造“钱”

起因 作为家里有两个娃的奶爸,时长为了孩子乱花钱而焦虑不已。然后最近看到一段短视频说了这么段话。 父母不要被动给孩子买东西,而是定期给孩子钱。让孩子自己管钱培养她对于钱的认知和理财的观念。 突然感觉大师我悟了。感觉值得一试。于是就打算给他…

如何在官网查看Qt5的所有模块?

2024年4月23日,周二上午 如果你不想一步步来的话,可以直接去这个Qt官方链接 https://doc.qt.io/qt-5/qtmodules.html 第一步:去到Qt官网 https://www.qt.io/ 第二步:点击文档链接 第三步:选择文档中的“Qt5” 第四步…

Python中的tkinter工具包帮助文档查询以及Python其他GUI工具包分类

Python中的tkinter工具包帮助文档查询以及Python其他GUI工具包分类 虽然Python支持许多GUI工具包,然而Tkinter是Python的实际标准GUI(图形用户界面)包,也是最常用的一种。本文简要介绍tkinter工具包帮助文档查询以及Python其他GU…