今天这篇文章,给大家分享一下最近看kafka源码时候,困扰我几天的疑惑,供大家一起思考讨论,确定一下它是不是一个 Bug 欢迎留言一起探讨！
PS: 当某个Topic的分区少于指定的分区数时候,他会抛出异常;但是不会影响其他Topic正常进行;
“ 为什么Kafka在RangeAssigor、RoundRobinAssignor的基础上，又新增了PartitionAssignor，它解决了什么问题？”
我们知道kafka的主题中数据数据是按照分区的概念来的，一个主题可能分配了多个分区，每个分区配置了复制系数，为了可用性，在多个broker中进行复制，一个分区在多个broker中选举出一个副本首领，消费者只访问这个分区副本首领，这些在本章节不重要，本章节阐述一个消费者如何选定一个主题中多个分区中的一个分区，和kafka的分区分配策略核心源码解析。
一，Kafka消费模式 从kafka消费消息，kafka客户端提供两种模式: 分区消费，分组消费。 分区消费对应的就是我们的DirectKafkaInputDStream 分组消费对应的就是我们的KafkaInputDStream 消费者数目跟分区数目的关系: 1)，一个消费者可以消费一个到全部分区数据 2)，分组消费，同一个分组内所有消费者消费一份完整的数据，此时一个分区数据只能被一个消费者消费，而一个消费者可以消费多个分区数据 3)，同一个消费组内，消费者数目大于分区数目后，消费者会有空余=分区数-消费
2)，分组消费，同一个分组内所有消费者消费一份完整的数据，此时一个分区数据只能被一个消费者消费，而一个消费者可以消费多个分区数据
支持正则表达式匹配Topic来进行删除,只需要将topic 用双引号包裹起来 例如: 删除以create_topic_byhand_zk为开头的topic;
从源码中得知, 会把我们指定的规则进行了包装,注意它并没有去检查你指定的Broker是否存在;
>bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 --partitions 2
使用起来还是很简单的，不过如果想要用好 consumer， 可能你还需要了解以下这些东西：
前段时间收到某个 Kafka 集群的生产客户端反馈发送消息耗时很高，于是花了一段时间去排查这个问题，最后该集群进行扩容，由于某些主题的当前数据量实在太大，在对这些主题迁移过程中花费了很长一段时间，不过这个过程还算顺利，因为在迁移过程中也做足了各方面的调研，包括分区重平衡过程中对客户端的影响，以及对整个集群的性能影响等，特此将这个过程总结一下，也为双十一打了一剂强心剂。
最近在排查一个sparkstreaming在操作kafka时，rebalance触发了一个异常引起任务失败，而组内小伙伴对消费者组的一些基本知识不是很了解，所以抽了些时间进行相关原理的整理。本文就来聊聊相关内容。
场景描述：Kafka使用分区将topic的消息打散到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。Kafka的producer和consumer都可以多线程地并行操作，而每个线程处理的是一个分区的数据。因此分区实际上是调优Kafka并行度的最小单元。对于producer而言，它实际上是用多个线程并发地向不同分区所在的broker发起Socket连接同时给这些分区发送消息；而consumer，同一个消费组内的所有consumer线程都被指定topic的某一个分区进行消费。
https://help.aliyun.com/document_detail/266782.html
为了让读者能与小编在后续的问题分析中有更好的共鸣，小编先与各位读者朋友对齐一下我们 Kafka 集群的部署架构及服务接入 Kafka 集群的流程。
push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快的速度传递消息，但是这样容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式可以根据consumer的消费能力以适当的速率消费消息。
需要注意的是–zookeeper后面接的是kafka的zk配置, 假如你配置的是localhost:2181/kafka 带命名空间的这种,不要漏掉了
在上一篇 kafka topic消息分配partition规则（Java源码) 我们对生产者产生的消息分配partition规则进行了分析，那么本章我们来看看消费者是怎么样分配partition的。
已知，Kafka 集群中有两个 kafka broker ，id 分别为 200、201 。
主题和分区是Kafka的两个核心概念，主题作为消息的归类，可以再细分为一个或者多个分区，分区可以看作是对消息的二次归类。分区的划分不仅可以为Kafka提供了可伸缩性，水平扩展能力，还可以通过副本机制来为Kafka提供数据冗余以提高数据的可靠性，为了做到均匀分布，通常partition的数量通常是BrokerServer数量的整数倍。
生产环境的kafka集群扩容，是一个比较常见的需求和操作。然而kafka在新增节点后并不会像elasticsearch那样感知到新节点加入后，自动将数据reblance到整个新集群中，因此这个过程需要我们手动分配。
在 Kafka 中，每当消费者组内的消费者查找不到所记录的消费位移或发生位移越界时，就会根据消费者客户端参数 auto.offset.reset 的配置来决定从何处开始进行消费，这个参数的默认值为 “latest” 。
前几天有个群友问我: kafka如何修改优先副本？ 他们有个需求是, 想指定某个分区中的其中一个副本为Leader
众所周知，Apache Kafka是基于生产者和消费者模型作为开源的分布式发布订阅消息系统（当然，目前Kafka定位于an open-source distributed event streaming platform），由Scala和Java编写。
搭建高吞吐量 Kafka 分布式发布订阅消息 集群 简介 Kafka 是一种高吞吐的分布式发布订阅消息系统，能够替代传统的消息队列用于解耦合数据处理，缓存未处理消息等，同时具有更高的吞吐率，支持分区、多副本、冗余，因此被广泛用于大规模消息数据处理应用。Kafka 支持Java 及多种其它语言客户端，可与Hadoop、Storm、Spark等其它大数据工具结合使用。 环境 Zookeeper集群: 192.168.252.121:2181,192.168.252.122:2181,192.168.252.12
kafka创建Topic的时候 什么时候在Broker磁盘上创建的日志文件? 当Controller监听zk节点/brokers/topics变更之后,将新增的Topic 解析好的分区状态流转
在 kafka 中，topic 是一个存储消息的逻辑概念，可以认为是一个消息集合。每条消息发送到 kafka 集群的消息都有一个类别。物理上来说，不同的 topic 的消息是分开存储的，每个 topic 可以有多个生产者向它发送消息，也可以有多个消费者去消费其中的消息。
从【kafka源码】kafka分区副本的分配规则 中我们已经知道了,如何分区副本是如何进行分配的 那么当我们想要批量进行副本扩缩的时候, 如果按照之前 --generate的重新计算分配方式来做的话, 那么这个数据迁移量是非常大的; 很有可能大部分的副本都有变动(牵一发而动全身) 那么我们有没有什么方式能够尽量减少这种变动吗, 根据这个目标，我们本篇文章就好好思考一下设计方案
KnowStreaming 是滴滴开源的Kafka运维管控平台, 有兴趣一起参与参与开发的同学,可以联系我呀 。
(后续的视频会在 公众号[全套视频首发]、CSDN、B站等各平台同名号[石臻臻的杂货铺]上上传 )
其中Zookeeper是Kafka用来负责元数据的管理、控制器的选举。Producer将消息发送到Broker，Broker负责将消息存储到磁盘中，而Consumer负责从Broker订阅并消费消息。
配置启动类--zookeeper xxxx:2181 --topics-to-move-json-file config/move-json-file.json --broker-list "0,1,2,3" --generate
Apache Kafka 是一个分布式的流处理平台（分布式的基于发布/订阅模式的消息队列【Message Queue】）。
kafka中的topic可以细分为不同的partition，一个topic可以将消息存放在不同的partition中。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
这种消费方式由broker主动推送消息给消费者，消费者被动接收消息。缺点: consumer 消费能力不强的情况下可能出现拒绝服务、以及因网络问问题产生的网络拥塞的情况;
上篇文章说了，kafka可以通过实现partitioner自定义分区，producer拦截器，拦截器是在producer发送消息之后，回调之前调用，里面主要重写两个方法，一个是onSend，可以重新定义发送的消息，一个是在回调之前调用，onAcknowledgement在回调之前调用，可以记录发送成功或者失败的消息数量。无消息丢失配置，首先保证一个问题，消息不会丢失，要acks设置为all或者-1，这样send回调才会生效，这时候还会存在一个问题，当网络瞬时故障时候，会出现乱序发送，乱序的出现是因为retries重试，这时候必须只能在同一时刻在同一个broker只能发送一次，max.in.flight.request.per.connection。还有参数replication.factory三备份原则，Min.insync.replica至少写入多少副本。
一，流式平台介绍 1，一般来说一个通用的流平台必须具备以下三个重要的能力： 1),能够允许你订阅和发布流式消息。在这方面，它类似于消息队列或企业消息系统。 2),它允许您以容错方式存储流式消息。 3),他可以允许你实时处理流式消息。 2，Kafka常被用于两大类应用程序： 1),构建可在系统或应用程序之间可靠获取数据的实时流数据流水线 2),构建对数据流进行变换处理的实时流应用程序 3，首先介绍一些基本概念： 1),kafka是以集群的方式运行，可以有一个或者多个Broker server。 2),kafk
Rebalance(再均衡)机制指的是：将一个Topic下的多个队列(或称之为分区)，在同一个消费者组(consumer group)下的多个消费者实例(consumer instance)之间进行重新分配。
https://github.com/841809077/hdpproject/blob/master/src/main/java/com/hdp/project/kafka/consumer/KafkaConsumerAnalysis.java
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
