Kafka-快速实战

news2024/12/25 23:45:39

Kafka介绍

ChatGPT对于Apache Kafka的介绍：

Apache Kafka是一个分布式流处理平台，最初由LinkedIn开发并于2011年开源。它主要用于解决大规模数据的实时流式处理和数据管道问题。

Kafka是一个分布式的发布-订阅消息系统，可以快速地处理高吞吐量的数据流，并将数据实时地分发到多个消费者中。Kafka消息系统由多个broker（服务器）组成，这些broker可以在多个数据中心之间分布式部署，以提供高可用性和容错性。

Kafka的基本架构由生产者、消费者和主题（topic）组成。生产者可以将数据发布到指定的主题，而消费者可以订阅这些主题并消费其中的数据。同时，Kafka还支持数据流的处理和转换，可以在管道中通过Kafka Streams API进行流式计算，例如过滤、转换、聚合等。

Kafka使用高效的数据存储和管理技术，能够轻松地处理TB级别的数据量。其优点包括高吞吐量、低延迟、可扩展性、持久性和容错性等。

Kafka在企业级应用中被广泛应用，包括实时流处理、日志聚合、监控和数据分析等方面。同时，Kafka还可以与其他大数据工具集成，如Hadoop、Spark和Storm等，构建一个完整的数据处理生态系统。

MQ的作用

MQ：MessageQueue，消息队列。 队列，是一种FIFO 先进先出的数据结构。消息则是跨进程传递的数据。一个典型的MQ系统，会将消息消息由生产者发送到MQ进行排队，然后根据一定的顺序交由消息的消费者进行处理。

主要作用：

  • 异步

    异步能提高系统的响应速度、吞吐量。

  • 解耦

    1、服务之间进行解耦，才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。

    2、另外，解耦后可以实现数据分发。生产者发送一个消息后，可以由一个或者多个消费者进行消费，并且消费者的增加或者减少对生产者没有影响。

  • 削峰

    作用：以稳定的系统资源应对突发的流量冲击。

为什么要用Kafka

典型日志聚合的应用场景：

业务场景决定了产品的特点。

1、数据吞吐量很大： 需要能够快速收集各个渠道的海量日志

2、集群容错性高：允许集群中少量节点崩溃

3、功能不需要太复杂：Kafka的设计目标是高吞吐、低延迟和可扩展，主要关注消息传递而不是消息处理。所以，Kafka并没有支持死信队列、顺序消息等高级功能。

4、允许少量数据丢失：Kafka本身也在不断优化数据安全问题，目前基本上可以认为Kafka可以做到不会丢数据。

Kafka快速上手

实验环境

准备三台CentOS7的虚拟机，预备搭建三台机器的集群。分别配置机器名 worker1，worker2，worker3。

vi /etc/hosts

192.168.146.128 worker1
192.168.146.129 worker2
192.168.146.130 worker3

关闭防火墙(实验环境建议关闭)

firewall-cmd --state   查看防火墙状态
systemctl stop firewalld.service   关闭防火墙

补充：虚拟机centos7遇到问题，bash: jps: 未找到命令... 的解决方案

yum list *openjdk-devel*
#安装适合自己的版本
yum install java-1.8.0-openjdk-devel.x86_64
#安装过程有几个同意步骤，输入y，安装完成测试jps ok！

下载kafka地址：Apache Kafka ，选择kafka_2.13-3.4.0.tgz进行下载。

下载Zookeeper地址 Apache ZooKeeper ，这里选择比较新的3.6.1版本。

下载完成后，将这两个工具包上传到服务器上，解压后，分别放到/app/kafka和/app/zk目录下。并将部署目录下的bin目录路径配置到path环境变量中。

环境变量/etc/profile最终配置：

export ZK_HOME=/app/zk/apache-zookeeper-3.6.4-bin
export KAFKA_HOME=/app/kafka/kafka_2.13-3.4.0
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
export PATH=$KAFKA_HOME/bin:$ZK_HOME/bin:$JAVA_HOME/bin:$PATH
export CLASSPATH=:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

单机服务体验

1、启动Kafka之前需要先启动Zookeeper。

#解压命令
tar zxvf apache-zookeeper-3.6.4-bin.tar.gz
tar zxvf kafka_2.13-3.4.0.tgz

#这里用Kafka自带的Zookeeper启动脚本
cd kafka_2.13-3.4.0/
nohup bin/zookeeper-server-start.sh config/zookeeper.properties &

通过jps指令看到一个QuorumPeerMain进程，确定服务启动成功。zk默认启动在2181端口

启动遇到问题可以查看nohup.out日志文件，注意脚本的执行权限

2、启动Kafka

nohup bin/kafka-server-start.sh config/server.properties &

启动完成后，使用jps指令，看到一个kafka进程，确定服务启动成功。服务默认9092端口

3、简单收发消息

Kafka的基础工作机制：消息发送者将消息发送到kafka上指定的topic，消息消费者从指定的topic上消费消息。

简单收到命令：

#创建Topic
bin/kafka-topics.sh --create --topic test --bootstrap-server localhost:9092
#查看Topic
bin/kafka-topics.sh --describe --topic test --bootstrap-server localhost:9092
#启动一个消息发送者端，往一个名为test的Topic发送消息
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
#启动一个消息接收者端，接收名为test的Topic消息
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test

生产者端示例：

消费者端示例：

注意：消费者启动命令执行后有几秒钟延迟（启动中接收不到消息），默认处理启动成功后接收到的消息

4、其他消费模式

指定消费进度

#通过--from-beginning消费之前发的消息
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic test
#指定从哪一条消息开始消费，offset表示索引/偏移量，索引4也就是第五条消息开始，0号partition
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --partition 0 --offset 4 --topic test

分组消费

kafka中的同一条消息，只能被同一个消费者组下的某一个消费者消费。而不属于同一个消费者组的其他消费者，也可以消费到这一条消息。通过--consumer-property group.id=testGroup指定消费者组

#两个消费者实例属于同一个消费者组
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGroup --topic test
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGroup --topic test
#这个消费者实例属于不同的消费者组
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGroup2 --topic test

查看消费者组的偏移量

#查看消费者组的情况，包括消费进度。
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group testGroup

···命令输出结果示例
Consumer group 'testGroup' has no active members. #没有活跃消费者
    
GROUP       TOPIC  PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG  CONSUMER-ID  HOST  CLIENT-ID
testGroup  test   0          20              20              0    ...			...	  ...
···

描述：
PARTITION		分区
CURRENT-OFFSET	当前消费进度
LOG-END-OFFSET	日志种最大消息进度
LAG				未消费消息数

虽然业务上是通过Topic来分发消息的，但是实际上，消息是保存在Partition这样一个数据结构上

理解Kakfa的消息传递机制

Kafka的消息发送者和消息消费者通过Topic这样一个逻辑概念来进行业务沟通。但是实际上，所有的消息是存在服务端的Partition这样一个数据结构当中的。

  • 客户端Client： 包括消息生产者和消息消费者。

  • 消费者组：每个消费者可以指定一个所属的消费者组，相同消费者组的消费者共同构成一个逻辑消费者组。每一个消息会被多个感兴趣的消费者组消费，但是在每一个消费者组内部，一个消息只会被消费一次。

  • 服务端Broker：一个Kafka服务器就是一个Broker。

  • 话题Topic：这是一个逻辑概念，一个Topic被认为是业务含义相同的一组消息。客户端都通过绑定Topic来生产或者消费自己感兴趣的话题。

  • 分区Partition：Topic只是一个逻辑概念，而Partition就是实际存储消息的组件。每个Partiton就是一个queue队列结构。所有消息以FIFO先进先出的顺序保存在这些Partition分区中。

Kafka集群服务

为什么要用集群？

单机服务下，Kafka已经具备了非常高的性能。TPS能够达到百万级别。但是，在实际工作中使用时，单机搭建的Kafka会有很大的局限性。

一方面：消息太多，需要分开保存。Kafka是面向海量消息设计的，一个Topic下的消息会非常多，单机服务很难存得下来。这些消息就需要分成不同的Partition，分布到多个不同的Broker上。这样每个Broker就只需要保存一部分数据。这些分区的个数就称为分区数。

另一方面：服务不稳定，数据容易丢失。单机服务下，如果服务崩溃，数据就丢失了。为了保证数据安全，就需要给每个Partition配置一个或多个备份，保证数据不丢失。Kafka的集群模式下，每个Partition都有一个或多个备份。Kafka会通过一个统一的Zookeeper集群作为选举中心，给每个Partition选举出一个主节点Leader，其他节点就是从节点Follower。主节点负责响应客户端的具体业务请求，并保存消息。而从节点则负责同步主节点的数据。当主节点发生故障时，Kafka会选举出一个从节点成为新的主节点。

最后：Kafka集群中的这些Broker信息，包括Partition的选举信息，都会保存在额外部署的Zookeeper集群当中，这样，kafka集群就不会因为某一些Broker服务崩溃而中断。

Kafka集群架构：

1、部署Zookeeper集群

Zookeeper是一种多数同意的选举机制，允许集群中少半数节点出现故障。因此，在搭建集群时，通常采用奇数节点，这样可以最大化集群的高可用特性。

先将下载下来的Zookeeper解压到/app/zk目录。

然后进入conf目录，修改配置文件。在conf目录中，提供了一个zoo_sample.cfg示例文件。只需要将这个文件复制一份zoo.cfg，并修改其中的关键配置：

#Zookeeper的本地数据目录，默认是/tmp/zookeeper。这是Linux的临时目录，随时会被删掉。
dataDir=/app/zk/data
#Zookeeper的服务端口
clientPort=2181
#集群节点配置
server.1=192.168.146.128:2888:3888
server.2=192.168.146.129:2888:3888
server.3=192.168.146.130:2888:3888

clientPort 2181是对客户端开放的服务端口。

集群配置部分， server.x这个x就是节点在集群中的myid。后面的2888端口是集群内部数据传输使用的端口。3888是集群内部进行选举使用的端口。

zookeeper启动时data目录会自动创建，但是需要手动在data目录下面添加一个myid文件

#启动服务
bin/zkServer.sh --config conf start
#查看服务状态
bin/zkServer.sh status

2、部署Kafka集群

kafka服务并不需要进行选举，因此也没有奇数台服务的建议。

首先将Kafka解压到/app/kafka目录下，然后进入config目录，修改server.properties。重点关注的配置：

#broker 的全局唯一编号，不能重复，只能是数字。
broker.id=0
#数据文件地址。同样默认是给的/tmp目录。
log.dirs=/app/kafka/logs
#默认的每个Topic的分区数
num.partitions=1
#zookeeper的服务地址
zookeeper.connect=worker1:2181,worker2:2181,worker3:2181

多个Kafka服务注册到同一个zookeeper集群上的节点，会自动组成集群。

server.properties文件中比较重要的核心配置：

PropertyDefaultDescription
broker.id0broker的“名字”，你可以选择任意你喜欢的数字作为id，只要id是唯每个broker都可以用一个唯一的非负整数id进行标识；这个id可以作为一的即可。
log.dirs/tmp/kafka-logskafka存放数据的路径。这个路径并不是唯一的，可以是多个，路径之间只需要使用逗号分隔即可；每当创建新partition时，都会选择在包含最少partitions的路径下进行。
listenersPLAINTEXT://127.0.0.1:9092server接受客户端连接的端口，ip配置kafka本机ip即可
zookeeper.connectlocalhost:2181zookeeper连接地址。hostname:port。如果是Zookeeper集群，用逗号连接。
log.retention.hours168每个日志文件删除之前保存的时间。
num.partitions1创建topic的默认分区数
default.replication.factor1自动创建topic的默认副本数量
min.insync.replicas1当producer设置acks为-1时，min.insync.replicas指定replicas的最小数目（必须确认每一个repica的写数据都是成功的），如果这个数目没有达到，producer发送消息会产生异常
delete.topic.enablefalse是否允许删除主题

启动服务：

bin/kafka-server-start.sh -daemon config/server.properties

理解服务端的Topic、Partition和Broker

# 创建一个分布式的Topic
bin/kafka-topics.sh --bootstrap-server worker1:9092 --create --replication-factor 2 --partitions 4 --topic disTopic
# 列出所有的Topic
bin/kafka-topics.sh --bootstrap-server worker1:9092 --list
# 查看列表情况
bin/kafka-topics.sh --bootstrap-server worker1:9092 --describe --topic disTopic

这里硬件资源有限，只启动了两台（上面截图）

1、--create创建集群，可以指定一些补充的参数。大部分的参数都可以在配置文件中指定默认值。

  • partitons参数表示分区数，这个Topic下的消息会分别存入这些不同的分区中。

  • replication-factor表示每个分区有几个备份。

2、--describe查看Topic信息。

  • partiton参数列出了四个partition，后面带有分区编号，用来标识这些分区。

  • Leader表示这一组partiton中的Leader节点是哪一个。这个Leader节点就是负责响应客户端请求的主节点。从这里可以看到，Kafka中的每一个Partition都会分配Leader，也就是说每个Partition都有不同的节点来负责响应客户端的请求。这样就可以将客户端的请求做到尽量的分散。

  • Replicas参数表示这个partition的多个备份是分配在哪些Broker上的。也称为AR。这里的0,1就对应配置集群时指定的broker.id。但是，Replicas列出的只是一个逻辑上的分配情况，并不关心数据实际是不是按照这个分配。甚至有些节点服务挂了之后，Replicas中也依然会列出节点的ID。

  • ISR参数表示partition的实际分配情况。他是AR的一个子集，只列出那些当前还存活，能够正常同步数据的那些Broker节点。

之前在配置Kafka集群时，指定了一个log.dirs属性，指向了一个服务器上的日志目录。进入这个目录，就能看到每个Broker的实际数据承载情况。

Kafka当中，Topic是一个数据集合的逻辑单元。同一个Topic下的数据，实际上是存储在Partition分区中的，Partition就是数据存储的物理单元。而Broker是Partition的物理载体，这些Partition分区会尽量均匀的分配到不同的Broker机器上。offset，就是每个消息在partition上的偏移量。

Kafka为何要这样来设计Topic、Partition和Broker的关系呢？

1、Kafka设计需要支持海量的数据，而这样庞大的数据量，一个Broker是存不下的。那就拆分成多个Partition，每个Broker只存一部分数据。这样极大的扩展了集群的吞吐量。

2、每个Partition保留了一部分的消息副本，如果放到一个Broker上，就容易出现单点故障。所以就给每个Partition设计Follower节点，进行数据备份，从而保证数据安全。另外，多备份的Partition设计也提高了读取消息时的并发度。

3、在同一个Topic的多个Partition中，会产生一个Partition作为Leader。这个Leader Partition会负责响应客户端的请求，并将数据往其他Partition分发。

Kafka集群的整体结构

1、Topic是一个逻辑概念，Producer和Consumer通过Topic进行业务沟通。

2、Topic并不存储数据，Topic下的数据分为多组Partition，尽量平均的分散到各个Broker上。每组Partition包含Topic下一部分的消息。每组Partition包含一个Leader Partition以及若干个Follower Partition进行备份，每组Partition的个数称为备份因子 replica factor。

3、Producer将消息发送到对应的Partition上，然后Consumer通过Partition上的Offset偏移量，记录自己所属消费者组Group在当前Partition上消费消息的进度。

4、Producer发送给一个Topic的消息，会由Kafka推送给所有订阅了这个Topic的消费者组进行处理。但是在每个消费者组内部，只会有一个消费者实例处理这一条消息。

5、最后，Kafka的Broker通过Zookeeper组成集群。然后在这些Broker中，需要选举产生一个担任Controller角色的Broker。这个Controller的主要任务就是负责Topic的分配以及后续管理工作。在我们实验的集群中，这个Controller实际上是通过ZooKeeper产生的。

Kraft集群--了解

Kraft集群简介

Kraft是Kafka从2.8.0版本开始支持的一种新的集群架构方式。其目的主要是为了摆脱Kafka对Zookeeper的依赖。因为以往基于Zookeeper搭建的集群，增加了Kafka演进与运维的难度，逐渐开始成为Kakfa拥抱云原生的一种障碍。使用Kraft集群后，Kafka集群就不再需要依赖Zookeeper，将之前基于Zookeeper管理的集群数据，转为由Kafka集群自己管理。

虽然官方规划会在未来完全使用Kraft模式代替现有的Zookeeper模式，但是目前来看，Kraft集群还是没有Zookeeper集群稳定，所以现在大部分企业还是在使用Zookeeper集群。

2022年10月3日发布的3.3.1版本才开始将KRaft标注为准备用于生产。KIP-833: Mark KRaft as Production Ready。 这离大规模使用还有比较长的距离。

实际上，Kafka摆脱Zookeeper是一个很长的过程。在之前的版本迭代过程中，Kafka就已经在逐步减少Zookeeper中的数据。在Kafka的bin目录下的大量脚本，早期都是要指定zookeeper地址，后续长期版本更迭过程中，逐步改为通过--bootstrap-server参数指定Kafka服务地址。到目前版本，基本所有脚本都已经抛弃了--zookeeper参数了。

传统的Kafka集群，会将每个节点的状态信息统一保存在Zookeeper中，并通过Zookeeper动态选举产生一个Controller节点，通过Controller节点来管理Kafka集群，比如触发Partition的选举。而在Kraft集群中，会固定配置几台Broker节点来共同担任Controller的角色，各组Partition的Leader节点就会由这些Controller选举产生。原本保存在Zookeeper中的元数据也转而保存到Controller节点中。

Raft协议是目前进行去中心化集群管理的一种常见算法，类似于之前的Paxos协议，是一种基于多数同意，从而产生集群共识的分布式算法。Kraft则是Kafka基于Raft协议进行的定制算法。

新的Kraft集群相比传统基于Zookeeper的集群，有一些很明显的好处：

  • Kafka可以不依赖于外部框架独立运行。这样减少Zookeeper性能抖动对Kafka集群性能的影响，同时Kafka产品的版本迭代也更自由。

  • Controller不再由Zookeeper动态选举产生，而是由配置文件进行固定。这样比较适合配合一些高可用工具来保持集群的稳定性。

  • Zookeeper的产品特性决定了他不适合存储大量的数据，这对Kafka的集群规模(确切的说应该是Partition规模)是极大的限制。摆脱Zookeeper后，集群扩展时元数据的读写能力得到增强。

不过，由于分布式算法的复杂性。Kraft集群和同样基于Raft协议定制的RocketMQ的Dledger集群一样，都还不太稳定，在真实企业开发中，用得相对还是比较少。

配置Kraft集群

在Kafka的config目录下，提供了一个kraft的文件夹，在这里面就是Kraft协议的参考配置文件。在这个文件夹中有三个配置文件，broker.properties，controller.properties，server.properties，分别给出了Kraft中三种不同角色的示例配置。

  • broker.properties：数据节点

  • controller.properties：Controller控制节点

  • server.properties：即可以是数据节点，又可以是Controller控制节点。

这里同样列出几个比较关键的配置项，按照自己的环境定制。

#配置当前节点的角色。Controller相当于Zookeeper的功能，负责集群管理。Broker提供具体的消息转发服务。
process.roles=broker,controller
#配置当前节点的id。与普通集群一样，要求集群内每个节点的ID不能重复。
node.id=1
#配置集群的投票节点。其中@前面的是节点的id，后面是节点的地址和端口，这个端口跟客户端访问的端口是不一样的。通常将集群内的所有Controllor节点都配置进去。
controller.quorum.voters=1@worker1:9093,2@worker2:9093,3@worker3:9093
#Broker对客户端暴露的服务地址。基于PLAINTEXT协议。
advertised.listeners=PLAINTEXT://worker1:9092
#Controller服务协议的别名。默认就是CONTROLLER
controller.listener.names=CONTROLLER
#配置监听服务。不同的服务可以绑定不同的接口。这种配置方式在端口前面是省略了一个主机IP的，主机IP默认是使用的java.net.InetAddress.getCanonicalHostName()
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
#数据文件地址。默认配置在/tmp目录下。
log.dirs=/app/kafka/kraft-log
#topic默认的partition分区数。
num.partitions=2

将配置文件分发，并修改每个服务器上的node.id属性和advertised.listeners属性。

由于Kafka的Kraft集群对数据格式有另外的要求，所以在启动Kraft集群前，还需要对日志目录进行格式化。

[root@worker1 kafka_2.13-3.4.0]# bin/kafka-storage.sh random-uuid
vRqZXTz0QT6FJKmeyEU7Yw
[root@worker1 kafka_2.13-3.4.0]# bin/kafka-storage.sh format -t vRqZXTz0QT6FJKmeyEU7Yw -c config/kraft/server.properties
Formatting /tmp/kraft-combined-logs with metadata.version 3.4-IV0.

-t 表示集群ID，三个服务器上可以使用同一个集群ID。

接下来就可以指定配置文件，启动Kafka的服务了。 例如，在Worker1上，启动Broker和Controller服务。

bin/kafka-server-start.sh -daemon config/kraft/server.properties

等三个服务都启动完成后，就可以像普通集群一样去创建Topic，并维护Topic的信息了。

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

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

相关文章

前端-杂记

前端-杂记

1 子域请求时候会默认带上父域下的Coolkie 2 document.cookie 设置cookie只能设置当前域和父域，且path只能是当前页或者/ 比如当前页面地址为 http://localhost:3000/about 我们设置 document.cookie "demo11"; 设置 document.cookie "demo22; …
阅读更多...
7.25 SpringBoot项目实战【我的借阅记录】

7.25 SpringBoot项目实战【我的借阅记录】

文章目录 前言一、编写控制器二、编写服务层三、Git提交前言 至此，我们已经实现 图书借阅、收藏、评论等场景，最后来到【还书】场景，首先 还书的 入口 一般 是【我的借阅记录】，在这里可以根据产品设计，对于需要归还的书 操作【还书】，所以本文来实现【我的借阅记录】。…
阅读更多...
基于ssm医院住院综合服务管理系统设计与开发论文

基于ssm医院住院综合服务管理系统设计与开发论文

摘 要 互联网发展至今，无论是其理论还是技术都已经成熟，而且它广泛参与在社会中的方方面面。它让信息都可以通过网络传播，搭配信息管理工具可以很好地为人们提供服务。针对医院住院信息管理混乱，出错率高，信息安全性差…
阅读更多...
网站高性能架构设计——高性能数据库集群

网站高性能架构设计——高性能数据库集群

从公众号转载，关注微信公众号掌握更多技术动态 --------------------------------------------------------------- 一、高性能数据库简介 1.高性能数据库方式 读写分离：将访问压力分散到集群中的多个节点，没有分散存储压力 分库分表&…
阅读更多...
【unity】如何用Unity获取Windows桌面

【unity】如何用Unity获取Windows桌面

【背景】 默认的Unity可实现的屏幕共享仅仅针对Unity编辑器的编辑窗口中的Camera展现的内容。本篇研究如何实现用Unity实时反映Windows桌面窗口画面。 【准备插件】 下载地址： https://download.csdn.net/download/weixin_41697242/88623496 将解压后的文件夹直…
阅读更多...
排序算法之一：直接插入排序

排序算法之一：直接插入排序

1.基本思想 直接插入排序是一种简单的插入排序法，其基本思想是： 把待排序的记录按其关键码值的大小逐个插入到一个已经排好序的有序序列中，直到所有的记录插入完为止，得到一个新的有序序列 实际中我们玩扑克牌时，就用…
阅读更多...
【AI】java，在集合中找最接近给定值的数，且比给定值小

【AI】java，在集合中找最接近给定值的数，且比给定值小

目录 一、最终得到的方案 二、AI辅助找到方案 2.1 【C知道】提供java代码支持 2.2 【文心一言】提供字段翻译支持 一、最终得到的方案 /*** 在 collection 中，找跟 value 最大接近值，且该值小于等于 value** param collection 不为null。* param val…
阅读更多...
css 纯样式实现绘出进度条

css 纯样式实现绘出进度条

效果： css代码： .bar{height: 14px;width: 100%;font-size: 10px;margin-top: 5px;background-color: #f5f5f5;}.bar::before{display: block;counter-reset: progress var(--precent); content: ;width: calc(1% * var(--precent));color: #fff;height:…
阅读更多...
酸奶店创业新模式，可以轻松应付风险的对策

酸奶店创业新模式，可以轻松应付风险的对策

本人经营一家酸奶店，已经5年时间，也不断学习和探索新的模式，希望我的一些经验可以帮到你。（可以点赞收藏，方便以后随时查阅） 这几年，各行各业，大家都在说，生意不好做&am…
阅读更多...
Qt设置类似于qq登录页面(ikun)

Qt设置类似于qq登录页面(ikun)

头文件 #ifndef WIDGET_H #define WIDGET_H#include <QWidget> #include <QWindow> #include <QIcon> #include <QLabel> #include <QMovie> #include <QLineEdit> #include <QPushButton>QT_BEGIN_NAMESPACE namespace Ui { class…
阅读更多...
jemeter，断言：响应断言、Json断言

jemeter，断言：响应断言、Json断言

一、响应断言 接口A请求正常返回值如下&#xff1a; {"status": 10013, "message": "user sign timeout"} 在该接口下创建【响应断言】元件&#xff0c;配置如下&#xff1a; 若断言成功&#xff0c;则查看结果树的接口显示绿色&#xff0c;若…
阅读更多...
新版Spring Security6.2案例 - Basic HTTP Authentication

新版Spring Security6.2案例 - Basic HTTP Authentication

前言&#xff1a; 书接上文&#xff0c;翻译官网Authentication的Username/Password这页&#xff0c;接下来继续翻译basic的这页&#xff0c;因为官网说的都是原理性的&#xff0c;这边一个小案例关于basic http authentication。 Basic Authentication 本节介绍 HTTP 基本身…
阅读更多...
C语言union联合体（共用体）

C语言union联合体（共用体）

一、定义 联合体&#xff08;共用体&#xff09;是一种特殊的自定义的数据类型&#xff0c;它包含一系列的成员变量&#xff0c;这些成员变量共用一块内存空间。 语法&#xff1a; union 标识符 { data_type 标识符1; data_type 标识符2; . . . dat…
阅读更多...
电影推荐系统

电影推荐系统

基于springboot vue实现的电影推荐系统&#xff0c;通过Jsoup数据爬取。 效果图如下&#xff1a;
阅读更多...
Java01 169-184

Java01 169-184

数组添加 import java.util.Scanner; public class ArrayAdd02 {public static void main(String[] args) {Scanner myScanner new Scanner(System.in);//数组一旦定义&#xff0c;不可以增加&#xff0c;必须增加新的数组int[] arr {1, 2, 3};do {int[] arrNew new int[arr…
阅读更多...
2023年【G3锅炉水处理】免费试题及G3锅炉水处理模拟试题

2023年【G3锅炉水处理】免费试题及G3锅炉水处理模拟试题

题库来源&#xff1a;安全生产模拟考试一点通公众号小程序 2023年【G3锅炉水处理】免费试题及G3锅炉水处理模拟试题&#xff0c;包含G3锅炉水处理免费试题答案和解析及G3锅炉水处理模拟试题练习。安全生产模拟考试一点通结合国家G3锅炉水处理考试最新大纲及G3锅炉水处理考试真…
阅读更多...
目标检测DOTA数据集提取感兴趣类别数据

目标检测DOTA数据集提取感兴趣类别数据

DOTA数据集 DOTA数据集包含2806张航空图像&#xff0c;尺寸大约从800x800到4000x4000不等&#xff0c;包含15个类别共计188282个实例。其标注方式为四点确定的任意形状和方向的四边形&#xff08;区别于传统的对边平行bbox&#xff09;。类别分别为&#xff1a;plane, ship, s…
阅读更多...
20、备忘录模式（Memento Pattern，不常用）

20、备忘录模式（Memento Pattern，不常用）

备忘录模式又叫作快照模式&#xff0c;该模式将当前对象的内部状态保存到备忘录中&#xff0c;以便在需要时能将该对象的状态恢复到原先保存的状态。 备忘录模式提供了一种保存和恢复状态的机制&#xff0c;常用于快照的记录和状态的存储&#xff0c;在系统发生故障或数据发生…
阅读更多...
为什么QLC NAND才是ZNS SSD最大的赢家？-part2

为什么QLC NAND才是ZNS SSD最大的赢家？-part2

ZNS出现的背景是什么&#xff1f;ZNS SSD的原理是把namespace空间划分多个zone空间&#xff0c;zone空间内部执行顺序读写。 在ZNS的场景下&#xff0c;不同应用按照Zone配置信息&#xff0c;相应存放业务数据。由于是Host管理数据的摆放和存取位置&#xff0c;会最大程度减少G…
阅读更多...
山海鲸可视化软件：选择合适的图表，让数据可视化更高效

山海鲸可视化软件：选择合适的图表，让数据可视化更高效

作为一名山海鲸可视化软件的开发者&#xff0c;我深知选择合适的图表对于数据可视化的重要性。下面我将从开发者的角度&#xff0c;分享一些关于如何选择合适可视图表的建议。 首先&#xff0c;我们需要明确数据可视化的目标。不同的图表类型具有不同的特点和适用场景&#xff…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023