【Kafka专题】Kafka集群架构设计原理详解
目录
- 前言
- 前置知识
- 课程内容
- 一、Kafka的Zookeeper元数据梳理
- 1.1 zookeeper整体数据
- 1.2 Controller Broker选举机制
- 1.3 Leader Partition选举机制
- 1.4 Leader Partition自动平衡机制
- *1.5 Partition故障恢复机制
- 1.6 HW一致性保障-Epoch更新机制
- 1.7 总结
- 学习总结
- 感谢
前言
Kafka的天生就是为了保证高吞吐,高性能,高可扩展的三高架构设计的,所以如果在学习中,遇到一些无法理解的,你可以适当地从这三高点入手理解。
前置知识
服务端Broker:一个Kafka服务器就是一个Broker(在MQ中经常出现的一个名词:中介者)
课程内容
一、Kafka的Zookeeper元数据梳理
1.1 zookeeper整体数据
Kafka将状态信息保存在Zookeeper中,这些状态信息记录了每个Kafka的Broker服务与另外的Broker服务有什么不同。通过这些差异化的功能,共同体现出集群化的业务能力。这些数据,需要在集群中各个Broker之间达成共识,因此,需要存储在一个所有集群都能共同访问的第三方存储中。
这些共识数据需要保持强一致性,这样才能保证各个Broker的分工是同步、清晰的。而基于CP实现的Zookeeper就是最好的选择。另外,Zookeeper的Watcher机制也可以很好的减少Broker读取Zookeeper的次数。
Kafka在Zookeeper上管理了哪些数据呢?这个问题可以先回顾一下Kafka的整体集群状态结构,然后再去Zookeeper上验证。
Kafka的整体集群结构如下图。其中红色字体标识出了重要的状态信息:
Kafka的集群中,最为主要的状态信息有两个。一个是在多个Broker中,需要选举出一个Broker,担任Controller角色。由Controller角色来管理整个集群中的分区和副本状态。另一个是在同一个Topic下的多个相同Partition中,需要选举出一个Leader角色。由Leader角色的Partition来负责与客户端进行数据交互。
这些状态信息都被Kafka集群注册到了Zookeeper中。Zookeeper数据整体如下图:
对于Kafka往Zookeeper上注册的这些节点,大部分都是比较简明的。比如/brokers/ids下,会记录集群中的所有BrokerId,/topics目录下,会记录当前Kafka的Topic相关的Partition分区等信息。下面就从这些Zookeeper的基础数据开始,来逐步梳理Kafka的Broker端的重要流程。
例如集群中每个Broker启动后,都会往Zookeeper注册一个临时节点/broker/ids/{BrokerId}。可以做一个试验验证一下。如果启动了Zookeeper和Kafka后,服务器非正常关机,这时Zookeeper上的这个临时节点就不会注销。下次重新启动Kafka时,就有可能因为无法注册上这个临时节点而报错。
1.2 Controller Broker选举机制
在Kafka集群进行工作之前,需要选举出一个Broker来担任Controller角色,负责整体管理集群内的分区和副本状态。选举Controller的过程原理其实很简单,就是通过抢占Zookeeper的/controller节点来实现的。换句话说,所有的Broker谁先往zookeeper成功注册/controller
节点,谁就是controller broker。
当一个集群内的Kafka服务启动时,就会尝试往Zookeeper上创建一个/controller临时节点,并将自己的brokerid写入这个节点。节点的内容如下:
{"version":1,"brokerid":0,"timestamp":"1661492503848"}
当一个应用在Zookeeper上创建了一个临时节点后,Zookeeper需要这个应用一直保持连接状态。如果Zookeeper长时间检测不到应用的心跳信息,就会删除临时节点。同时,Zookeeper还允许应用监听节点的状态,当应用状态有变化时,会向该节点对应的所有监听器广播节点变化事件。
这样,如果集群中的Controller节点服务宕机了,Zookeeper就会删除/controller节点。而其他未注册成功的Broker节点,就会感知到这一事件,然后开始竞争,再次创建临时节点。这就是Kafka基于Zookeeper的Controller选举机制。
选举产生的Controller节点,就会负责监听Zookeeper中的其他一些关键节点,触发集群的相关管理工作。例如:
- 监听Zookeeper中的/brokers/ids节点,感知Broker增减变化
- 监听/brokers/topics,感知topic以及对应的partition的增减变化
- 监听/admin/delete_topic节点,处理删除topic的动作
另外,Controller还需要负责将元数据推送给其他Broker。
1.3 Leader Partition选举机制
在Kafka中,一个Topic下的所有消息,是分开存储在不同的Partition中的。在使用kafka-topics.sh脚本创建Topic时,可以通过–partitions 参数指定Topic下包含多少个Partition,还可以通过–replication-factors参数指定每个Partition有几个备份。而在一个Partition的众多备份中,需要选举出一个Leader Partition,负责对接所有的客户端请求,并将消息优先保存,然后再通知其他Follower Partition来同步消息。
在理解Leader Partition选举机制前,需要了解几个基础的概念:
AR
:Assigned Repllicas。 表示Kafka分区中的所有副本(存活的和不存活的)ISR
:表示在所有AR中,服务正常,保持与Leader同步的Follower集合。如果Follower长时间没有向Leader发送通信请求(超时时间由replica.lag.time.max.ms参数设定,默认30S),那么这个Follower就会被提出ISR中。(在老版本的Kafka中,还会考虑Partition与Leader Partition之间同步的消息差值,大于参数replica.lag.max.messages条就会被移除ISR。现在版本已经移除了这个参数)OSR
:表示从ISR中踢出的节点。记录的是那些服务有问题,延迟过多的副本
其中,AR和ISR比较关键,可以通过kafka-topics.sh的–describe指令查看。
[oper@worker1 kafka_2.13-3.2.0]$ bin/kafka-topics.sh -bootstrap-server worker1:9092 --describe --topic disTopic
Topic: disTopic TopicId: vX4ohhIER6aDpDZgTy10tQ PartitionCount: 4 ReplicationFactor: 2 Configs: segment.bytes=1073741824Topic: disTopic Partition: 0 Leader: 2 Replicas: 2,1 Isr: 2,1Topic: disTopic Partition: 1 Leader: 1 Replicas: 1,0 Isr: 1,0Topic: disTopic Partition: 2 Leader: 2 Replicas: 0,2 Isr: 2,0Topic: disTopic Partition: 3 Leader: 2 Replicas: 2,0 Isr: 2,0
这个结果中,AR就是Replicas列中的Broker集合。而这个指令中的所有信息,其实都是被记录在Zookeeper中的。
接下来,Kafka设计了一套非常简单高效的Leader Partition选举机制。在选举Leader Partition时,会按照AR中的排名顺序,靠前的优先选举。只要当前Partition在ISR列表中,也就是是存活的,那么这个节点就会被选举成为Leader Partition。
例如,我们可以设计一个实验来验证一下LeaderPartiton的选举过程。
#1、创建一个备份因子为3的Topic,每个Partition有3个备份。
[oper@worker1 kafka_2.13-3.2.0]$ bin/kafka-topics.sh --bootstrap-server worker1:9092 --create --replication-factor 3 --partitions 4 --topic secondTopic
Created topic secondTopic.
#2、查看Topic的Partition情况 可以注意到,默认的Leader就是ISR的第一个节点。
[oper@worker1 kafka_2.13-3.4.0]$ bin/kafka-topics.sh -bootstrap-server worker1:9092 --describe --topic secondTopic
Topic: secondTopic TopicId: W3mXDtj1RsWmsEhQrZjN5g PartitionCount: 4 ReplicationFactor: 3 Configs: Topic: secondTopic Partition: 0 Leader: 1 Replicas: 1,0,2 Isr: 1,0,2Topic: secondTopic Partition: 1 Leader: 0 Replicas: 0,2,1 Isr: 0,1,2Topic: secondTopic Partition: 2 Leader: 2 Replicas: 2,1,0 Isr: 1,0,2Topic: secondTopic Partition: 3 Leader: 1 Replicas: 1,2,0 Isr: 1,0,2
#3、在worker3上停掉brokerid=2的kafka服务。
[oper@worker3 kafka_2.13-3.2.0]$ bin/kafka-server-stop.sh
#4、再次查看SecondTopic上的Partiton分区情况
[oper@worker1 kafka_2.13-3.4.0]$ bin/kafka-topics.sh -bootstrap-server worker1:9092 --describe --topic secondTopic
Topic: secondTopic TopicId: W3mXDtj1RsWmsEhQrZjN5g PartitionCount: 4 ReplicationFactor: 3 Configs: Topic: secondTopic Partition: 0 Leader: 1 Replicas: 1,0,2 Isr: 1,0Topic: secondTopic Partition: 1 Leader: 0 Replicas: 0,2,1 Isr: 0,1Topic: secondTopic Partition: 2 Leader: 1 Replicas: 2,1,0 Isr: 1,0Topic: secondTopic Partition: 3 Leader: 1 Replicas: 1,2,0 Isr: 1,0
从实验中可以看到,当BrokerId=2的kafka服务停止后,2号BrokerId就从所有Partiton的ISR列表中剔除了。然后,Partition2的Leader节点原本是Broker2,当Broker2的Kafka服务停止后,都重新进行了Leader选举。Parition2预先评估的是Replicas列表中Broker2后面的Broker1,Broker1在ISR列表中,所以他被最终选举成为Leader。当Partiton选举完成后,Zookeeper中的信息也被及时更新了。
/brokers/topics/secondTopic: {"partitions":{"0":[1,0,2],"1":[0,2,1],"2":[2,1,0],"3":[1,2,0]},"topic_id":"W3mXDtj1RsWmsEhQrZjN5g","adding_replicas":{},"removing_replicas":{},"version":3}
/brokers/topics/secondTopic/partitions/0/state: {"controller_epoch":20,"leader":1,"version":1,"leader_epoch":2,"isr":[1,0]}
Leader Partitoin选举机制能够保证每一个Partition同一时刻有且仅有一个Leader Partition。但是,是不是只要分配好了Leader Partition就够了呢?
1.4 Leader Partition自动平衡机制
在一组Partiton中,Leader Partition通常是比较繁忙的节点,因为他要负责与客户端的数据交互,以及向Follower同步数据。默认情况下,Kafka会尽量将Leader Partition分配到不同的Broker节点上,用以保证整个集群的性能压力能够比较平均。
但是,经过Leader Partition选举后,这种平衡就有可能会被打破,让Leader Partition过多的集中到同一个Broker上。这样,这个Broker的压力就会明显高于其他Broker,从而影响到集群的整体性能。为此,Kafka设计了Leader Partition自动平衡机制,当发现Leader分配不均衡时,自动进行Leader Partition调整。
Kafka在进行Leader Partition自平衡时的逻辑是这样的:他会认为AR当中的第一个节点就应该是Leader节点。这种选举结果成为preferred election 理想选举结果。Controller会定期检测集群的Partition平衡情况,在开始检测时,Controller会依次检查所有的Broker。当发现这个Broker上的不平衡的Partition比例高于leader.imbalance.per.broker.percentage
阈值时,就会触发一次Leader Partiton的自平衡。这个机制涉及到Broker中server.properties配置文件中的几个重要参数:
#1 自平衡开关。默认true
auto.leader.rebalance.enable
Enables auto leader balancing. A background thread checks the distribution of partition leaders at regular intervals, configurable by `leader.imbalance.check.interval.seconds`. If the leader imbalance exceeds `leader.imbalance.per.broker.percentage`, leader rebalance to the preferred leader for partitions is triggered.
Type: boolean
Default: true
Valid Values:
Importance: high
Update Mode: read-only
#2 自平衡扫描间隔
leader.imbalance.check.interval.seconds
The frequency with which the partition rebalance check is triggered by the controller
Type: long
Default: 300
Valid Values: [1,...]
Importance: high
Update Mode: read-only
#3 自平衡触发比例
leader.imbalance.per.broker.percentage
The ratio of leader imbalance allowed per broker. The controller would trigger a leader balance if it goes above this value per broker. The value is specified in percentage.Type: int
Default: 10
Valid Values:
Importance: high
Update Mode: read-only
这几个参数可以到broker的server.properties文件中修改。但是注意要修改集群中所有broker的文件,并且要重启Kafka服务才能生效。
另外,你也可以通过手动调用kafka-leader-election.sh
脚本,触发一次自平衡。例如:
# 启动worker3上的Kafka服务,Broker2上线。
# secondTopic的partion2不是理想状态。理想的leader应该是2
[oper@worker1 kafka_2.13-3.4.0]$ bin/kafka-topics.sh -bootstrap-server worker1:9092 --describe --topic secondTopic
Topic: secondTopic TopicId: W3mXDtj1RsWmsEhQrZjN5g PartitionCount: 4 ReplicationFactor: 3 Configs: Topic: secondTopic Partition: 0 Leader: 1 Replicas: 1,0,2 Isr: 1,0,2Topic: secondTopic Partition: 1 Leader: 0 Replicas: 0,2,1 Isr: 0,1,2Topic: secondTopic Partition: 2 Leader: 1 Replicas: 2,1,0 Isr: 1,0,2Topic: secondTopic Partition: 3 Leader: 1 Replicas: 1,2,0 Isr: 1,0,2
# 手动触发所有Topic的Leader Partition自平衡
[oper@worker1 bin]$ ./kafka-leader-election.sh --bootstrap-server worker1:9092 --election-type preferred --topic secondTopic --partition 2
Successfully completed leader election (PREFERRED) for partitions secondTopic-2
# 自平衡后secondTopic的partition2就变成理想状态了。
[oper@worker1 kafka_2.13-3.4.0]$ bin/kafka-topics.sh -bootstrap-server worker1:9092 --describe --topic secondTopic
Topic: secondTopic TopicId: W3mXDtj1RsWmsEhQrZjN5g PartitionCount: 4 ReplicationFactor: 3 Configs: Topic: secondTopic Partition: 0 Leader: 1 Replicas: 1,0,2 Isr: 1,0,2Topic: secondTopic Partition: 1 Leader: 0 Replicas: 0,2,1 Isr: 0,1,2Topic: secondTopic Partition: 2 Leader: 2 Replicas: 2,1,0 Isr: 1,0,2Topic: secondTopic Partition: 3 Leader: 1 Replicas: 1,2,0 Isr: 1,0,2
但是要注意,这样Leader Partition自平衡的过程是一个非常重的操作,因为要涉及到大量消息的转移与同步。并且,在这个过程中,会有丢消息的可能。所以在很多对性能要求比较高的线上环境,会选择将参数auto.leader.rebalance.enable设置为false,关闭Kafka的Leader Partition自平衡操作,而用其他运维的方式,在业务不繁忙的时间段,手动进行Leader Partiton自平衡,尽量减少自平衡过程对业务的影响。(为什么会丢消息?见1.5)(Kafka丢消息的第一条可能导火索)
*1.5 Partition故障恢复机制
Kafka设计时要面对的就是各种不稳定的网络以及服务环境。如果Broker的服务不稳定,随时崩溃,Kafka集群要怎么保证数据安全呢?
我们先来回顾一下Leader Patition和Follower之间的工作流程:
- 当一组Partition中选举出了一个Leader节点后,这个Leader节点就会优先写入并保存Producer传递过来的消息
- Leader节点保存以后,再同步给其他Follower(这个过程通常是异步的)
所以,大家思考一下,上述流程中,如果Leader Partition所在的Broker服务发生宕机时,Kafka就只能触发Leader Partition的重新选举了。但是,在选举过程中,原来Partition上的数据是如何处理的呢?
答案是,Kafka为了保证消息能够在多个Parititon中保持数据同步,内部记录了两个关键的数据:
LEO(Log End Offset)
: 每个Partition的最后一个Offset。这个参数比较好理解,每个Partition都会记录自己保存的消息偏移量。leader partition收到并记录了生产者发送的一条消息,就将LEO加1。而接下来,follower partition需要从leader partition同步消息,每同步到一个消息,自己的LEO就加1。通过LEO值,就知道各个follower partition与leader partition之间的消息差距HW(High Watermark)
: 【翻译:高水位】。一组Partiton中最小的LEO。Follower partition每次往leader partition同步消息时,都会同步自己的LEO给leader partition。这样leader partition就可以汇总到所有Follower Partition的HW值,然后通过比较得到整个集群最终的HW值,并同步给各个follower partition。leader partition认为这个HW值以前的消息,都是在所有follower partition之间完成了同步的,是安全的。这些安全的消息就可以被消费者拉取过去了。而HW值之后的消息,就是不安全的,是可能丢失的。这些消息如果被消费者拉取过去消费了,就有可能造成数据不一致(主从partition同步的核心)
说实在,就算我把上面的两个概念告诉大家了,但是很多人都会不理解,特别是一些对生产者端ack
机制有印象的朋友,对于这个丢数据情况理解会更加艰难。
首先,我希望大家在记忆理解HW-高水位
值的时候,心中能浮现出下面这个图片(木桶效应。我才HW之所以叫HW就是源于木桶效应):
我想这个图片已经非常形象了。一个木桶能装多少水,取决于那块最短的板。对于Kafka某个partition集群来说,他们的数据安全点取决于整个patition集群中HW
最小的那个Folloer patition
。
也就是说,在所有服务都正常的情况下,当一个消息写入到Leader Partition后,并不会立即让消费者感知。而是会等待其他Follower Partition同步。这个过程中就会推进HW。当HW超过当前消息时,才会让消费者感知。比如在上图中,4号往后的消息,虽然写入了Leader Partition,但是消费者是消费不到的。
上面说的这些跟ack机制没关系,是两码事
当服务出现故障时,如果是Follower发生故障,这不会影响消息写入,只不过是少了一个备份而已。处理相对简单一点。Kafka会做如下处理:
- 将故障的Follower节点临时踢出ISR集合。而其他Leader和Follower继续正常接收消息
- 出现故障的Follower节点恢复后,不会立即加入ISR集合。该Follower节点会读取本地记录的上一次的HW,将自己的日志中高于HW的部分信息全部删除掉,然后从HW开始,向Leader进行消息同步
- 等到该Follower的LEO大于等于整个Partiton的HW后,就重新加入到ISR集合中。这也就是说这个Follower的消息进度追上了Leader
如上图,broker1宕机重启后,LEO从5变为3。高水位HW后的数据都不要了
如果是Leader节点出现故障,Kafka为了保证消息的一致性,处理就会相对复杂一点。
- Leader发生故障,会从ISR中进行选举,将一个原本是Follower的Partition提升为新的Leader。这时,消息有可能没有完成同步,所以新的Leader的LEO可能会低于之前Leader的LEO
- Kafka中的消息都只能以Leader中的备份为准。其他Follower会将各自的Log文件中高于HW的部分全部清理掉,然后从新的Leader中同步数据(万恶之源,这就是为什么说kafka天生就可能丢消息)
- 旧的Leader恢复后,将作为Follower节点,进行数据恢复
不知道同学们意识到什么没有,按照我们一开始给出的partition群,以及他们的LEO情况,这时候leader宕机了,然后重新连接上来成为了follower,那很可能出现下面这种情况:
在这个过程当中,Kafka注重的是保护多个副本之间的数据一致性。但是这样,消息的安全性就得不到保障。
从这个角度来看,在服务极端不稳定的极端情况下,Kafka为了保证高性能,其实是牺牲了数据安全性的。Kafka并没有保证消息绝对安全。而RocketMQ在这一方面做了改善,优先保证数据安全。后续学习RocketMQ时,可以对比Kafka理解一下。
在这里你或许会有一个疑问,这个机制中有一个很重要的前提,就是各个Broker中记录的HW是一致的。但是HW和LEO同样是一个分布式的值,怎么保证HW在多个Broker中是一致的呢?
(PS:想要对HW机制有个更好的理解,建议点击右边传送门看看大佬的文章,《Kafka 3.0 源码笔记(12)-Kafka 服务端分区异常恢复机制的源码分析》)
1.6 HW一致性保障-Epoch更新机制
有了HW机制后,各个Partiton的数据都能够比较好的保持统一。但是,实际上,HW值在一组Partition里并不是总是一致的。
Leader Partition需要计算出HW值,就需要保留所有Follower Partition的LEO值。
但是,对于Follower Partition,他需要先将消息从Leader Partition拉取到本地,才能向Leader Partition上报LEO值。所有Follower Partition上报后,Leader Partition才能更新HW的值,然后Follower Partition在下次拉取消息时,才能更新HW值。所以,Leader Partiton的LEO更新和Follower Partition的LEO更新,在时间上是有延迟的。这也导致了Leader Partition上更新HW值的时刻与Follower Partition上跟新HW值的时刻,是会出现延迟的。这样,如果有多个Follower Partition,这些Partition保存的HW的值是不统一的。当然,如果服务一切正常,最终Leader Partition还是会正常推进HW,能够保证HW的最终一致性。但是,当Leader Partition出现切换,所有的Follower Partition都按照自己的HW进行数据恢复,就会出现HW数据不一致的情况。
因此,Kafka还设计了Epoch机制,来保证HW的一致性。
- Epoch是一个单调递增的版本号,每当Leader Partition发生变更时,该版本号就会更新。所以,当有多个Epoch时,只有最新的Epoch才是有效的,而其他Epoch对应的Leader Partition就是过期的,无用的Leader
- 每个Leader Partition在上任之初,都会新增一个新的Epoch记录。这个记录包含更新后端的epoch版本号,以及当前Leader Partition写入的第一个消息的偏移量。例如(1,100)。表示epoch版本号是1,当前Leader Partition写入的第一条消息是100. Broker会将这个epoch数据保存到内存中,并且会持久化到本地一个leader-epoch-checkpoint文件当中
- 这个leader-epoch-checkpoint会在所有Follower Partition中同步。当Leader Partition有变更时,新的Leader Partition就会读取这个Epoch记录,更新后添加自己的Epoch记录
- 接下来其他Follower Partition要更新数据时,就可以不再依靠自己记录的HW值判断拉取消息的起点。而可以根据这个最新的epoch条目来判断
这个关键的leader-epoch-checkpoint文件保存在Broker上每个partition对应的本地目录中。这是一个文本文件,可以直接查看。他的内容大概是这样样子的:
[oper@worker1 disTopic-0]$ cat leader-epoch-checkpoint
0
1
29 2485991681
其中第一行版本号;第二行表示下面的记录数。这两行数据没有太多的实际意义。从第三行开始,可以看到两个数字。这两个数字就是epoch 和 offset。epoch就是表示leader的epoch版本。从0开始,当leader变更一次epoch就会+1。offset则对应该epoch版本的leader写入第一条消息的offset。可以理解为用户可以消费到的最早的消息offset。
1.7 总结
Kafka其实天生就是为了集群而生,即使单个节点运行Kafka,他其实也是作为一个集群运行的。而Kafka为了保证在各种网络抽风,服务器不稳定等复杂情况下,保证集群的高性能,高可用,高可扩展三高,做了非常多的设计。而这一章节,其实是从可见的Zookeeper注册信息为入口,理解Kafka的核心集群机制。回头来看今天总结的这些集群机制,其实核心都是为了保持整个集群中Partition内的数据一致性。有了这一系列的数据一致性保证,Kafka集群才能在复杂运行环境下保持高性能、高可用、高可扩展三高特性。而这其实也是我们去理解互联网三高问题最好的经验
学习总结
- 学习了partition的leader选举机制
- 学习了leader partition的自平衡机制
- 学习了partition故障恢复机制,以及HW的深入理解
感谢
感谢大佬【作者:谈谈1974】的文章《Kafka 3.0 源码笔记(12)-Kafka 服务端分区异常恢复机制的源码分析》
相关文章:
【Kafka专题】Kafka集群架构设计原理详解
目录 前言前置知识课程内容一、Kafka的Zookeeper元数据梳理1.1 zookeeper整体数据1.2 Controller Broker选举机制1.3 Leader Partition选举机制1.4 Leader Partition自动平衡机制*1.5 Partition故障恢复机制1.6 HW一致性保障-Epoch更新机制1.7 总结 学习总结感谢 前言 Kafka的…...
Docker 镜像的缓存特性
Author:rab 目录 前言一、构建缓存二、Pull 缓存总结 前言 首先我们要清楚,Docker 的镜像结构是分层的,镜像本身是只读的(不管任何一层),当我们基于某镜像运行一个容器时,会有一个新的可写层被…...
Javascript 笔记:object
一部分object可以见:JavaScript 笔记 初识JavaScript(变量)_UQI-LIUWJ的博客-CSDN博客 1 in操作符 2 hasOwnProperty 3 获取一个object所拥有的所有property 不去原型链上找 4 定义data property...
【vue3】可编辑el-table
<template><el-table:data"tableData"style"width: 100%"><el-table-columnprop"date"label"日期"width"180"><template #default"{row,$index}"><input type"text" v-mode…...
一个开源的安卓相机:OpenCamera
原网址 Open Camera download | SourceForge.net 我也上传了一个 https://github.com/quantum6/Android-OpenCamera...
分类预测 | MATLAB实现POA-CNN鹈鹕算法优化卷积神经网络多特征分类预测
分类预测 | MATLAB实现POA-CNN鹈鹕算法优化卷积神经网络多特征分类预测 目录 分类预测 | MATLAB实现POA-CNN鹈鹕算法优化卷积神经网络多特征分类预测分类效果基本描述程序设计参考资料 分类效果 基本描述 1.Matlab实现POA-CNN鹈鹕算法优化卷积神经网络多特征分类预测࿰…...
学习网络编程No.7【应用层之序列化和反序列化】
引言: 北京时间:2023/9/14/19:13,下午刚刚更完文章,是一篇很久很久以前的文章,由于各种原因,留到了今天更新,非常惭愧呀!目前在上学校开的一门网络课程,学校的课听不了一…...
小谈设计模式(10)—原型模式
小谈设计模式(10)—原型模式 专栏介绍专栏地址专栏介绍 原型模式角色分类抽象原型(Prototype)具体原型(Concrete Prototype)客户端(Client)原型管理器(Prototype Manager…...
用《斗破苍穹》的视角打开C#3 标签与反射(人物创建与斗技使用)
随着剧情的发展,主线人物登场得越来越多,时不时跳出一个大佬,对我张牙舞爪地攻击。眼花缭乱的斗技让我不厌其烦,一个不小心,我就记不清楚在哪里遇上过什么人,他会什么斗技了。这时候,我就特别希…...
c语言进阶部分详解(详细解析字符串常用函数,并进行模拟实现(下))
上篇文章介绍了一些常用的字符串函数,大家可以跳转过去浏览一下:c语言进阶部分详解(详细解析字符串常用函数,并进行模拟实现(上))_总之就是非常唔姆的博客-CSDN博客 今天接着来介绍一些&#x…...
一文看懂光模块的工作原理
你们好,我的网工朋友 光模块有很多类别,是我们经常要用到的PHY层器件。虽然封装,速率,传输距离有所不同,但是其内部组成基本是一致的。 以太网交换机常用的光模块有SFP,GBIC,XFP,X…...
基于SpringBoot的桂林旅游景点导游平台
目录 前言 一、技术栈 二、系统功能介绍 用户信息管理 景点类型管理 景点信息管理 线路推荐管理 用户注册 线路推荐 论坛交流 三、核心代码 1、登录模块 2、文件上传模块 3、代码封装 前言 随着信息技术在管理上越来越深入而广泛的应用,管理信息系统的实…...
【小程序 - 加强】自定义组件、使用npm包、全局数据共享、分包_05
目录 一、自定义组件 1. 组件的创建与引用 1.1 创建组件 1.2 引用组件 1.2.1 局部引用组件 1.2.2 全局引用组件 1.2.3 全局引用 VS 局部引用 1.2.4 组件和页面的区别 2. 样式 2.1 组件样式隔离 2.2 组件样式隔离的注意点 2.3 修改组件的样式隔离选项 2.4 styleIso…...
Vue.js3学习篇--Vue模板应用
目录 一,模板基础 1.模板插值 (1)基础插值 (2)HTML代码插值 (3)标签属性插值 2.模板指令 (1)定义 (2)指令参数 二.条件渲染 1.使用v-if指令渲染 2.使…...
【软考】5.2 传输介质/通信方式/IP地址/子网划分
《传输介质》 双绞线:网线;传输距离在100m以内 无屏蔽双绞线:UTP;可靠性相对较低屏蔽双绞线:STP;屏蔽怕干扰;可靠性相对较高;一般用于对传输可靠性要求很高的场合 网线:…...
软件测试银行项目网上支付接口调用测试实例
公司最近有一个网站商城项目要开始开发了,这几天老板和几个同事一起开着需求会议, 讨论了接下来的业务规划和需求策略,等技术需求一下来还要讨论技术需求, 确认后再慢慢的进入开发阶段,趁着闲暇时间新造的人想总结一…...
w806 adc 中断扫描通道采集
用到了该芯片adc 扫描4个adc 通道,官方的死循环等待非常浪费时间,这里改用adc 中断采集方式,记录一下 int32_t adcFilterSum[4]{0}; int32_t detec_adc_value[4]{0};//mV int16_t detec_convt_ok[4]{0};/*is OK*/ ADC_HandleTypeDef hadc;vo…...
使用CSS的Positions布局打造响应式网页
在当今移动互联网的时代,响应式网页设计已经成为了一个必备的技能。通过使用CSS Positions布局,我们可以轻松地实现一个响应式的网页,使网页能够在不同的屏幕尺寸下自动适应。本文将介绍如何使用CSS Positions布局来打造一个响应式网页&#…...
模型训练环境相关(CUDA、PyTorch)
模型训练环境相关(CUDA、PyTorch) 1. 查看当前 GPU 所能支持的最高版本的 CUDA2. 如何判断是否安装了 CUDA3. 安装 PyTorch3.1 创建虚拟环境3.2 激活并进入虚拟环境3.3 安装 PyTorch 1. 查看当前 GPU 所能支持的最高版本的 CUDA 打开 NVIDIA 控制面板&a…...
链动2+1模式:社交电商行业的新型商业模式与营销手段
链动21模式是近年来在社交电商行业中崭露头角的一种新型商业模式和营销手段。在经历了多年的发展之后,社交电商行业已经进入了一个竞争激烈、用户获取成本高昂的阶段。在这个阶段,如何迅速吸引用户并增加他们的留存率和复购率成为了亟待解决的问题。 为了…...
竞赛选题 深度学习 opencv python 实现中国交通标志识别
文章目录 0 前言1 yolov5实现中国交通标志检测2.算法原理2.1 算法简介2.2网络架构2.3 关键代码 3 数据集处理3.1 VOC格式介绍3.2 将中国交通标志检测数据集CCTSDB数据转换成VOC数据格式3.3 手动标注数据集 4 模型训练5 实现效果5.1 视频效果 6 最后 0 前言 🔥 优质…...
LuatOS-SOC接口文档(air780E)-- fskv - kv数据库,掉电不丢数据
示例 -- 本库的目标是替代fdb库 -- 1. 兼容fdb的函数 -- 2. 使用fdb的flash空间,启用时也会替代fdb库 -- 3. 功能上与EEPROM是类似的 fskv.init() fskv.set("wendal", 1234) log.info("fskv", "wendal", fskv.get("wendal"))--[[ fs…...
一篇文章教你Pytest快速入门和基础讲解,一定要看!
前言 目前有两种纯测试的测试框架,pytest和unittestunittest应该是广为人知,而且也是老框架了,很多人都用来做自动化,无论是UI还是接口pytest是基于unittest开发的另一款更高级更好用的单元测试框架出去面试也好,跟别…...
SpringBoot项目:Cannot find declaration to go to
SpringBoot项目get,set方法总报Cannot find declaration to go to 搜了很多答案,没解决 后来仔细一想,原来是我的idea软件重装了,lombok插件没重新安装导致。 安装步骤: 1、下载地址:https://plugins.jetbrains.com…...
【高并发】多线程和高并发提纲
文章目录 三大源头两个主要问题三大解决方案 最近正在面试,对多线程和高并发相关问题整理了一个简单的提纲。 个人感觉这三大部分由底向上,足够引出对并发编程中大部分问题的讨论~ 三大源头 线程切换带来的原子性问题。 原子操作:利用CPU提…...
vue.js处理数组对象中某个字段是否变为两个字段
一、场景: 产品要求做一个时间步骤条,使用目前后端已返回的数据进行操作实现。时间步骤条要求日期和时间分开显示且相同日期只显示第一个日期。 图左边为实现效果,右边为后台返回的接口。接口中current字段表示当前到达第几步,从…...
从零开始的C++(补充三的内容)
auto:在编译阶段根据数据的类型确认auto所代表的类型,并将auto换成对应的类型。 特点: 1、auto所能代表的类型必须是在编译阶段就能确认的。 2、auto修饰的变量必须初始化,否则编译器无法判断auto的实际类型。 3、auto会根据第一个数据来…...
微信小程序通过createSelectorQuery获取元素 高度,宽度与界面距离
小程序官方有提供给我们一个 const query wx.createSelectorQuery() 函数 我们可以先编写这样一段代码 wxml <view><button bindtap"getDom">点击查看</button><view class "textIn" style "height: 100px;width: 30px;&quo…...
MySQL-事务
MySQL-事务 1.什么是事务 举例:想象炒菜的过程。 洗菜切菜炒菜装盘 我相信缺少任何任何一个步骤,都不完美!!!可以将炒菜的过程理解为一个事务,是一组操作的集合,而MySQL中的事务也是如此。但…...
自动定时删除磁盘文件的脚本(从文件日期最早的开始删)
#!/bin/bash# 指定的挂载点 MOUNTPOINT"/media/vm/MyDisk512GB"# 设置磁盘大小的限制 (例如:800G) LIMIT$((800 * 1024 * 1024)) # 单位是KB# 获取挂载点的已使用空间 USED_SPACE$(df -kP "$MOUNTPOINT" | tail -1 | awk {print $3})echo &quo…...
拆解CPU的基本结构和运行原理
CPU的基本结构 CPU是一个计算系统的核心 南北桥芯片将CPU与外设连接起来 CPU执行流程 CPU的电路基础 组合电路基本原理 时序电路基本原理 多核成为主流 汇编语言和寄存器 中断的基本原理 中断的产生 中断服务程序 CPU 做为计算机的总司令官,它管理着计算…...
Docker安装——Ubuntu (Jammy 22.04)
一、为什么要用 Ubuntu?(centos和ubuntu有什么区别) 使用lsb_release命令:lsb_release -a ,即可查看ubantu的版本,但是为什么要使用ubantu 呢? 区别:1、centos基于EHEL开发,而ubunt…...
Fast DDS之Transport
目录 transport层负责为DDS用户数据收发和服务发现提供通信。包含UDP,TCP,SHM。...
爱普生L125X_L325X系列打印机Wi-Fi配置方法(Smart Panel)
准备工作: 手机需要下载“Epson Smart Panel”APP; 配置无线(Wi-Fi)方法 说明:SSID名称(Wi-Fi名)不能包含中文字符,路由器需要选择2.4GHz频段; 1. 打开“Epson Smart Panel”软件࿰…...
【回顾一下Docker的基本用法】
文章目录 回顾一下Docker的基本用法1.初识Docker1.1.什么是Docker1.1.1.应用部署的环境问题1.1.2.Docker解决依赖兼容问题1.1.3.Docker解决操作系统环境差异1.1.4.小结 1.2.Docker和虚拟机的区别1.3.Docker架构1.3.1.镜像和容器1.3.2.DockerHub1.3.3.Docker架构1.3.4.小结 1.4.…...
【Python】Python基础知识
【Python】Python基础知识 关键字 查看Python关键字: >python >>>import keyword >>>keyword.kwlist 注释 注释有两方面作用: (1)提高程序的可读性(最重要的作用);…...
【计算机视觉 05】YOLO论文讲解:V1-V7
https://ai.deepshare.net/live_pc/l_63243a65e4b050af23b79338 Part1.目标检测与YOLO系列 1. 目标检测任务及发展脉络 2. YOLO的发展史 Anchors Base原理: Part2.YOLOV1-V3 3. YOLO V1的网络结构 4. YOLO V3的网络结构与实验结果 Part3.YOLO的进化 5. YOLO V4的网络…...
git全局与单仓库的密码管理
概要 在使用git时,有默认的全局配置,每个仓库也有自己的配置,在使用时常常傻傻分不清楚,现在进行一个简单的整理记录。 一般情况下全局配置中的git账号和邮箱通常设置成自己的,其他仓库再根据项目需要进行单独配置&a…...
IDEA的使用(一) (IntelliJ IDEA 2022.1.3版本)
目录 1. IDEA项目结构 2. 模块的导入操作 2.1 正规操作 2.2 取巧操作 2.3 出现乱码 2.4 模块改名 3. 代码模板的使用 后缀补全(Postfix Completion)、实时模板(Live Templates)菜单里面什么介绍都有,可以自学&a…...
javaee SpringMVC文件上传 项目结构
引入依赖 <?xml version"1.0" encoding"UTF-8"?><project xmlns"http://maven.apache.org/POM/4.0.0" xmlns:xsi"http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation"http://maven.apache.org/POM/4.0.0…...
JavaScript DOM 函数大全详解(使用最新的 JS 语法)
JavaScript DOM 函数大全详解(使用最新的 JS 语法) JavaScript 的 Document Object Model(DOM)是用于操作网页内容的编程接口。在最新的 JavaScript 语法下,我们有很多方便和高效的方法来处理 DOM。下面是一些常用 DO…...
Stm32_标准库_8_ADC_光敏传感器_测量具体光照强度
ADC简介 测量方式 采用二分法比较数据 IO通道 ADC基本结构及配置路线 获取数字变量需要用到用到光敏电阻的AO口,AO端口接在PA0引脚即可 测得的模拟数据与实际光照强度之间的关系为 光照强度 100 - 模拟量 / 40;代码: 完整朴素代码: #in…...
基于SSM的固定资产管理系统的设计与实现
末尾获取源码 开发语言:Java Java开发工具:JDK1.8 后端框架:SSM 前端:采用JSP技术开发 数据库:MySQL5.7和Navicat管理工具结合 服务器:Tomcat8.5 开发软件:IDEA / Eclipse 是否Maven项目&#x…...
Leetcode---364场周赛
题目列表 2864. 最大二进制奇数 2865. 美丽塔 I 2866. 美丽塔 II 2867. 统计树中的合法路径数目 一、最大二进制奇数 这题只要你对二进制有了解(学编程的不会不了解二进制吧),应该问题不大,这题要求最大奇数,1.奇数:只要保证…...
使用 Powershell 检索不理解的命令
使用 Powershell 检索不理解的命令 尝试使用 Powershell 完成 Powershell 的命令行 使用 Powershell 时,有时您会忘记某个 cmdlet 或想要了解哪些 cmdlet 可用。在这种情况下,最好在互联网上查找,但您也可以使用 Powershell 函数来完成。 以…...
基于 FPGA 的机器博弈五子棋游戏
基于 FPGA 的机器博弈五子棋游戏 一,设计目的 五子棋是一种深受大众喜爱的游戏,其规则简单,变化多端,非常富有趣味性 和消遣性。棋类游戏在具备娱乐性、益智性的同时也因为其载体大多是手机, 电脑等移动互联网设备导致现代社会低头族等现象更加严重,危害青少年的身 体健康…...
uCOSIII实时操作系统 三 移植
目录 uCOSIII简介: 准备工作: 准备基础工程: UCOSIII工程源码: UCOSIII移植: 向基础工程中添加相应的文件夹 向工程中添加分组 常见问题: 下载验证: uCOSIII简介: UCOS-I…...
机器学习之SGD, Batch, and Mini Batch的简单介绍
文章目录 总述SGD(Stochastic Gradient Descent)(随机梯度下降)Batch (批量)mini Batch (迷你批量) 总述 SGD, Batch, and Mini Batch是可用于神经网络的监督学习计算权重更新的方案,即∆wij。 SGD(Stochastic Gradi…...
Windows电脑上的多开器与分布式存储系统的关系
Windows电脑上的多开器和分布式存储系统是两个不同的概念,二者之间没有直接的关系。 多开器是一种软件,它可以在Windows电脑上让用户同时运行多个同一应用程序的实例。多开器通常用于游戏玩家和应用程序测试人员等需要同时运行多个实例的用户。 分布式…...
积分球可以用于什么光谱光学检测
积分球是光测量的主要工具之一。积分球可以同时捕获一个光源发出的所有辐射。 1.光源测量 积分球可以用于测量光源的光通量、色温、光效等参数。通过将光源放置在积分球的入口处,球内的光线经过多次反射后形成均匀的照度分布,然后使用光度计或光谱仪对光…...