idealemail的博客

Kafka网络层及Api层结构图,欢迎讨论

KafkaConsumer主流程图,欢迎讨论

kafka-producermatadata类图

kafka生产者主流程图,欢迎讨论

GroupCoordinator负责对接上层KafkaApis的各种handle请求,对下封装了GroupMetadataManager的各个方法重点分析rebalance的两个阶段JoinRequest和SyncRequest一.JoinRequest1.最上层由KafkaApis的handleJoinGroupRequest方法发起case ApiKeys.JOIN_GROUP => handleJoinGroupRequest(request)def handleJoin.

__consumer_offsets成为位移主题,有以下知识点1.由kafka自己创建,默认50个分区,每个分区3个副本2.例如partition-1的leader为broker 4. isr为 4,6,8 ar为4,6,83.一个group,计算group的hash值,对50取余得出0-49的值,如果是1则这个group的group coordinator在partition-1的leader所在的broker上4.__consumer_offsets保存了组元数据和offset元数.

组管理器是管理多个GroupMetadata一.核心字段其中最核心的就是groupMetadataCache ,底层就是一个ConcurrentHashMap,消费组名,对应GroupMetadataclass GroupMetadataManager(brokerId: Int, interBrokerProtocolVersion: ApiVersion, config: Offse

kafka服务端消费组管理器的源码位于kafka.coordinator.group包下分为四个部分分析1.元数据 MemberMetadata.scala & GroupMetadata.scala2.元数据管理 GroupMetadataManager.scala3.__consumer_offsets分析4.组管理器 GroupCoordinator第一部分:MemberMetadata.scala & GroupMetadata.scala一.Member

一.topic级别的配置 配置项 可选项 默认值 broker参数 说明 cleanup.policy delete,compact delete log.cleanup.policy 日志策略,delete或者compact delete.retention.ms 数字 86400000 (1 day) log.cleaner.delete.retention.ms 日志策略为compact.

fetch.min.bytes--1fetch.max.bytes--52428800 (50 mebibytes)heartbeat.interval.ms--3000 (3 seconds) 和consumer coordinator之间的预跳时间(The value must be set lower thansession.timeout.ms, but typically should be set no higher than 1/3 of that value)max.parti.

一.producerbuffer.memory--33554432=32mretries--2147483647:可能导致顺序不对batch.size--16384 字节=16kconnections.max.idle.ms--540000 (9 minutes)delivery.timeout.ms--120000 (2 minutes) 此值应该大于request.timeout.ms+linger.ms,一个消息的最大投递时间request.timeout.ms--30...

基础配置listenersdefault.replication.factor--1advertised.listenersauto.create.topics.enablemessage.max.bytesbroker.rackbroker.id.generation.enablenum.partitions--1reserved.broker.max.idsecurity.inter.broker.protocol--PLAINTEXTcreate.topic

kafka通过副本机制保证数据的可靠性一.副本机制的概念如下:1.一个partition有多个副本replication,一般是3个或5个2.每个副本位于不通的broker3.每个副本集合里有一个leader副本,其余的为follower副本,只有leader副本才接受读写请求,follower副本只做同步数据4.所有的副本组成的集合称为AR,所有同步副本成为ISR(In-Sync Replication),所有非同步副本成为OSR,OSR+ISR=AR5.如果leader副本不可用

分区再均衡分区再均衡在服务端由GroupCoordinator负责,在客户端由ConsumerCoordinator负责有以下集中情况会触发再均衡1.新消费者加入2.消费者被动下线3.消费者主动下线4.消费组对应的GroupCoordinator节点发生变更5.消费组订阅的主题分区数量发生变化当发生分区再均衡时有以下几个阶段第一阶段 FIND_COORDINATOR第二阶段JOIN_GROUP第三阶段SYNC_GROUP第四阶段HEARTBE...

分区分配策略一个消费组内有多个消费者,一个topic有多个patition,所以消费者和partition是多对多的关系,kafka默认有以下三种分区分配策略1.RangeAssignor按照消费者总数和分区总数整除得到一个跨度,然后将分区按照跨度进行平均分配,当订阅多个topic时,每个topic分别计算例如消费者c0,c1topic有2个,分区分别为:t0p0,t0p1,t0p2t1p0,t1p1,t1p2分配过程:(1)分配topic:t0c0: t0p0,t0

1.kafka中有多个broker,其中一个broker会被选举为controller2.选举的方式是所有broker在zookeeper创建/controller临时节点,创建成功的broker成为controllercontroller的数据如下{"version":1,"brokerid":2,"timestamp":"1604740076796"}同时会创建controller_epoch节点,节点数据是一个整数,记录选举轮次3.controller的职责监听分区相关的变化

kafka的topic-partition文件夹下有多个文件包括 .log .idex .timeindex 这三个核心文件 还包括 .deleted .cleaned .swap 等临时文件 还可能有 .snapshot .txnindex leader-epoch-checkpoint 等文件.log文件是kafka的数据文件

1.分区优先副本选举当分区的leader分配不均衡时,例如3个broker,0,1,2,有一个topic有3个分区p0,p1,p2,当所有的分区leader都在一个broker上时,就是分区分配不均衡./kafka-preferred-replica-election.sh --zookeeper 127.0.0.1:2181/kafka-plaintext-poc结果太多,不展示可以通过指定topic和分区的方式,对特定topic和分区进行优先副本选举2.分区重分配当有broker

一.概念kafka的topic是一个逻辑概念,一个topic对应多个分区,一个分区对应多个副本,一个副本对应一台broker上的一个文件夹,例如topic为test的第0个分区的一个副本的文件夹名为test-1,每个分区在一个broker上只能有一个副本,所以所有副本的文件夹名是相同的,只是在不同的broker上每个副本的文件夹内有以下文件:00000000000000000974.index //索引文件00000000000000000974.snapshot //快照文件0000..

一.创建配置,最小化配置如下var props = new Properties();props.setProperty(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "127.0.0.1:9092");//broker地址props.setProperty(ConsumerConfig.GROUP_ID_CONFIG, "group_id_1");//group idprops.setProperty(ConsumerConfig.KEY_DESERIALI

一.必须按配置Properties props = new Properties();props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "127.0.0.19092");//kafka broker地址props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");//key序列...

kafka的复制机制不是完全的同步或异步,完全的同步需要所有的副本成功写入才能返回,会极大地影响性能,完全的异步,只要写入leader副本即可,这样如果leader宕机,会丢消息,kafka采取了独特的ISR机制权衡数据的可靠性和性能.1.日志文件逻辑格式0是日志起始offset,HW是消费者可以拉取到的最大的offset,leo是新写入的下一条offset2.所有的副本组成的集合是AR(Assigned Replicas)3.与Leader保持一定程度同步的副本集合是ISR(In-Sy

一.问题现象:go 客户端简单consumer 模式可以消费go客户端consumer group模式不可消费,客户端运行到一下代码卡住<-consumer.ready // consumer一直没有readyfmt.Println("Sarama consumer up and running!...")java客户端不可消费客户端每次poll不到数据,没有日志输出ConsumerRecords<String, String> records = consu