Kafka系列 - kafka 副本|AR|ISR|OSR|Leader|Follower|HW|LEO

news2024/9/28 9:19:50

文章目录

      • 01. kafka 副本信息
      • 02. kafka 中 ISR、AR和OSR代表什么?
      • 03. kafka 中 ISR的伸缩指什么?
      • 04. 什么情况下一个broker会从ISR中踢出去?
      • 05. kafka 副本和ISR扮演什么角色?
      • 06. kafka 副本长时间不在ISR中,意味着什么?
      • 07. kafka follower副本如何和 leader副本同步?
      • 08. kafka 如何实现主从同步?
      • 09. kafka有哪些地方需要选举,这些地方的选举策略有哪些?
      • 10. kafka Partition Leader选举
      • 11. kafka Partition Leader选举流程
      • 12. kafka HW和LEO代表什么?
      • 13. 如何理解ISR集合与HW和LEO的关系?

01. kafka 副本信息

Kafka 为分区引入了多副本(Replica)机制,通过增加副本数量可以提升容灾能力。同一分区的不同副本中保存的是相同的消息,每个分区都有一个 leader 副本和多个 follower 副本,其中leader副本负责处理读写请求,follower副本只负责与leader副本的消息同步。副本处于不同的broker中,当leader副本出现故障时,Kafka 会自动从 follower 副本中选举一个新的 leader 副本对外提供服务。这个过程称为副本重分配。在副本重分配期间,Kafka 仍然可以正常工作,但可能会出现一些延迟。Kafka通过多副本机制实现了故障的自动转移,当Kafka集群中某个broker失效时仍然能保证服务可用。

如图,Kafka集群中有4个broker,某个主题中有3个分区,且副本因子(即副本个数)也为3,如此每个分区便有1个leader副本和2个follower副本。生产者和消费者只与leader副本进行交互,而follower副本只负责消息的同步,很多时候follower副本中的消息相对leader副本而言会有一定的滞后。

在这里插入图片描述

Kafka 的副本机制可以提供以下好处:

① 数据可靠性:即使某个副本失效,数据仍然可以从其他副本中恢复。

② 高可用性:即使某个副本失效,Kafka 仍然可以正常工作。

③ 提高读取性能:由于可以从任意一个副本中读取消息,因此可以提高读取性能。

Kafka 消费端也具备一定的容灾能力。Consumer 使用拉(Pull)模式从服务端拉取消息,并且保存消费的具体位置,当消费者宕机后恢复上线时可以根据之前保存的消费位置重新拉取需要的消息进行消费,这样就不会造成消息丢失。

02. kafka 中 ISR、AR和OSR代表什么?

Kafka是一种分布式流处理平台,其中ISR、AR和OSR是Kafka中的三个重要概念。

① ISR(In-Sync Replicas):指的是与Leader副本保持同步的副本集合。当Producer发送消息到Kafka集群时,只有ISR中的副本才会被写入消息,确保数据的可靠性和一致性。如果ISR中的某个副本无法与Leader保持同步,则该副本将被从ISR中移除,直到与Leader重新同步。

② OSR(Out-of-Sync Replicas):指的是与Leader副本失去同步的副本集合。当ISR中的某个副本无法与Leader保持同步时,该副本将被移动到OSR中,直到与Leader重新同步。

③ AR(Assigned Replicas):指的是被分配到某个Partition的副本集合。AR包括ISR和OSR。

总之,ISR是Kafka中保证数据可靠性和一致性的重要机制,而AR和OSR则是与Partition相关的副本集合。

分区中的所有副本统称为AR 。所有与leader副本保持一定程度同步的副本(包括leader副本在内)组成ISR,ISR集合是AR集合中的一个子集。消息会先发送到leader副本,然后follower副本才能从leader副本中拉取消息进行同步,同步期间内follower副本相对于leader副本而言会有一定程度的滞后。前面所说的“一定程度的同步”是指可忍受的滞后范围,这个范围可以通过参数进行配置。与leader副本同步滞后过多的副本(不包括leader副本)组成OSR,由此可见,AR=ISR+OSR。在正常情况下,所有的 follower 副本都应该与 leader 副本保持一定程度的同步,即AR=ISR,OSR集合为空。

leader副本负责维护和跟踪ISR集合中所有follower副本的滞后状态,当follower副本落后太多或失效时,leader副本会把它从ISR集合中剔除。如果OSR集合中有follower副本“追上”了leader副本,那么leader副本会把它从OSR集合转移至ISR集合。默认情况下,当leader副本发生故障时,只有在ISR集合中的副本才有资格被选举为新的leader,而在OSR集合中的副本则没有任何机会。

03. kafka 中 ISR的伸缩指什么?

ISR中的伸缩指的是ISR中副本的动态变化。当某个副本落后于leader副本时,它将被从ISR中移除,直到它再次与leader副本保持同步。当某个副本追上了leader副本,它将被重新加入ISR中。这种动态变化可以通过Kafka的副本管理机制自动完成,从而保证ISR中的副本集合始终与leader副本保持同步。

04. 什么情况下一个broker会从ISR中踢出去?

ISR(In-Sync Replicas)是Kafka中用于保证数据可靠性和高可用性的机制。ISR中的副本与Leader副本保持同步,可以保证在Leader副本宕机时,ISR中的副本可以顶替成为新的Leader副本,从而保证数据的可靠性和高可用性。

一般情况下,一个broker会从ISR中踢出去有以下几种情况:

① 副本同步延迟:如果ISR中的副本与Leader副本之间的同步延迟超过了一定的阈值,那么该副本就会被从ISR中踢出去。

② 副本故障:如果ISR中的副本发生故障,比如网络故障、硬件故障等,那么该副本也会被从ISR中踢出去。

③ 副本过期:如果ISR中的副本长时间没有与Leader副本保持同步,那么该副本也会被从ISR中踢出去。

需要注意的是,当一个broker被从ISR中踢出去时,需要及时进行故障排查和修复,以保证数据的可靠性和高可用性。

05. kafka 副本和ISR扮演什么角色?

副本(Replicas)和ISR(In-Sync Replicas)是Apache Kafka中非常重要的概念,它们扮演着以下角色:

① 副本:Kafka中的每个分区都有多个副本,每个副本都是分区数据的完整拷贝。副本的作用是提高数据的可靠性和可用性。当某个副本所在的broker宕机时,其他副本可以继续提供服务,确保数据不会丢失。

② ISR:ISR是指与leader副本保持同步的副本集合。当leader副本发生故障时,ISR中的某个副本会被选举为新的leader副本。只有在ISR中的副本才能被选举为新的leader副本,因为它们保证了数据的一致性。如果某个副本与leader副本失去同步,它将被从ISR中移除,直到与leader副本重新保持同步。

因此,副本和ISR是Kafka实现高可用性和数据一致性的重要手段。

06. kafka 副本长时间不在ISR中,意味着什么?

在Kafka中,ISR(in-sync replicas)是指与leader副本保持同步的副本集合。如果一个副本长时间不在ISR中,意味着该副本与leader副本的数据同步出现了问题,可能是由于网络故障、硬件故障或其他原因导致的。这种情况下,该副本可能会落后于其他副本,导致数据不一致。因此,Kafka会将该副本从ISR中移除,以避免数据不一致的情况发生。当该副本恢复正常后,Kafka会将其重新加入ISR中,以确保数据同步。

07. kafka follower副本如何和 leader副本同步?

Kafka中的follower副本通过与leader副本进行数据同步来保持与leader副本的一致性。follower节点与leader节点同步的过程如下:

① follower节点向leader节点发送拉取请求,请求获取最新的数据。

② leader节点接收到拉取请求后,将最新的数据发送给follower节点。

③ follower节点接收到数据后,将其写入本地日志文件,并向leader节点发送确认消息,表示已经成功接收到数据。

④ leader节点接收到确认消息后,将该消息标记为已经被follower节点接收到。

⑤ follower节点定期向leader节点发送心跳消息,以保持与leader节点的连接。

⑥ 如果follower节点在一定时间内没有向leader节点发送心跳消息,或者leader节点在一定时间内没有收到follower节点的确认消息,那么leader节点将认为该follower节点已经失效,将其从副本集合中移除。

08. kafka 如何实现主从同步?

Kafka通过副本机制来实现主从同步。每个分区都有多个副本,其中一个副本被指定为领导者(leader),其他副本被指定为追随者(follower)。领导者负责处理所有的读写请求,而追随者只是简单地复制领导者的数据。

当生产者向Kafka发送消息时,它会将消息发送到领导者副本。领导者副本将消息写入本地日志,并将消息复制到所有追随者副本。一旦所有追随者副本都确认已成功复制消息,领导者副本将向生产者发送确认消息。

当消费者从Kafka读取消息时,它会从领导者副本读取数据。如果领导者副本不可用,消费者可以从追随者副本读取数据。Kafka使用ZooKeeper来管理领导者和追随者副本之间的切换,以确保高可用性和数据一致性。

09. kafka有哪些地方需要选举,这些地方的选举策略有哪些?

① Controller选举

Controller是Kafka集群中的一个节点,负责管理集群的元数据信息,包括Broker的上下线、Partition的分配等。当当前的Controller节点失效时,需要选举一个新的Controller节点来接管其职责。

Controller选举的策略是通过Zookeeper实现的,每个Kafka Broker都会在Zookeeper上创建一个临时节点,节点的路径为/brokers/ids/[broker-id],其中broker-id为Broker的唯一标识。当一个Broker想要成为Controller时,它会在Zookeeper上创建一个临时节点/brokers/controller_epoch,节点的值为当前的epoch值,然后尝试获取/brokers/controller节点的锁。如果获取锁成功,则该Broker成为新的Controller节点;否则,它会监听/brokers/controller节点的变化,等待锁的释放。

② Partition Leader选举

每个Partition在Kafka集群中都有一个Leader节点,负责处理该Partition的读写请求。当当前的Leader节点失效时,需要选举一个新的Leader节点来接管其职责。

Partition Leader选举的策略是通过副本之间的协作实现的。每个Partition都有多个副本,其中一个副本为Leader,其他副本为Follower。当Leader节点失效时,Follower节点会发起一次选举,选举出一个新的Leader节点。

具体的选举过程如下:

  • Follower节点向所有其他副本发送一个Leader选举请求,请求中包含该Partition的最后一条消息的offset值。
  • 如果其他副本中有一个副本的最后一条消息的offset值大于等于该Follower节点的offset值,则该副本成为新的Leader节点。
  • 如果没有副本的offset值大于等于该Follower节点的offset值,则该Follower节点等待一段时间后重新发起选举请求。

需要注意的是,为了避免脑裂(split-brain)的情况发生,Kafka要求每个Partition至少有一个副本处于活跃状态,否则该Partition将无法使用。因此,在进行Leader选举时,只有那些处于活跃状态的副本才能参与选举。

10. kafka Partition Leader选举

Kafka是一个分布式的消息系统,它将消息分成多个分区(Partition)并存储在多个Broker上。每个分区都有一个Leader和多个Follower,Leader负责处理读写请求,Follower则从Leader同步数据。

当一个Broker宕机或者网络故障导致Leader无法正常工作时,Kafka需要进行Partition Leader选举,选出一个新的Leader来处理读写请求。选举的过程如下:

① 每个Broker都会定期向Zookeeper注册自己的Broker信息,并创建一个临时节点。这个节点的路径是/brokers/ids/[broker-id],节点的值是一个JSON格式的字符串,包含了Broker的IP地址、端口号等信息。

② 当一个Broker宕机或者网络故障导致Leader无法正常工作时,Zookeeper会检测到这个Broker的临时节点被删除,然后通知其他Broker。

③ 其他Broker会检查所有的Partition,如果某个Partition的Leader是宕机的Broker,那么它会尝试成为新的Leader。它会向Zookeeper创建一个临时节点/brokers/topics/[topic]/[partition]/[broker-id],表示它想要成为这个Partition的Leader。

④ 如果多个Broker都尝试成为Leader,那么Zookeeper会根据节点创建时间的先后顺序来选举Leader。创建时间最早的节点会成为新的Leader。

⑤ 选举完成后,新的Leader会向Zookeeper更新Partition的元数据,其他Broker会从Zookeeper获取最新的元数据,并更新自己的缓存。

需要注意的是,Kafka的Partition Leader选举是异步的,也就是说,选举完成后,可能会有一段时间内某些消息无法被正常处理。因此,Kafka的高可用性需要依赖于多个副本(Replica)的存在,以保证即使某个Broker宕机,也能够保证消息的可靠性和可用性。

11. kafka Partition Leader选举流程

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader,负责管理集群 broker 的上下线,所有 topic 的分区副本分配和 Leader 选举等工作。Controller 的信息同步工作是依赖于 Zookeeper 的。

选举流程:

① kafka每启动一个节点就会在zookeeper中注册一个节点信息,每一个broker节点都有对应的Controller,他们会争先抢占Controller的注册,谁先注册谁会被选举为 Controller Leader。

② 选举出来的 Controller 会监听 brokers 节点变化,决定 Leader 的选举,将节点信息上传到 zookeeper,其他Contorller 就会从 zookeeper 同步相关信息。

③ 假设 Broker1 中 Leader 挂了,Controller 就会监听到节点变化,然后获取到 ISR,选举新的 Leader(在 ISR 中存活为前提,按照 AR 中排在前面的优先),更新 Leader 及 ISR。
在这里插入图片描述

利用3台服务器(brokerId=0,1,2)集群来验证以上整个流程 :

① 创建一个新的 topic,3 个分区,3 个副本:

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --create --partitions 3 --replication-factor 3  --topic test1

② 查看 Leader 分布情况:

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0,2
Topic: test1    Partition: 1    Leader: 2       Replicas: 2,1,0 Isr: 2,1,0
Topic: test1    Partition: 2    Leader: 0       Replicas: 0,2,1 Isr: 0,2,1

③ 停止掉 brokerId=0 的 kafka 进程,并查看 Leader 分区情况:

假如 brokerId=0 的 kafka 进程挂掉了,那么Partition为2 的Leader 就会重新选举,选举的规则为:在 ISR 中存活为前提,按照AR中排在前面的优先,即新的Leader将是2。

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0,2
Topic: test1    Partition: 1    Leader: 2       Replicas: 2,1,0 Isr: 2,1,0
Topic: test1    Partition: 2    Leader: 0       Replicas: 0,2,1 Isr: 0,2,1

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,2
Topic: test1    Partition: 1    Leader: 2       Replicas: 2,1,0 Isr: 2,1
Topic: test1    Partition: 2    Leader: 2       Replicas: 0,2,1 Isr: 2,1

④ 停止掉 brokerId=2 的 kafka 进程,并查看 Leader 分区情况:

假如 brokerId=2 的 kafka 进程挂掉了,那么 Partition1和 Partition2 的Leader 就会重新选举,选举的规则为:在 ISR 中存活为前提,按照AR中排在前面的优先,即Partition1 和 Partition2 新的Leader都将是1。

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,2
Topic: test1    Partition: 1    Leader: 2       Replicas: 2,1,0 Isr: 2,1
Topic: test1    Partition: 2    Leader: 2       Replicas: 0,2,1 Isr: 2,1

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1
Topic: test1    Partition: 1    Leader: 1       Replicas: 2,1,0 Isr: 1
Topic: test1    Partition: 2    Leader: 1       Replicas: 0,2,1 Isr: 1

⑤ 启动 brokerId=0 的 kafka 进程,并查看 Leader 分区情况:

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1
Topic: test1    Partition: 1    Leader: 1       Replicas: 2,1,0 Isr: 1
Topic: test1    Partition: 2    Leader: 1       Replicas: 0,2,1 Isr: 1

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0
Topic: test1    Partition: 1    Leader: 1       Replicas: 2,1,0 Isr: 1,0
Topic: test1    Partition: 2    Leader: 1       Replicas: 0,2,1 Isr: 1,0

⑥ 启动 brokerId=2 的 kafka 进程,并查看 Leader 分区情况:

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0,2
Topic: test1    Partition: 1    Leader: 1       Replicas: 2,1,0 Isr: 1,0,2
Topic: test1    Partition: 2    Leader: 1       Replicas: 0,2,1 Isr: 1,0,2

⑦ 停止掉 brokerId=1 的 kafka 进程,并查看 Leader 分区情况:

假如 brokerId=1 的 kafka 进程挂掉了,那么 Partition0、Partition1和 Partition2 的Leader 就会重新选举,选举的规则为:在 ISR 中存活为前提,按照AR中排在前面的优先,即 Partition0 的Leader将为0,Partition1 的Leader将为2, Partition2 的Leader将是0。

[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0,2
Topic: test1    Partition: 1    Leader: 1       Replicas: 2,1,0 Isr: 1,0,2
Topic: test1    Partition: 2    Leader: 1       Replicas: 0,2,1 Isr: 1,0,2
        
[root@localhost kafka-01]# bin/kafka-topics.sh --zookeeper localhost:2182 --describe --topic test1
Topic:test1     PartitionCount:3        ReplicationFactor:3     Configs:
Topic: test1    Partition: 0    Leader: 0       Replicas: 1,0,2 Isr: 0,2
Topic: test1    Partition: 1    Leader: 2       Replicas: 2,1,0 Isr: 0,2
Topic: test1    Partition: 2    Leader: 0       Replicas: 0,2,1 Isr: 0,2

可以看出选举是按照AR中的顺序轮询选举的,而不是ISR中的顺序。

12. kafka HW和LEO代表什么?

HW是High Watermark的缩写,俗称高水位,它标识了一个特定的消息偏移量(offset),消费者只能拉取到这个offset之前的消息。

如图 ,它代表一个日志文件,这个日志文件中有 9 条消息,第一条消息的 offset 为0,最后一条消息的offset为8,offset为9的消息用虚线框表示,代表下一条待写入的消息。日志文件的HW为6,表示消费者只能拉取到offset在0至5之间的消息,而offset为6的消息对消费者而言是不可见的。

在这里插入图片描述

LEO是Log End Offset的缩写,它标识当前日志文件中下一条待写入消息的offset,图中offset为9的位置即为当前日志文件的LEO,LEO的大小相当于当前日志分区中最后一条消息的offset值加1。分区ISR集合中的每个副本都会维护自身的LEO,而ISR集合中最小的LEO即为分区的HW,对消费者而言只能消费HW之前的消息。

注意要点:很多资料中误将图中的offset为5的位置看作HW,而把offset为8的位置看作LEO,这显然是不对的。

13. 如何理解ISR集合与HW和LEO的关系?

① 假设某个分区的ISR集合中有3个副本,即一个leader副本和2个follower副本,此时分区的LEO和HW都为3。消息3和消息4从生产者发出之后会被先存入leader副本:

在这里插入图片描述

② 在消息写入leader副本之后,follower副本会发送拉取请求来拉取消息3和消息4以进行消息同步:

在这里插入图片描述

③ 在同步过程中,不同的 follower 副本的同步效率也不尽相同,在某一时刻follower1完全跟上了leader副本而follower2只同步了消息3,如此leader副本的LEO为5,follower1的LEO为5,follower2的LEO为4,那么当前分区的HW取最小值4,此时消费者可以消费到offset为0至3之间的消息。

在这里插入图片描述

④ 所有的副本都成功写入了消息3和消息4,整个分区的HW和LEO都变为5,因此消费者可以消费到offset为4的消息了。

在这里插入图片描述

Kafka 的复制机制既不是完全的同步复制,也不是单纯的异步复制。事实上,同步复制要求所有能工作的 follower 副本都复制完,这条消息才会被确认为已成功提交,这种复制方式极大地影响了性能。而在异步复制方式下,follower副本异步地从leader副本中复制数据,数据只要被leader副本写入就被认为已经成功提交。在这种情况下,如果follower副本都还没有复制完而落后于leader副本,突然leader副本宕机,则会造成数据丢失。Kafka使用的这种ISR的方式则有效地权衡了数据可靠性和性能之间的关系。

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

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

相关文章

buuctf re(二)+ web CheckIn

目录 re xor helloword reverse3 web SUCTF 2019 CheckIn xor 1.查壳 64位,无壳 2.ida,f5查看伪代码 3.跟进global dq是八个字节,汇编数据类型参考汇编语言---基本数据类型_汇编db类型_wwb0111的博客-CSDN博客 4.因为global变量里有一…

多商户商城有哪些功能和优势?-加速度jsudo

电商时代下,传统企业商家急需拓展业务规模,向线上拓展,而多商户小程序造价低,效应高,自然就成为了很多企业商家拓展线上营销渠道的首要选择,那么多商户小程序商城涵盖哪些功能呢?下面小编就来详细为大家解答&#xff…

UE5《Electric Dreams》项目PCG技术解析 之 理解Assembly(以SplineExample为例)

文章目录 1. 什么是Assembly2. PCG部分2.1 Assembly变换2.2 Point变换2.2.1. SG_CopyPointsWithHierachy2.2.2 过滤及点变换2.2.3. ApplyHierachy 3. 小结 1. 什么是Assembly UE5.2的PCG出了有一段时间了,大家玩得都很开心。很多朋友可能和老王一样,使用…

Rust语言从入门到入坑——(10)文件与IO

文章目录 0、引入1、命令行1.1 命令行参数1.2 命令行输入 2、文件操作2.1 读取文件2.2 写入文件 3、总结 0、引入 Rust 语言的 I/O 操作,最基本的交互模式,主流语言都具备的功能。 1、命令行 1.1 命令行参数 命令行程序是计算机程序最基础的存在形式&…

B050-cms05-轮播图 cookie session 登录

目录 轮播图修改操作删除操作查询并展示所有轮播图 无状态的HTTP协议CookieCookie的原理Cookie的创建获取Cookie更新Cookie设置cookie的声明周期设置cookie访问路径Cookie优缺点 SessionSession原理创建SessionSession的使用sesion的生命周期Session的优缺点Cookie和Session的区…

定积分计算—牛顿-莱布尼兹公式、定积分的几何意义、利用奇偶性化简、利用Wallis公式

定积分计算 前言定积分的常规计算技巧—牛顿-莱布尼茨公式定积分的几何意义利用奇偶性简化计算![在这里插入图片描述](https://img-blog.csdnimg.cn/9acfec48362141ba9486630f7060d78d.jpg)利用周期性平移和缩小积分区间利用Wallis公式利用一个常见的积分公式定积分计算练习题 …

yolov8 -01 部署

本想去配环境的步骤,在之前yolov5运行的环境下,试predict yolov8,竟然报错。 与其改bug, 选择重头来。 1. conda 创建新环境 yolo 8 conda create -n yolo82. 官网下载资料 官网下载yolo8相关资料 https://github.com/ultralytics/ultraly…

Flutter 检查连接网络 connectivity_plus

Flutter 检查连接网络 connectivity_plus 前言 有些对通讯敏感的程序,我们需要检查当前连接的网络情况。 我推荐使用 connectivity_plus https://pub-web.flutter-io.cn/packages/connectivity_plus 这个插件的好处就是支持全平台,这点非常好。 我们今天…

socketio连接失败,nginx返回502 connect() failed (111: Connection refused)

现象 我们信控平台,需要实时展示信号灯灯态(红黄绿、倒计时等) 当灯态变化时,前端信号机设备会通过socket协议将消息推送给我们的通信服务,通信服务将消息解析处理后,关联路口信息,再把信息通过…

数据库监控与调优【四】—— EXPLAIN详解

EXPLAIN详解(使用、可视化、扩展与性能计算公式) TIPS 本文基于MySQL 8.0编写,理论支持MySQL 5.0及更高版本。 什么是EXPLAIN命令 EXPLAIN命令是查看MySQL查询优化器如何执行查询的主要方法,可以很好地分析SQL语句的执行情况。每…

MPLS新手排查丢包问题

借助查问题又重新复习了一下mpls协议,首先复习一下它的报文格式: 0---------------19-------22---23------------31 | Label value | Exp | Bos | TTL | -----------------|---------|-------|-------------| 字段意义: Label v…

全网最新超详细的【Axure】Axure RP 10的下载、安装、中文字体、授权【2023年】

文章目录 1. 文章引言2. 下载Axure103. 安装Axure104. Axure10中文5. 解决axure弹框更新的问题6. 重要备注7. Axure10授权 1. 文章引言 最近在学习原型图,针对画原型图的工具,反复对比墨刀、Axure、xiaopiu后,最终选择了Axure。 接下来&…

ansible自动化IT工具安装部署与使用验证

目录 一、环境配置 1、关闭防火墙 2、免密登录配置 3、同步时区 二、服务端配置 1、安装软件 2、查看版本 3、实现远程控制huyang3 4、测试 结果验证: 一、环境配置 1、关闭防火墙 systemctl stop firewalld iptables -F setenforce0 2、免密登录配置 【huy…

二叉树题目:二叉树展开为链表

文章目录 题目标题和出处难度题目描述要求示例数据范围进阶 解法一思路和算法代码复杂度分析 解法二思路和算法代码复杂度分析 解法三思路和算法代码复杂度分析 后记 题目 标题和出处 标题:二叉树展开为链表 出处:114. 二叉树展开为链表 难度 3 级 …

8 从0开始学PyTorch | PyTorch中自动计算梯度、使用优化器

上一节,我们写了很多代码,但是不知道你有没有注意,那些代码看起来跟PyTorch关系并不是很大啊,貌似很多都是Python原生代码? 如果你是这样的感觉,那我要告诉你,你感觉的没有错。前面主要在于机制…

下面告诉你音频转换工具有哪些

今天我想和大家聊一聊音频转换工具。你是不是有时候想把一首酷炫的歌曲转换成你喜欢的音频格式,或者想把录音文件转成可编辑的格式?别担心,这里有一些超赞的音频转换工具,可以帮你解决这些问题!无论是从MP3到WAV&#…

武汉大学计算机考研分析

关注我们的微信公众号 姚哥计算机考研 更多详情欢迎咨询 武汉大学(A-)考研难度(☆☆☆☆☆) 武汉大学计算机考研招生学院是计算机学院、国家网络安全学院和测绘遥感信息工程国家重点实验室。目前均已出拟录取名单。 武汉大学计…

Redis的3大特殊数据类型(1)-BitMap

BitMap(位图/位数组)是Redis2.2.0版本中引入的一种新数据类型,该数据类型本质是一个仅含0和1的二进制字符串。因此可以把 Bitmap 想象成一个以位为单位的数组,数组的每个单元只能存储 0 和 1,数组的下标在 Bitmap 中叫做偏移量 offset&#x…

volatile关键字和ThreadLocal

作用: 1.线程的可见性:当一个线程修改一个共享变量时,另外一个线程能读到这个修改的值。 2. 顺序一致性:禁止指令重排序。 线程之间的共享变量存储在主内存中(Main Memory)中,每个线程都一个都…

StarRocks Friends 上海站活动回顾(含 PPT 下载链接)

6月17日, StarRocks & Friends 上海站活动如期而至,近百位社区小伙伴参与交流活动;针对 StarRocks 存算分离、StarRocks 在业界的应用实践、以及 StarRocks 与 BI 结合、湖仓一体规划等话题展开激烈的交流互动。 本文总结了技术交流活动…