kafka集群工作机制

一、kafka在zookeeper上的元数据解释

kafka中的broker要选举Controller角色来管理整个kafka集群中的分区和副本状态。一个Topic下多个partition要选举Leader角色和客户端进行交互数据

Zookeeper客户端工具： prettyZoo。 下载地址：https://github.com/vran-dev/PrettyZoo/releases

对于kafka还有个问题，就是kafka集群的每个broker都会注册在zookeeper的临时节点/broker/ids/{BrokerId} ，如果集群节点服务器是非正常关机，zookeeper上面对应broker的节点不会删除，再次启动broker往zookeeper会报错

二、Controller Broker选举机制

通过在zookeeper上创建一个/controller的临时节点，写入当前启动的broker信息，其它的服务器无法写入了，写入成功的作为Controller，写入的内容如下：

{"version":1,"brokerid":0,"timestamp":"1661492503848"}

Controller会与zookeeper保持一个长连接，如果属于Controller角色的broker宕机，zookeeper长时间检测不到心跳就会删除/controller节点，其它broker就会监听到并重新竞争/controller

​ 选举产生的Controller节点，就会负责监听Zookeeper中的其他一些关键节点，触发集群的相关管理工作。例如：

  • 监听Zookeeper中的/brokers/ids节点，感知Broker增减变化。
  • 监听/brokers/topics，感知topic以及对应的partition的增减变化。
  • 监听/admin/delete_topic节点，处理删除topic的动作。

​ 另外，Controller还需要负责将元数据推送给其他Broker。

三、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是有问题的，Leader Partition用于接收客户端请求，这样分配显然是分配不均，导致Broker1过于繁忙

四、Leader Partition自动平衡机制

Kafka会尽量将Leader Partition分配到不同的Broker节点上

Kafka在进行Leader Partition自平衡时的逻辑是这样的：他会认为AR当中的第一个节点就应该是Leader节点。这种选举结果成为preferred election 理想选举结果。Controller会定期检测集群的Partition平衡情况，在开始检测时，Controller会依次检查所有的Broker。当发现这个Broker上的不平衡的Partition比例高于leader.imbalance.per.broker.percentage阈值时，就会触发一次Leader Partiton的自平衡。

这是官方文档的部分截图。

image.png

这个机制涉及到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自平衡，尽量减少自平衡过程对业务的影响。

五、Partition故障恢复机制

当Leader Partition对应broker宕机了如何选举新的Leader Partition接收客户端请求

先理解如下两个参数

  • 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就可以计算出这个HW值，并最终会同步给各个follower partition。leader partition认为这个HW值以前的消息，都是在所有follower partition之间完成了同步的，是安全的。这些安全的消息就可以被消费者拉取过去了。而HW值之后的消息，就是不安全的，是可能丢失的。这些消息如果被消费者拉取过去消费了，就有可能造成数据不一致。

image.png

​ 也就是说，在所有服务都正常的情况下，当一个消息写入到Leader Partition后，并不会立即让消费者感知。而是会等待其他Follower Partition同步。这个过程中就会推进HW。当HW超过当前消息时，才会让消费者感知。比如在上图中，4号往后的消息，虽然写入了Leader Partition，但是消费者是消费不到的。

这跟生产者的acks应答参数是不一样的

​ 当服务出现故障时，如果是Follower发生故障，这不会影响消息写入，只不过是少了一个备份而已。处理相对简单一点。Kafka会做如下处理：

  1. 将故障的Follower节点临时提出ISR集合。而其他Leader和Follower继续正常接收消息。
  2. 出现故障的Follower节点恢复后，不会立即加入ISR集合。该Follower节点会读取本地记录的上一次的HW，将自己的日志中高于HW的部分信息全部删除掉，然后从HW开始，向Leader进行消息同步。
  3. 等到该Follower的LEO大于等于整个Partiton的HW后，就重新加入到ISR集合中。这也就是说这个Follower的消息进度追上了Leader。

image.png

​ 如果是Leader节点出现故障，Kafka为了保证消息的一致性，处理就会相对复杂一点。

  1. Leader发生故障，会从ISR中进行选举，将一个原本是Follower的Partition提升为新的Leader。这时，消息有可能没有完成同步，所以新的Leader的LEO会低于之前Leader的LEO。
  2. Kafka中的消息都只能以Leader中的备份为准。其他Follower会将各自的Log文件中高于HW的部分全部清理掉，然后从新的Leader中同步数据。
  3. 旧的Leader恢复后，将作为Follower节点，进行数据恢复。

image.png

​ 在这个过程当中，Kafka注重的是保护多个副本之间的数据一致性。但是这样，消息的安全性就得不到保障。例如在上述示例中，原本Partition0中的4，5，6，7号消息就被丢失掉了。

六、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进行数据恢复，就会出现数据不一致的情况。

image.png

​ 因此，Kafka还设计了Epoch机制，来保证HW的一致性。

  1. Epoch是一个单调递增的版本号，每当Leader Partition发生变更时，该版本号就会更新。所以，当有多个Epoch时，只有最新的Epoch才是有效的，而其他Epoch对应的Leader Partition就是过期的，无用的Leader。
  2. 每个Leader Partition在上任之初，都会新增一个新的Epoch记录。这个记录包含更新后端的epoch版本号，以及当前Leader Partition写入的第一个消息的偏移量。例如(1,100)。表示epoch版本号是1，当前Leader Partition写入的第一条消息是100. Broker会将这个epoch数据保存到内存中，并且会持久化到本地一个leader-epoch-checkpoint文件当中。
  3. 这个leader-epoch-checkpoint会在所有Follower Partition中同步。当Leader Partition有变更时，新的Leader Partition就会读取这个Epoch记录，更新后添加自己的Epoch记录。
  4. 接下来其他Follower Partition要更新数据时，就可以不再依靠自己记录的HW值判断拉取消息的起点。而可以根据这个最新的epoch条目来判断。

image.png

​ 这个关键的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。

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

如若内容造成侵权/违法违规/事实不符，请联系一条长河网进行投诉反馈，一经查实，立即删除！

相关文章

2023年R1快开门式压力容器操作证模拟考试题库及R1快开门式压力容器操作理论考试试题

2023年R1快开门式压力容器操作证模拟考试题库及R1快开门式压力容器操作理论考试试题

题库来源：安全生产模拟考试一点通公众号小程序 2023年R1快开门式压力容器操作证模拟考试题库及R1快开门式压力容器操作理论考试试题是由安全生产模拟考试一点通提供，R1快开门式压力容器操作证模拟考试题库是根据R1快开门式压力容器操作最新版教材&#…
阅读更多...
润滑油泵控制(博途SCL源代码)

润滑油泵控制(博途SCL源代码)

有关博途PLC定时器的各种使用方法请参考下面文章链接： 博途PLC IEC定时器编程应用（SCL语言）_博图 定时器-CSDN博客博途PLC定时器支持数据类型TIME 类型 ，写法支持T#2M10S 、T#10S等，时基是MS所以如果设置1M用 DINT数据类型就是60000，大部分HMI上数据类型很多不支持IEC的…
阅读更多...
buuctf-[GXYCTF2019]禁止套娃 git泄露，无参数rce

buuctf-[GXYCTF2019]禁止套娃 git泄露，无参数rce

用dirsearch扫一下&#xff0c;看到flag.php 访问一下没啥东西&#xff0c;使用githack python2 GitHack.py http://8996e81f-a75c-4180-b0ad-226d97ba61b2.node4.buuoj.cn/.git/查看index.php <?php include "flag.php"; echo "flag在哪里呢&#xff1f;…
阅读更多...
【iptables 实战】9 docker网络原理分析

【iptables 实战】9 docker网络原理分析

在开始本章阅读之前&#xff0c;需要提前了解以下的知识 阅读本节需要一些docker的基础知识&#xff0c;最好是在linux上安装好docker环境。提前掌握iptables的基础知识&#xff0c;前文参考【iptables 实战】 一、docker网络模型 docker网络模型如下图所示 说明&#xff1…
阅读更多...
【算法|动态规划No.9】leetcodeLCR 091. 粉刷房子

【算法|动态规划No.9】leetcodeLCR 091. 粉刷房子

个人主页&#xff1a;兜里有颗棉花糖 欢迎 点赞&#x1f44d; 收藏✨ 留言✉ 加关注&#x1f493;本文由 兜里有颗棉花糖 原创 收录于专栏【手撕算法系列专栏】【LeetCode】 &#x1f354;本专栏旨在提高自己算法能力的同时&#xff0c;记录一下自己的学习过程&#xff0c;希望…
阅读更多...
Bee2.1.8支持Spring Boot 3.0.11,active命令行选择多环境,多表查改增删(bee-spring-boot发布,更新maven)

Bee2.1.8支持Spring Boot 3.0.11,active命令行选择多环境,多表查改增删(bee-spring-boot发布,更新maven)

天下大势&#xff0c;分久必合&#xff01; Hibernate/MyBatis plus Sharding JDBC Jpa Spring data GraphQL App ORM (Android, 鸿蒙) Bee Spring Cloud 微服务使用数据库更方便&#xff1a;Bee Spring Boot; 轻松支持多数据源&#xff0c;Sharding, Mongodb. 要整合一堆的…
阅读更多...
牛客网国庆赛day3

牛客网国庆赛day3

B&#xff1a; 给定一个由小写字母组成的字符串S。你要逐个执行Q个操作。每个操作可以是以下两种类型之一&#xff1a; 修改&#xff1a;给定一个整数x。根据x的值修改字符串S。如果x是正数&#xff0c;则将S中最左边的x个字母移到S的右侧&#xff1b;如果x是负数&#xff0c;…
阅读更多...
最短路径专题6 最短路径-多路径

最短路径专题6 最短路径-多路径

题目&#xff1a; 样例&#xff1a; 输入 4 5 0 2 0 1 2 0 2 5 0 3 1 1 2 1 3 2 2 输出 2 0->1->2 0->3->2 思路&#xff1a; 根据题意&#xff0c;最短路模板还是少不了的&#xff0c; 我们要添加的是&#xff0c; 记录各个结点有多少个上一个结点走动得来的…
阅读更多...
JS-Dom转为图片，并放入pdf中进行下载

JS-Dom转为图片，并放入pdf中进行下载

1、将dom转换为图片 这里我们使用html2canvas工具插件先将dom转为canvas元素然后canvas拥有一个方法可以将绘制出来的图形转为url然后下载即可注意&#xff1a;如果元素使用了渐变背景并透明的话&#xff0c;生成的图片可能会有点问题。我下面这个案例使用了渐变背景实现元素对…
阅读更多...
【进程管理】初识进程

【进程管理】初识进程

一.何为进程 教材一般会给出这样的答案: 运行起来的程序 或者 内存中的程序 这样说太抽象了&#xff0c;那我问程序和进程有什么区别呢&#xff1f;诶&#xff1f;这我知道&#xff0c;书上说&#xff0c;动态的叫进程&#xff0c;静态的叫程序。那么静态和动态又是什么意思…
阅读更多...
typescript: Builder Pattern

typescript: Builder Pattern

/*** file: CarBuilderts.ts* TypeScript 实体类 Model* Builder Pattern* 生成器是一种创建型设计模式&#xff0c; 使你能够分步骤创建复杂对象。* https://stackoverflow.com/questions/12827266/get-and-set-in-typescript* https://github.com/Microsoft/TypeScript/wiki/…
阅读更多...
想要精通算法和SQL的成长之路 - 验证二叉树

想要精通算法和SQL的成长之路 - 验证二叉树

想要精通算法和SQL的成长之路 - 验证二叉树 前言一. 验证二叉树1.1 并查集1.2 入度以及边数检查 前言 想要精通算法和SQL的成长之路 - 系列导航 并查集的运用 一. 验证二叉树 原题链接 思路如下&#xff1a; 对于一颗二叉树&#xff0c;我们需要做哪些校验&#xff1f; 首先…
阅读更多...
（二）正点原子STM32MP135移植——TF-A移植

（二）正点原子STM32MP135移植——TF-A移植

目录 一、TF-A概述 二、编译官方代码 2.1 解压源码 2.2 打补丁 2.3 编译准备 &#xff08;1&#xff09;修改Makfile.sdk &#xff08;2&#xff09;设置环境变量 &#xff08;3&#xff09;编译 三、移植 3.1 复制官方文件 3.2 修改电源 3.3 修改TF卡和emmc 3.4 添…
阅读更多...
学习记忆——方法篇——联想法+记忆宫殿+数字编码

学习记忆——方法篇——联想法+记忆宫殿+数字编码

左右脑在记忆当中的不同特点&#xff1a; 左脑是我们的理性脑。主要功能是处理逻辑内容、以及数字、文字等信息&#xff0c;擅长对知识的分析、理解、归纳、整合。缺点是处理信息速度慢、效率低&#xff0c;死记硬背就是用左脑记忆。 右脑是我们的感性脑。主要功能是处理节奏、…
阅读更多...
2.2.2搭建交叉编译器

2.2.2搭建交叉编译器

1 交叉编译器 交叉编译的存在，有2个原因，1个是不同的平台，架构不同，使用的指令集不同，ARM和MIPS的CPU无法运行X86指令休编码的程序，1个是一般arm平台上的存储/性能有限，无法提供一个可靠的编译环境。所以就出现了在x86上编译，在arm上运行的镜像，即交叉编译。在交叉编…
阅读更多...
Linux多线程网络通信

Linux多线程网络通信

思路&#xff1a;主线程&#xff08;只有一个&#xff09;建立连接&#xff0c;就创建子线程。子线程开始通信。 共享资源&#xff1a;全局数据区&#xff0c;堆区&#xff0c;内核区描述符。 线程同步不同步需要取决于线程对共享资源区的数据的操作&#xff0c;如果是只读就不…
阅读更多...
网络是什么？(网络零基础入门篇)

网络是什么？(网络零基础入门篇)

1.如何理解局域网和广域网&#xff1f; 2.路由器和交换机是怎么样工作的&#xff1f; 3.三层交换机能不能代替路由器&#xff1f; -- 局域网 广域网 -- 企业网架构&#xff0c;运营商架构&#xff0c;数据中心架构 -- 局域网 通过 交换机连接的 转发 相同的ip地址…
阅读更多...
stable diffusion学习笔记【2023-10-2】

stable diffusion学习笔记【2023-10-2】

L1&#xff1a;界面 CFG Scale&#xff1a;提示词相关性 denoising&#xff1a;重绘幅度 L2&#xff1a;文生图 女性常用的负面词 nsfw,NSFW,(NSFW:2),legs apart, paintings, sketches, (worst quality:2), (low quality:2), (normal quality:2), lowres, normal quality, (…
阅读更多...
ubuntu下源码编译方式安装opencv

ubuntu下源码编译方式安装opencv

基础条件 ubuntu 20.04 opencv 3.4.3 opencv 源码编译的安装步骤 第一步&#xff0c; 首先clone源码 git clone https://github.com/opencv/opencv.git第二步&#xff0c;依赖包&#xff0c;执行下面的命令 sudo apt-get install build-essential sudo apt-get install cmak…
阅读更多...
使用华为eNSP组网试验⑸-访问控制

使用华为eNSP组网试验⑸-访问控制

今天练习使用华为sNSP模拟网络设备上的访问控制&#xff0c;这样的操作我经常在华为的S7706、S5720、S5735或者H3C的S5500、S5130、S7706上进行&#xff0c;在网络设备上根据情况应用访问控制的策略是一个网管必须熟练的操作&#xff0c;只是在真机上操作一般比较谨慎&#xff…
阅读更多...
最新文章

Copyright @ 2022~2023