分布式-MQ-07 kafka高级特性及常见问题调优

已于 2023-01-06 09:28:31 修改
阅读量3.7k 收藏 2
点赞数
分类专栏： MQ 分布式 文章标签： kafka 分布式 java
于 2022-03-14 00:35:30 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/csfun1/article/details/123469697
版权

kafka高级特性及常见问题调优

一、kafka高级特性

1.1 producer发布消息机制

  • 消息写入方式
    producer采用push模式将消息发送到broker,消息将被顺序写入对应的partition中，因为顺序写的极高，保证了kafka的吞吐效率。
  • 消息路由机制
    producer发消息到时，因为在多分区中只能写入唯一分区，所以消息写入分区号是需要计算的。
    • 指定分区号，则直接使用该分区
      public ProducerRecord(String topic, Integer partition, K key, V value)
    • 未指定分区，指定key[hash取模指定分区]
      public ProducerRecord(String topic, K key, V value) 
//对当前key进行hash，取模分区数
Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions;
    • 分区号及key均未指定[RoundRobinPartitioner 轮询发送指定分区]
      public ProducerRecord(String topic, V value)
//轮询RoundRobin
int nextValue = nextValue(topic);
List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);
if (!availablePartitions.isEmpty()) {
    int part = Utils.toPositive(nextValue) % availablePartitions.size();
    return availablePartitions.get(part).partition();
} else {
    // no partitions are available, give a non-available partition
    return Utils.toPositive(nextValue) % numPartitions;
}
  • 消息写入过程
    在这里插入图片描述

1.2 Controller及partition选举机制

在这里插入图片描述

1.2.1 Controller选举机制(zk控制)

kafka集群启动时，所有broker向zookeeper发送创建**/Controller临时节点的请求，由zookeeper来保证只有1个broker节点能创建成功，该broker则当选为kafka集群中的Controller，负责管理集群分区和副本状态信息。
当controller节点的broker宕机，则zookeeper中的/Controller**临时节点消失，所有存活的broker将再次竞争创建临时节点，由zookeeper保证唯一的新broker成为Controller。

具备控制器身份的broker需要比其他普通的broker多一份职责，负责监听整个集群所有分区和副本的状态。具体细节如下：

  • 监听broker相关的变化。为Zookeeper中的/brokers/ids/节点添加BrokerChangeListener，用来处理broker增减的变化。

  • 监听topic相关的变化。为Zookeeper中的/brokers/topics节点添加TopicChangeListener，用来处理topic增减的变化；为Zookeeper中的/admin/delete_topics节点添加TopicDeletionListener，用来处理删除topic的动作。

  • 从Zookeeper中读取获取当前所有与topic、partition以及broker有关的信息并进行相应的管理。对于所有topic
    所对应的Zookeeper中的/brokers/topics/[topic]节点添加PartitionModificationsListener，用来监听topic中的分区分配变化。

  • 更新集群的元数据信息，同步到其他普通的broker节点中。

1.2.2 partition选举Leader机制
  • unclean.leader.election.enable=false 不选非Isr集合中的broker
    选择Isr集合中，第一个broker作为leader。(第一个broker最先放进ISR列表，可能是同步数据最多的副本)
  • unclean.leader.election.enable=true 如果Isr列表为空，将选择AR中可用的broker作为partition的lerder

副本进入ISR列表有两个条件：

  • 副本节点不能产生分区，必须能与zookeeper保持会话以及跟leader副本网络连通
  • 副本能复制leader上的所有写操作，并且不能落后太多。(与leader副本同步滞后的副本，是由
    replica.lag.time.max.ms 配置决定的，超过这个时间都没有跟leader同步过的一次的副本会被移出ISR列表)

1.3 Rebalance再平衡机制

1.3.1 rebalance的前提

消费者通过subscribe不指定分区消费的情况下会发生rebalance，assign这种指定分区消费的方式则不会再平衡。

1.3.2 什么情况下会发生rebalance
  • 消费者组的consumer数量发生增减(重启某台消费者服务器时势必也会造成rebalance)
  • 动态给topic增加分区
  • 消费者组订阅了更多的topic
1.3.3 Rebalance的过程
  • 第一阶段：选择组协调器(选小组长)
  • 第二阶段：加入消费组Join Group
  • 第三阶段：Sync Group
1.3.4 Rebalance分配策略

rebalance共有3中再平衡策略：range、round-robin、sticky

  • range(范围分配) 假设有10个分区，消费者组内有3个消费者，则：

    消费者0被分配：partition-0、partition-1、partition-2、partition-3

    消费者1被分配：partition-4、partition-5、partition-6

    消费者2被分配：partition-7、partition-8、partition-9

  • round-robin(轮询分配) 假设有9个分区，消费者组内有3个消费者，则：

    消费者0被分配：partition-0、partition-3、partition-6

    消费者1被分配：partition-1、partition-4、partition-7

    消费者2被分配：partition-2、partition-5、partition-8

  • sticky(稳态分配)

    sticky与round-robin的分配方案比较类似，但显著的区别时，sticky尽可能保证本次分配与上次相同。

    即原有分配方案，尽可能不变。

    sticky发生rebalance的两个原则：

    • 1）分区分配尽可能均匀
    • 2）再平衡尽可能与上次保持相同

1.4 日志存储

kafka消息存储在指定的log.dir目录下，topic对应的日志信息以Topic+分区号命名。

  • 为避免日志文件过大，kafka为.log文件指定分段大小，以避免文件过大影响读写效率

    单个日志分段大小

    log.segment.bytes: The maximum size of a single log file

    Default: 1073741824 = 1GB

  • 存储文件消息内容的文件.log文件

  • 为提高查询效率，.log文件的内容以每次4K(可配置)的offset作为索引值记录到.index文件中。存储索引offset的文件，可以快速定位消息的offset进而查找到.log真是消息内容的位置。

  • .timeindex索引文件，同样在.log文件中每次以4K发送一次来到.timeindex中。

在这里插入图片描述

1.5 分区数如何选择

bin/kafka-producer-perf-test.sh --topic my_local_topic --num-records 1000000 --record-size 1024 --throughput -1 --producer-props bootstrap.server=192.168.149.128:9092 acks=1

二、kafka常见问题及调优

2.1 kafka启动慢及消费者重新订阅慢

2.1.1 kafka重启慢问题
  • kafka-server-start.sh 修改默认初始化堆内存及最大堆内存
#原值
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
    export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G"
fi
#根据物理内存情况32G内存可置为16G
export KAFKA_HEAP_OPTS="‐Xmx16G ‐Xms16G ‐Xmn10G ‐XX:MetaspaceSize=256M ‐XX:+UseG1GC ‐XX:MaxGCPauseMillis=50 ‐XX:G1He apRegionSize=16M"
#最大STW50ms,使用G1垃圾回收器,单元格大小16M，元空间256M，初始化内存16G.最大内存16G,年轻代10G
  • 修改启动实例或关闭实例时梳理日志文件线程数
    在启动kafka时，需要后台线程将log.dir目录中topic的分区segment log读取到内核空间，当partition分区中的数据很多(或许日志删除hour过大，保留日志量很大)，后台默认的num.recovery.threads.per.data=1将忙不过来，可以试着将该线程数放大
2.1.2 kafka消费者重启后重新订阅很慢

当有消费者宕机或重启，这是生产中非常常见的状态，将导致coordinator认为分区与消费者的对应关系发生变化，需要重新平衡消费者于分区关系。

  • session.timeout.ms 根据服务需求，可大可小，当该值更小时，更容易触发rebalance，当该值更大时，可能消费者已宕机而broker未发现。
  • max.poll.interval.ms 如果消费者处理消息的时间，超过该设置值，将视为消费者处理能力差，或被踢出ConsumerGroup
  • rebalance策略，可以选择sticky以减少已有稳定分区的重新分配。

2.2 kafka消息顺序性分析

能否保证所有消息有序？不能，只能保证分区内有序(局部有序)

2.3 kafka如何保证不丢消息

1、kafka能否保证消息不丢? 不能 why？什么情况下会丢消息？
2、消息丢失及处理(消息保障)
3、消费确认机制等

2.4 kafka能否保证消息幂等性

是否支持消息幂等？
消息生产端可调整配置支持幂等，消费者端需要业务自行实现(服务端需要有异常补偿，基于Corgi准实时补偿 + 异常表补偿等)

2.4 kafka高性能的原因

  • 磁盘顺序读写
    kafka消息不能修改及不会在文件中间删除内容，保证了每次写内容都是在文件末尾的追加，从而保证写文件的顺序行；每次读内容时有.index文件的索引查找，及.log文件的分段，又能极大结合磁道读取内容的顺序行，从而提高读取效率。

  • 数据传输零拷贝

  • 读写数据的批量batch处理及压缩传输

三、kafka集群的CAP问题

什么是CAP，当分布式系统同时涉及读写时，需要保证一致性(Consistence)、可用性(Availabiliy)、分区容错性(Partition Tolerance)的平衡。成熟的分布式系统一般是在一致性、可用性方面找到平衡点，依据服务的需求设计出更贴近使用的CAP系统。

当强调一致性时，需保证所有的ISR必须完成数据的同步才算完成生产者数据的写入，而此时从可用性来看，只要Leader存活，是可以保证可用性的。除非Leader宕机，Follower才需要从ISR中靠前的broker选择接替Leader，短时间出现不可用。
当强调可用性时，也可以通过保证最终一致性(如ack=-1，> nums/2个副本完成数据同步)，使集群其他节点最终数据一致性，从而实现可用性和一致性得以兼得。

3.1 一致性

分布式系统一般存在多个副本，Leader副本和多个Follower副本，如果系统能够保证线性一致性当然极好，但如果不能保证线性一致，进而保证顺序一致性也能满足需要。

  • 什么是线性一致性？
    线性一致性(Linearizability)，也称原子一致性(atomic consistency)、强一致性(strong consistency)。从字面意思就可以理解，多个副本之间的同步状态像是集群只有1个副本。所有的操作都是原子的，当针对leader进行更新时，多个follower副本的状态也需要同步更新完成才能让该条更新结果对客户端可见。
    显而易见，线性一致性对消费者客户端是十分友好的，我和朋友小张分别拿着手机看NBA总决赛最后10s，当小张看到Ray Allen三分绝杀比赛结束时，我看到的却还是比分持平，等待发球，我的内心是无法接收的。
    但做到线性一致性是需要付出更多代价的，比如在kafka中消息生产者可以将 ACKS=ALL或-1，同时 min.insync.replicas(最少同步副本数量)设置为AR(所有副本数)，此时生产者发送消息必须所有副本写入完成才算成功。但这毫无疑问将导致集群可用性的降低。
  • 什么是顺序一致性(Sequence Consistency)
    假设分布式系统中，X的原值为0，ClientA对X的值修改为1，那么因为网络的延迟等原因，虽然B0、C1的执行事件与A0存在先后顺序，但在服务端真正执行的顺序却是不确定的。所以B0、C1由于与A0存在并行关系，所以B0、C1得到X=0或X=1都是可能的。
    顺序一致性，需要保证的就是：当一个Client从服务端得到最新的结果后，后续其他Client得到的结果也必须是最新的。既：当B0如果读到X=1，那么C1也只能得到X=1。这样就保证了有序的一致性。
    在这里插入图片描述
    我们从kafka的角度再详细的看读写一致性问题。
3.1.1 数据写一致性控制

更新的数据只能由Leader写入，然后同步超过半数以上副本算写入成功，其他未立即同步的副本会在后续完成写入，可得数据写入是线性一致、强一致的。

Acks=-1 或Acks=All
min.insync.replicas >= num/2+num%2 (保证同步副本超过半数)
3.1.2 数据读一致性控制

kafka官网中介绍，Consumer客户端连接不同的Partition分区，虽然有了HW高水位的存在保证消费者能读取到的消息水位是相同的，但由于不同分区的log-end-offset偏移量是不同的（显然Leader的最大偏移量是最大的），当有ClientA、B分别读取Follower1和Follower2，此时X=3尚未同步到Follower2。
在这里插入图片描述
如果此时出现Rebalance，则可能出现ClientA、B再平衡到Follower2、Follower1，但由于zookeeper的存在，客户端和Zookeeper分别维护了zxid和lastZxid值(下面细讲)，当客户端的zxid>zookeeper维护节点的lastZxid时，也就是ClientA连接到Follower2,但是Follower的lastZxid尚未更新到3，此时如果连接将导致消息丢失。所以zk将保证重连时ClientA不会连接到Follower2。
在这里插入图片描述
上面两幅图的动态过程，大致讲解了zk在保证消息顺序一致性所做的事。那么什么是zxid?

  • zxid
    就是事务id，由64位二进制数组成，是为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。
    其中高32位为epoch值(eopch值主要用来区分leader的版本，当前leader宕机选出下个leader时则需要epoch+1，以此区别leader朝代的更迭)，低32位则是当前leader通知下依次递增的计数号码。
    在这里插入图片描述
    看到这个zxid有没有让你联想到什么？我的感受是：
  • 从外形上看类似java对象头Object Header中Markword，甚至在偏向锁中也有epoch值概念。
  • 从高低位搭配上看，酷似ReentrantReadWriteLock的sync内部类中用高16位表示共享锁状态，低16位表示独占写锁状态。

3.2 可用性

可用性指的是在集群中，一部分节点故障后，集群整体是否还能响应客户端的读写请求。
提到可用性，势必会和一致性做兼容。

  • WARO(Write All Read One)
    所有副本写入完成才算成功，读取数据只从一个节点读。当Write All时保证了原子性、强一致性，所以读取节点时无疑会读取最新数据。但此时可用性并不高。
  • Quorum(NWR) 权衡一定的一致性和可用性。
    • N：总的副本数
    • W：更新数据需要保证完成写入的节点数
    • R：读取数据时，需要读取的副本节点数
  • N=5，W=5，R=1(追求强一致性，需要保证所有节点均写入成功，读取时数据是最新的)
  • N=5，W=3，R=3(写入时需要保证超过半数节点写入成功，读取超过半数节点的数据，未完成同步的节点可以通过zxid比较事物号大小，保证读取时顺序一致性)
  • N=5，W=3，R=1(当追求可用性更高时，该种配置可以在存在2个节点故障时仍然可用，且可以保证顺序一致性。)

3.3 分区扩展性

由于kafka是分布式部署在不同机器上的，并且由于网络不可靠，Leader也可能存在网络异常的场景，当Controller认为当前Leader不可用，broker将会再次选举(broker首先会推选自己为leader，再经由与其他broker投票生成新的leader)，若老的leader恢复后，新leader也生成了，将出现新旧Leader并存的问题。此时zookeeper将再次通过上述的epoch值比较，控制版本保证数据一致性。

4.2.4 Kafka高级特性解析(物理存储、稳定性:事物，控制器，可靠性，一致性，_consumer_offsets、延时队列、自定义重试队列)
weixin_47134119的博客
03-23 1032
Kafka高级特性解析 文章目录Kafka高级特性解析2.5 物理存储2.5.1 日志存储概述 2.5 物理存储 2.5.1 日志存储概述 Kafka 消息是以主题为单位进行归类，各个主题之间是彼此独立的，互不影响。 每个主题又可以分为一个或多个分区。 每个分区各自存在一个记录消息数据的日志文件。 图中，创建了一个 tp_demo_01 主题，其存在6个 Parition，对应的每个Parition下存在一个[Topic-Parition] 命名的消息日志文件。在理想情况下，数据流量分摊到各个 Pa
Kafka--Kafka日志索引详解以及生产常见问题分析与总结
weixin_43874650的博客
12-20 2195
​ Kafka的设计重点是在网络不稳定，服务也不稳定的复杂分布式环境下，如何保持高性能，高可用，高可扩展的三高架构。在这方面，Kafka的设计是很复杂也很完善的，是业内公认的老大哥。因此网上的解读文章也是最多的。但是这些解读的文章如果没有一条主线串起来，那永远都只是一些零散的，过目既忘的东西。​ 在这几期的课程中，一直在尝试以可见的方式去深入理解Kafka的各种主要设计思想。内容非常多，节奏也非常紧凑，但是梳理出了客户端、Zookeeper数据、Log日志三条可以看得见的数据主线。
kafka高级特性
拒绝熬夜啊的博客
06-29 578
kafka高级特性
Kafka高级特性
weixin_38910645的博客
07-08 737
幂等设计 消息语义 At most once：消息可能会丢失，但不会重复。 At least once：消息不会丢失，但有可能重复。 Exactly once：正好一次。消息不会重复也不会丢失。 在0.11.0.0之前，如果生产者未能收到已提交消息的响应，除了重新发送消息外别无选择，但提供了至少一次的语义保证。即原始请求实际上已经成功，但是遇上某些意外情况，则会在重新发送时将消息再次写入日志。 如：网络抖动、超时等问题，导致Producer没有收到Broker返回的税局Ack，则Producer会继续重试
Kafka线上常见问题及性能优化
qq_44528357的博客
11-02 493
kafka常见问题优化
【分布式学习】消息中间件（MQ）学习：kafka
午后阳光
08-23 3508
1，概念 Kafka是一种高吞吐量的分布式发布订阅消息系统，是观察者模式的一种实现。 1）特性 通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。 高吞吐量 ：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。 支持通过Kafka服务器和消费机集群来分区消息。 支持Hadoop并行数据加载。 Broker Kafka集群包含一个或............
kafka --- 系列二（kafka最全面试题）
下课铃声~的博客
11-16 1633
目录 1、请说明什么是Apache Kafka? 2、说说Kafka的使用场景？ 3、使用Kafka有什么优点和缺点？ 4、为什么说Kafka性能很好，体现在哪里？ 5、请说明什么是传统的消息传递方法? 6、请说明Kafka相对传统技术有什么优势? 7、解释Kafka的Zookeeper是什么?我们可以在没有Zookeeper的情况下使用Kafka吗? 8、解释Kafka的用...
分布式架构mq
最新发布
03-31
接下来，我应该考虑常见的MQ实现方案，比如Kafka、RabbitMQ、ActiveMQ、RocketMQ等。每个系统有不同的特点，比如Kafka适合高吞吐量场景，RabbitMQ有灵活的路由机制，而RocketMQ在事务消息方面表现不错。需要分别介绍...
Kafka 高级特性
码农郭大大的博客
05-29 1953
Kafka消费者默认对于未订阅的topic的offset的时候，也就是系统并没有存储该消费者的消费分区的记录信息，默认Kafka消费者的默认消费策略：latest消费者在消费数据的时候默认会定期自动提交偏移量,用户可以通过以下两个参数配置： enable.auto.commit = true 默认auto.commit.interval.ms = 5000 默认。
大数据-66 Kafka 高级特性 分区Partition 副本因子Replication Factor replicas动态修改 线上动态修改副本数
永远好奇，无限进步！
08-05 3516
上节完成了Kafka宕机恢复后，Leader不会重新分配，需要我们用脚本重新恢复。本节对Kafka集群的副本因子进行修改，现实业务中我们会遇到：当Kafka集群中有一个节点宕机了，比如Broker0、Broker1中，Broker1宕机了，此时由于我们配置了副本数为2，Kafka集群正常工作，提供生产和消费能力。但是当我们修好Broker1之后，恢复宕机之后，发现Leader都是Broker0，不会再平衡到Broker1上，所以我们需要用脚本来让Kafka集群进行自动再平衡。
kafka-高性能设计详解（页缓存、零拷贝等六大特性）
A的博客
06-27 1903
为了提升对文件的读写效率，Linux 内核会以页大小（4KB）为单位，将文件划分为多数据块。当用户对文件中的某个数据块进行读写操作时，内核首先会申请一个内存页（称为。
Kafka的几个面试重点（高级特性）
MCY的博客
12-24 1250
Kafka面试常客 消费组 用来组织管理消费者一个特性，同组负载均衡，不同组广播 同组负载均衡 相同的消费组的消费者实例运行多个 // 运行多个消费者服务实例 prop.put(ConsumerConfig.GROUP_ID_CONFIG, "g1"); // 消费组 不同组广播 同组负载均衡 结论： 同组 负载均衡，同组一个消费者负责一个或多个分区的数据处理，分区到消费者是一个平行关系...
kafka之十 高级应用
weixin_42672777的博客
01-04 445
高级应用 命令行工具 消费组管理 查看消费组 bin/kafka-consumer-groups.sh --bootstrap-server localhost:9892 --list 查看消费组详情 bin/kafka-consumer-groups.sh --bootstrap-server localhost:9890 --describe --group groupName ...
kafka线上问题优化：消息丢失、重复消费、消息积压、延时队列、顺序消费
叶新东老师的博客
09-14 2319
1、防止消息丢失 发送方 将ack设为1或者-1/all，可以防止消息丢失；如果要做到99.99999%防止丢失，把ack设为all,把min.insync.replicas设为你的集群分区副本的数量即可； # 表示要将消息刷入集群环境的2个副本中后，才会返回ack； min.insync.replicas=2 消费方 把自动提交改为手动提交，也就是说当我消费成功后才会进行提交。如果设为自动提交的话，那么不管消费者有没有消费成功都会提交给broker，一旦提交上去，offset就会 + 1，表示已经消费成
实战：kafka删除Topic常见异常排查思路及解决方案
kafka_zsxq的博客
12-03 1883
有人报案 最近技术群里面有几个同学碰到了 删除Topic的问题, 怎么样也删除不掉,然后我协助排查之后,就做个记录,写篇文章,大家在碰到这类型的问题的时候应该怎么去排查 收集线索 报not retrying deletion 异常 版本:kafka_2.11-2.0.0 删除前在执行重分配,但是失败了,强制停止数据迁移,手动删除了节点/admin/reassign_partitions 再次重新删除提示异常Topic test is already marked for deletio
Kafka三、Kafka生产问题总结以及性能优化
东风麦芽糖
01-10 512
Kafka可视化管理工具kafka-manager kfuka线上问题及优化 kafka的事务
第三章 Kafka生产问题总结及性能优化实践
JavaAlenboy
02-20 944
kafka 是 scala 语言开发，运行在 JVM 上，需要对 JVM 参数合理设置，参看 JVM 调优专题修改这种大内存的情况一般都要用 G1 垃圾收集器，因为年轻代内存比较大，用 G1 可以设置 GC 最大停顿时间，不至于一次 minor gc 就花费太长时间，当然，因为像 kafka，rocketmq，es 这些中间件，写数据到磁盘会用到操作系统的 page cache，所以 JVM 内存不宜分配过大，需要给操作系统的缓存留出几个 G。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

旧梦昂志

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值