kafka springboot 集成配置+测试

最新推荐文章于 2024-05-01 23:43:02 发布

yang_zzu

最新推荐文章于 2024-05-01 23:43:02 发布

阅读量6.6k

点赞数 1

分类专栏： java开发文章标签： kafka配置解析 java

本文链接：https://blog.csdn.net/yang_zzu/article/details/105657129

版权

java开发专栏收录该内容

101 篇文章 1 订阅

订阅专栏

partitions,replication(设置)

Broker(集群中一个服务器，称为一个 broker)

数据在kafka里的存储机制：

消费：

亲自测试，springboot 不会自动的帮你提交 offset 偏移量。

我的项目中的springboot + kakfa配置内容

kafka在代码中的的使用主要是对配置文件的配置，与服务器上配置文件的配置，

实际生产、消费的代码很简单。

----------------------------------------------------------------------------------------------------------------------------------

partitions,replication(设置)

auto.create.topics.enable参数为true（默认值就是true），在配置文件中没有找到

num.partitions（默认值为1）个分区和default.replication.factor（默认值为1）个副本

default.replication.factor，在配置文件中也没有找到，

副本的数量不能大于broker的数量（集群服务器的数量）

如果是一个副本，则会均匀分布在broker中

不建议将auto.create.topics.enable参数设置为true，因为这个参数会影响topic的管理与维护。

消息会通过负载均衡发布到不同的分区上，消费者会监测偏移量来获取哪个分区有新数据，从而从该分区上拉取消息数据。

分区数越多，在一定程度上会提升消息处理的吞吐量，因为kafka是基于文件进行读写，因此也需要打开更多的文件句柄，也会增加一定的性能开销。

如果分区过多，那么日志分段也会很多，写的时候由于是批量写，其实就会变成随机写了，随机 I/O 这个时候对性能影响很大。所以一般来说 Kafka 不能有太多的 Partition。

当broker和partions一样时，就均匀分布在不同的broker上。

建议：

replication.factor 主题副本数量（主题指的是topic）<= broker数量（集群服务器个数）

partitions数量 >= broker数量（建议相等就可以了，如果想大于的话建议使用broker的整数倍，这样对集群压力比较均匀）

看了一下，运维配的内容：

#########Internal Topic Settings#######

offsets.topic.replication.factor=3

transaction.state.log.replication.factor=3

transaction.state.log.min.isr=1

对副本的操作，及一些优化，可以参考：

kafka增加副本+增加partition+加速消费_yang_zzu的博客-CSDN博客

----------------------------------------------------------------------------------------------------------------------------------

生产者机制：

设置缓冲区大小

buffer.memory

Sender线程会把多个Batch打包成一个Request发送到Kafka服务器上去。

缓冲区太小：会导致消息快速的写入内存缓冲里面，但是Sender线程来不及把Request发送到Kafka服务器。

数据打包的大小

batch.size

提升batch的大小，可以允许更多的数据缓冲在里面，那么一次Request发送出去的数据量就更多了，这样吞吐量可能会有所提升。过于大了之后，要是数据老是缓冲在Batch里迟迟不发送出去，那么岂不是你发送消息的延迟就会很高。

Batch的最大存活时间

linger.ms

设置为25ms,则在batch从创建开始到25ms的时候，即使没有达到batch设置的大小，以一样会发送出去。避免一个Batch迟迟凑不满，导致消息一直积压在内存里发送不出去的情况。这是一个很关键的参数。

最大请求设置

max.request.size

每次发送给Kafka服务器请求的最大大小，即一个 request 请求的最大大小

重试机制

“retries”和“retries.backoff.ms”决定了重试机制，也就是如果一个请求失败了可以重试几次，每次重试的间隔是多少毫秒。比如给100ms的重试间隔。

----------------------------------------------------------------------------------------------------------------------------------

Broker(集群中一个服务器，称为一个 broker)

Broker发生宕机的情况下，该broker中存储的partion(leader)会停止工作，该partion会在剩余的broker中选出新的leader（serially的方式），kafka controller节点broker自动完成，

在通常情况下，当一个broker有计划地停止服务时，那么controller会在服务停止之前，将该broker上的所有leader一个个地移走。由于单个leader的移动时间大约只需要花费几毫秒，因此从客户层面看，有计划的服务停机只会导致系统在很小时间窗口中不可用。（注：在有计划地停机时，系统每一个时间窗口只会转移一个leader，其他leader皆处于可用状态。）

根据经验，如果你十分关心消息延迟问题，限制每个broker节点的partition数量是一个很好的主意：对于b个broker节点和复制因子为r的kafka集群，整个kafka集群的partition数量最好不超过100*b*r个，即单个partition的leader数量不超过100.

根据经验，为了达到较好的吞吐量，我们必须在producer端为每个分区分配至少几十KB的内存（指的是producer.batch-size，但是在这个值增加之后，producer.buffer-memory，缓冲区的大小也要相应的发生变化），并且在分区数量显著增加时调整可以使用的内存数量。

----------------------------------------------------------------------------------------------------------------------------------

数据在kafka里的存储机制：

Message

Topic

Partition

Segment = index.index(索引) + data.log(数据)

一台服务器为一个Broker（假设3台服务器，就有3个broker）

一个broker有多个partition(假设，一个broker存在3个partition)

一个topic可以存储在多个patition上面，任何一个Partition，只有Leader是对外提供读写服务的。

Partition多副本，称为，一个partition有多个副本。（并不是说每一个broker上面存储的partion个数都相等，）

Partition(Leader)对外提供读写服务。

Leader接收到数据，Follower副本会不停的给他发送请求尝试去拉取最新的数据，拉取到自己本地后，写入磁盘中。

kafka broker 主从节点同步的方式，ISR全称是“In-Sync Replicas”，也就是保持同步的副本，他的含义就是，跟Leader始终保持同步的Follower有哪些。

----------------------------------------------------------------------------------------------------------------------------------

消费：

在kafka0.10.1之后的版本中，将session.timeout.ms 和 max.poll.interval.ms 解耦了。也就是说：new KafkaConsumer对象后，在while true循环中执行consumer.poll拉取消息这个过程中，其实背后是有2个线程的，即一个kafka consumer实例包含2个线程：一个是heartbeat 线程，另一个是processing线程，processing线程可理解为调用consumer.poll方法执行消息处理逻辑的线程，而heartbeat线程是一个后台线程，对程序员是"隐藏不见"的。如果消息处理逻辑很复杂，比如说需要处理5min，那么 max.poll.interval.ms可设置成比5min大一点的值。而heartbeat 线程则和上面提到的参数 heartbeat.interval.ms有关，heartbeat线程每隔heartbeat.interval.ms向coordinator发送一个心跳包，证明自己还活着。只要 heartbeat线程在 session.timeout.ms 时间内向 coordinator发送过心跳包，那么 group coordinator就认为当前的kafka consumer是活着的。

consumer在max.poll.interval.ms的时间内定时向 group coordinator发送心跳，则认为在 max.poll.interval.ms的时间内该consumer是有效的，

心跳heartbeat-interval，默认是3秒，即session.timeout的1/3

如果在session.timeout时间内没有检测到心跳，则认为该consumer失效

spring.kafka.consumer.max-poll-records=500   （拉取的最大为500条数据）

spring.session.timeout=10000ms（在10s内，消费者没有发送心跳则认为该消费者死掉）

spring.kafka.consumer.heartbeat-interval=3000ms

max.poll.interval.ms（默认是5分钟，五分钟后没有再次进行poll则，该消费者死掉）

如果设置为手动提交，但是在代码中没有，设置为手动提交，

代码会正常的进行生产、消费，

如果服务再次重启，则，会将之前没有提交的offset 数据再次消费一遍

在网上查找的资料（说的是，springboot 集成 kafka，在设置为手动提交之后，如果没有在代码中手动提交则springboot框架会自动帮你提交）

亲自测试，springboot 不会自动的帮你提交 offset 偏移量。

-----------------------------------------------------------------------------------------------------------------------------

我的项目中的springboot + kakfa配置内容

要修改的内容：（基于手动提交的方式进行设置，手动提交的方式比较安全，可控性比较高）

#以逗号分隔的主机：端口对列表，用于建立与Kafka群集的初始连接。不需要指定所有的的 broker
spring.kafka.bootstrap-servers=192.168.232.100:9092

#在侦听器容器中运行的线程数,多线程消费（这个也要合理的进行设置，不要设置的太多）
spring.kafka.listener.concurrency=3

#========================================================== kafka ===============================================================
#以逗号分隔的主机：端口对列表，用于建立与Kafka群集的初始连接。不需要指定所有的的 broker
spring.kafka.bootstrap-servers=192.168.232.100:9092

##################################  producer的配置参数（开始）##################################
#procedure要求leader在考虑完成请求之前收到的确认数，用于控制发送记录在服务端的持久化，其值可以为如下：
#acks = 0 如果设置为零，则生产者将不会等待来自服务器的任何确认，该记录将立即添加到套接字缓冲区并视为已发送。在这种情况下，无法保证服务器已收到记录，并且重试配置将不会生效（因为客户端通常不会知道任何故障），为每条记录返回的偏移量始终设置为-1。
#acks = 1 这意味着leader会将记录写入其本地日志，但无需等待所有副本服务器的完全确认即可做出回应，在这种情况下，如果leader在确认记录后所在的broker立即宕机，但在将数据复制到所有的副本服务器之前，则记录将会丢失。
#acks = all 这意味着leader将等待完整的同步副本集以确认记录，这保证了只要至少一个同步副本服务器仍然存活，记录就不会丢失，这是最强有力的保证，这相当于acks = -1的设置。
#可以设置的值为：all, -1, 0, 1
spring.kafka.producer.acks=all
#如果该值大于零时，表示启用重试失败的发送次数,瞬时失败的原因可能包括：元数据信息失效、副本数量不足、超时、位移越界或未知分区等
#消息的重试不会造成消息的重复发送。
spring.kafka.producer.retries=3
#retry.backoff.ms 重试的时间间隔
#spring.

#生产者可用于缓冲等待发送到服务器的记录的内存总字节数，默认值为33554432，32MB
spring.kafka.producer.buffer-memory=33554432
#每当多个记录被发送到同一分区时，生产者将尝试将记录一起批量处理为更少的请求，batch 越小，producer的吞吐量越低
#这有助于提升客户端和服务器上的性能，此配置控制默认批量大小（以字节为单位），默认值为16384 即 16kb
spring.kafka.producer.batch-size=16384
#linger.ms设置(吞吐量和延时性能),默认是0，表示不做停留
#spring.

#max.in.flight.requests.per.connection设置(吞吐量和延时性能)
#spring.

#生产者生成的所有数据的压缩类型，此配置接受标准压缩编解码器（'gzip'，'snappy'，'lz4'），
#它还接受'uncompressed'以及'producer'，分别表示 没有压缩 以及 保留生产者设置的原始压缩编解码器，
#默认值为producer，推荐使用 lz4
spring.kafka.producer.compression-type=lz4
#ID在发出请求时传递给服务器，用于服务器端日志记录
spring.kafka.producer.client-id=
#key的Serializer类，实现类实现了接口org.apache.kafka.common.serialization.Serializer
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
#值的Serializer类，实现类实现了接口org.apache.kafka.common.serialization.Serializer
spring.kafka.producer.value-serializer=org.apache.kafka.common.serialization.StringSerializer


################################## consumer的配置参数（开始）##################################
#是否自动提交偏移量，默认是true,为避免出现重复数据和数据丢失，设置为false，然后手动提交偏移量
spring.kafka.consumer.enable-auto-commit=false
#如果'enable.auto.commit'为true，则消费者偏移自动提交给Kafka的频率（以毫秒为单位），默认值为5000。
spring.kafka.consumer.auto-commit-interval=5000ms
#心跳与消费者协调员之间的预期时间（毫秒），默认3000，这个值必须设置的小于session.timeout.ms，通常设置的值要低于session.timeout.ms的1/3。
spring.kafka.consumer.heartbeat-interval=3000ms
#当Kafka中没有初始偏移量或者服务器上不再存在当前偏移量时该怎么办，默认值为latest，表示自动将偏移重置为最新的偏移量
#可选的值为latest, earliest, none
spring.kafka.consumer.auto-offset-reset=latest
#检测消费者失败的超时，10000，这个值必须设置在broker configuration中的group.min.session.timeout.ms 与 group.max.session.timeout.ms之间。
#spring.session.timeout=10000ms

#在一次调用poll（）中返回的最大记录数。500
spring.kafka.consumer.max-poll-records=500
#max.poll.interval.ms，在使用消费者组管理时，调用poll（）之间的最大延迟。这提出了消费者在获取更多记录之前可以闲置的时间量的上界。如果在此超时到期之前未调用poll（），则认为使用者失败，并且组将重新平衡以将分区重新分配给其他成员。
#默认300000，5分钟

#ID在发出请求时传递给服务器;用于服务器端日志记录。
#spring.kafka.consumer.client-id;

#如果没有足够的数据立即满足“fetch.min.bytes”给出的要求，服务器在回答获取请求之前将阻塞的最长时间（以毫秒为单位）
#默认值为500
#spring.kafka.consumer.fetch-max-wait;

#服务器应以字节为单位返回获取请求的最小数据量，默认值为1，对应的kafka的参数为fetch.min.bytes。
#spring.kafka.consumer.fetch-min-size;

#用于标识此使用者所属的使用者组的唯一字符串。
#spring.kafka.consumer.group-id;

#密钥的反序列化器类，实现类实现了接口org.apache.kafka.common.serialization.Deserializer
spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
#值的反序列化器类，实现类实现了接口org.apache.kafka.common.serialization.Deserializer
spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer


################################## listener的配置参数（结束）##################################
#侦听器的AckMode,参见https://docs.spring.io/spring-kafka/reference/htmlsingle/#committing-offsets
#当enable.auto.commit的值设置为false时，该值会生效；为true时不会生效，listener负责ack，背后也是批量上去，手动提交offset需要的配置
#RECORD :当listener一读到消息，就提交offset
#BATCH : poll() 函数读取到的所有消息,就提交offset
#TIME : 当超过设置的ackTime ，即提交Offset
#COUNT ：当超过设置的COUNT，即提交Offset
#COUNT_TIME ：TIME和COUNT两个条件都满足，提交offset
#MANUAL ： Acknowledgment.acknowledge()即提交Offset，和Batch类似
#MANUAL_IMMEDIATE： Acknowledgment.acknowledge()被调用即提交Offset
spring.kafka.listener.ack-mode=MANUAL
#在侦听器容器中运行的线程数,多线程消费
spring.kafka.listener.concurrency=3
#轮训消费者时的超时时间，ms
spring.kafka.listener.poll-timeout=10000ms
#监控间隔时间
spring.kafka.listener.monitor-interval=10000ms
#当ackMode为“COUNT”或“COUNT_TIME”时，偏移提交之间的记录数
spring.kafka.listener.ack-count;
#当ackMode为“TIME”或“COUNT_TIME”时，偏移提交之间的时间（以毫秒为单位）
spring.kafka.listener.ack-time;

关于kafka 多线程的消费可以参考（这个只是一种方法，还存在通过添加阻塞队列的变种方式，）：

#在侦听器容器中运行的线程数,多线程消费
spring.kafka.listener.concurrency=3

可以参考这个：

kafka _ spring.kafka.listener.concurrency 的使用_yang_zzu的博客-CSDN博客_spring.kafka.listener.concurrency

yang_zzu

关注

1
点赞
踩
12

收藏

觉得还不错? 一键收藏
1
评论
kafka springboot 集成配置+测试

kafka在代码中的的使用主要是对配置文件的配置，与服务器上配置文件的配置，实际生产、消费的代码很简单。----------------------------------------------------------------------------------------------------------------------------------partition...
复制链接

扫一扫