![](https://img-blog.csdnimg.cn/20201014180756916.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
大数据/kafka/源码
文章平均质量分 85
莫言静好、
这个作者很懒,什么都没留下…
展开
-
NetworkClient分析
NetworkClient是一个网络客户端实现,它可以用于生产者发送消息,也可以用于消费者消费消息以及服务器端broker之间的通信一 核心字段Selectable selector: 用于执行网络I/OMetadataUpdater: 用于更新MetadataClusterConnectionStates connectionStates: 每一个node的连接状态InFli原创 2017-06-02 16:33:35 · 2203 阅读 · 0 评论 -
消费者Heartbeat分析
消费者会定期向GroupCoordinator发送HeartbeatRequest来确定 彼此在线,也就是说告诉GroupCoordinator我还活着,或者也判断GrooupCoordinator是否还活着 HeartbeatRequest的组成:它是由groupId,generationId,memberId.HeartbeatResponse组成:它只有一个errorCode原创 2017-06-01 17:28:10 · 3847 阅读 · 0 评论 -
Fetcher分析
Fetcher: 根据offset从服务器端获取数据,发送FetchRequest请求获取指定的消息集合,处理FetchResponse,更新消息位置 一 比较重要的字段ConsumerNetworkClient client: 负责网络通信,发送请求int minBytes:在服务器端收到FetchRequest之后,并不是立即响应,而是当可返回的消息数据积累到至少在minbyt原创 2017-06-01 17:26:28 · 6026 阅读 · 2 评论 -
ConsumerNetworkClient 分析
ConsumerNetworkClient 是对NetworkClient的一个封装,提供了额外的一些功能,首先我们看一下它有哪些属性:# NetworkClientprivate final KafkaClient client; # 等待被发送的请求队列private final Map> unsent = new HashMap # 元数据信息private原创 2017-06-01 17:24:14 · 1456 阅读 · 0 评论 -
ConsumerCoordinator分析
ConsumerCoordinator实现了AbstractCoordinator,主要负责和服务器端GroupCoordinator进行交互 一 核心字段// 心跳任务辅助类Heartbeat heartbeat;// 当前消费者所属的消费者组的group idString groupId;// 负责网络通信ConsumerNetworkClient client原创 2017-06-01 17:23:18 · 3740 阅读 · 1 评论 -
DelayedProduce分析
DelayedProduce是DelayedOperation在生产者向服务器提交消息的时候的一个延迟操作的实现一 核心字段delayMs: Long 延迟的时间produceMetadata:ProduceMetadata 为一个ProduceRequest中所有相关分区记录一些追加消息后返回结果,主要用于判断DelayedProduces是否满足执行条件replicaManag原创 2017-06-01 17:21:21 · 1185 阅读 · 0 评论 -
DelayedOperation分析
我们知道,ProducerRequest和 FetchRequest两种请求,服务端在收到这请求时候,并不是立即响应返回,可能会等待一段时间才返回。 对于ProducerRequest来说,其中acks设置为-1,表示ProducerRequest发送到leader之后,需要ISR集合中所有副本都同步该请求中消息(或者超时了)才能返回响应给客户端. ISR集合中的副本分布在不同的bro原创 2017-06-01 17:20:25 · 833 阅读 · 0 评论 -
DelayedOperationPurgatory分析
DealyedOperationPurgatory是一个辅助类,用于管理DelayedOperation和处理到期的DelayedOperation,组件图如下:一 核心字段purgatoryName:String 表示DelayedOperationPurgatory的名字timeoutTimer:Timer 表示SystemTimer,用于定时任务调度brokerI原创 2017-06-01 17:18:41 · 972 阅读 · 0 评论 -
DelayedFetch分析
DelayedFetch是FecthRequest对应的延迟操作,和DelayedProduce类似,他的流程是:来自消费者或者其他follower replica的请求到来,会交给KafkaApi的handleFetchRequest处理,然后他会调用ReplicaManager的fetchMessage方法对应Log中读取消息,并生成DelayedFetch添加到delayedFetc原创 2017-06-01 17:16:57 · 670 阅读 · 0 评论 -
SystemTimer,TimerTaskList等源码分析
一 SystemTimerKafka中定时器的实现,它在时间轮的基础上添加了执行到期任务,阻塞等待最近到期任务的功能tickMs: Long 时间格executorName: String 线程名字wheelSize: Int 时间轮startMs: Long 创建时间taskExecutor:ExecutorService 固定线程池,由此线程执行定时到期任务del原创 2017-06-01 17:15:18 · 856 阅读 · 0 评论 -
TimingWheel[时间轮]介绍
Kafka的延迟操作是一个相对独立的组件,他的主要功能是管理延迟操作,底层依赖于Kafka提供的时间轮实现。JDK本身提供的java.util.Timer也可以实现定时任务,但是如果系统请求量巨大,性能要求很高,他们底层所依赖的数据结构存取操作复杂度都是O(nlog(n))为了将时间复杂度降为o(1),一般会使用其他方式的定时任务组件,比如zookeeper的时间桶方式处理session过期,原创 2017-06-01 17:14:08 · 10973 阅读 · 1 评论 -
KafkaConsumer分析
一 重要的字段String clientId:Consumer唯一标识ConsumerCoordinator coordinator: 控制Consumer与服务器端GroupCoordinator之间的通信逻辑Fetcher fetcher: 负责从服务器端获取消息的组件,并且更新partition的offsetConsumerNetworkClient client: 负责和原创 2017-06-01 17:29:10 · 6043 阅读 · 0 评论 -
offset分析
一 提交offset提交offset的功能是由ConsumerCoordinator实现的,它会发送OffsetCommitRequest请求和接受OffsetCommitResponse响应我们先分析一下OffsetCommitRequest和OffsetCommitResponse消息体格式OffsetCommitRequest:group_id: 消费者组的id原创 2017-06-01 17:31:39 · 2840 阅读 · 0 评论 -
PartitionAssignor分析
消费者组里的leader在收到JoinGroupResponse之后,会按照其中指定的分区分配策略进行分区分配,每一个分区分配策略就是一个PartitionAssignor接口的实现,下图是其继承结构:PartitionAssignor接口中定义了Assignment和Subscription两个内部类。进行分区分配需要两方面的数据:Subscription:Metadata中原创 2017-06-01 17:33:32 · 831 阅读 · 0 评论 -
sender分析之Selector
Selector是kafka自己实现的一个NIO 异步非阻塞的网络IO操作。使用一条单独的线程管理多条网络连接上的连接、读、写操作一 核心字段java.nio.channels.Selector nioSelector: 用来监听网络I/O事件Map channels: 维护了NodeId和KafkaChannel之间的映射关系,KafkaChannel是针对SocketChannel原创 2017-06-02 16:32:35 · 536 阅读 · 0 评论 -
sender分析之创建请求
一 Sender run方法调用流程# 从Metadata获取集群元数据# 调用RecordAccumulator.ready方法,根据RecordAccumulator的缓存情况,选出可以向哪些Node发送消息,返回ReadyCheckResult对象# 如果ReadyCheckResult存在某些分区没有leader副本,则调用Metadata的requestUpdat原创 2017-06-02 16:31:28 · 717 阅读 · 0 评论 -
RecordBatch分析
RecordBatch主要用于封装MemoryRecords以及其他的一些统计类型的信息。一 核心字段int recordCount: 保存的record个数int maxRecordSize: 最大record的字节数int attempts: 尝试发送当前RecordBatch的次数long lastAttemptMs: 最后一次尝试发送的时间戳long lastApp原创 2017-06-02 16:28:07 · 3339 阅读 · 0 评论 -
RecordAccumulator分析
它主要作用就是相当于一个队列,相当于一个缓冲区,用于储蓄record到MemoryRecords,然后被发送到服务器一 核心字段int batchSize: 批量大小CompressionType compression: 压缩类型long lingerMs: 延迟时间long retryBackoffMs: 重试时间BufferPool free: ByteBuffer缓原创 2017-06-02 16:26:47 · 2246 阅读 · 0 评论 -
Metatdata分析
我们知道每一个topic有多个分区,这些分区leader副本分布在不同的broker上,分区的数量和leader副本可能是动态变化的。比如有可能增加topic的分区数以提高topic的并行处理能力或者leader所在副本宕机导致重新选举新的leader副本对外提供服务。 我们在创建ProducerRecord中的时候我们可以指定分区,也可以不指定分区,当不指定分区的时候,KafkaProd原创 2017-06-02 16:25:27 · 2114 阅读 · 0 评论 -
MemoryRecords分析
我们知道RecordBatch会拥有一个MemeoryRecords对象的引用,因为MemeoryRecords才是消息最终存放的地方 MemoryRecords表示多个消息的集合,其中封装看NIO ByteBuffer用来保存消息数据,Compressor用于对ByteBuffer中的消息进行压缩。 一 核心字段ByteBuffer buffer: 用于保存消息的NIO By原创 2017-06-02 16:24:27 · 1312 阅读 · 0 评论 -
KafkaProducer介绍
一 生产者发送消息到broker的流程1.1 ProducerIntercptor对消息进行拦截1.2 Serialzer对key和value进行序列化1.3 Partitioner对消息选择合适的分区1.4 RecordAccumulator收集消息,实现批量发送1.5 Sender从RecordAccumulator获取消息1.6 构造ClientReque转载 2017-06-02 16:23:30 · 3132 阅读 · 0 评论 -
消费者传递保证语义
Kafka服务器端并不会记录消费者的消费位置,而是由消费者自己决定如何保存其消费的offset. 0.8.2版本之前消费者会将其消费位置记录zookeeper中,在后面的新版本中,消费者为了缓解zookeeper集群的压力,在Kafka服务器端添加了一个名字是__consusmer_offsets的内部topic,简称为offset topic,他可以用来保存消费者提交的offset,当出现消费者原创 2017-06-02 16:19:53 · 762 阅读 · 0 评论 -
消费者rebalance机制分析
一 触发rebalance的时机# 有新的消费者加入# 有消费者宕机或者下线# 消费者主动退出消费者组# 消费者组订阅的topic出现分区数量变化# 消费者调用unsubscrible取消对某topic的订阅 二 rebalance过程分析2.1 查找GroupCoordinator在poll数据的时候,首先会调用ConsumerCoordinator#poll原创 2017-06-02 16:16:43 · 14731 阅读 · 0 评论 -
SubscriptionState分析
KafkaConsumer从Kafka拉取消息的时候发送的请求时FetchRequest,在其中需要指定消费者希望拉取的起始消息的offset。为了消费者快速获取这个值,KafkaConsumer使用SubscriptionState来追踪TopicPartition与offset的关系:一 SubscriptionTypeNONE: 没有状态AUTO_TOPICS:按照指原创 2017-06-01 17:35:03 · 1670 阅读 · 0 评论 -
GroupMetadataManager分析
GroupMetadataManager是负责管理GroupMetadata和对应的offset信息的组件。底层使用内部的Offset Topic,以消息的形式存储消费者组的GroupMetadata信息以及消费的每一个分区的offset,如下图所示:为了提升查询效率,GroupMetadataManager还会将消费者组的GroupMetadata信息和offset信息在内存原创 2017-06-01 17:10:59 · 3347 阅读 · 0 评论 -
GroupCoordinator分析
一 核心字段brokerId: Int 该GroupCoordinator所在的节点groupConfig: GroupConfig 记录了消费者组中consumer session过期的最小时长和最大时长offsetConfig: OffsetConfig 记录哦OffsetMetadata相关配置,比如metatdata字段允许的最大长度,Offset Topic每一个分区的副本数原创 2017-06-01 17:07:35 · 4426 阅读 · 0 评论 -
ReplicaManager分析
一个broker可能分布多个Partition的副本信息,ReplicaManager主要负责管理一个broker范围内的Partition信息,然后它还根据KafkaController发送过来的命令,然后执行这些命令,比如LeaderAndIsr和StopReplica一 ReplicaManager 数据结构假设有5个broker节点,分区数目为3,备份因子为2:bro原创 2017-05-31 17:05:13 · 2423 阅读 · 0 评论 -
MetadataCache分析
MetadataCache 是broker用来缓存当前集群中所有分区状态的组件,他需要通过KafkaController通过向集群中的broker发送UpdateMetadataRequest请求来更新MetadataCache中缓存的数据,每一个broker在收到请求后会异步更新MetadataCache中的数据 一 核心字段brokerId:Int 对应的broker的id原创 2017-05-31 17:06:51 · 1720 阅读 · 0 评论 -
Partition分析
Partition负责管理每个副本对应的Replica对象,进行Leader副本的切换,ISR列表的管理以及调用日志存储系统完成写消息等一Partition核心字段topic: String 表示topic名字partitionId:Int 表示分区号replicaManager: ReplicaManager 管理副本的一个类localBrokerId:Int 当前的brok原创 2017-05-31 17:00:46 · 2957 阅读 · 1 评论 -
replica分析
Kafka引入副本机制的目的主要是为了增加kafka集群的高可用性。Kafka实现副本机制后,每个分区可以有多个副本,并且会从其副本集合(AR)中选举出一个Leader副本,负责所有的读写请求,剩余作为follower副本,follower副本会从leader副本fetch 消息到自己的log,以防止leader挂了,其余broker上的follower可以选举为leader继续对外提供服务。一般原创 2017-05-31 16:59:08 · 679 阅读 · 0 评论 -
OffsetIndex和TimeIndex分析
为了提高查找消息的性能,为每一个日志文件添加2个索引索引文件:OffsetIndex 和 TimeIndex,她俩分别对应着磁盘上两个索引文件,与FileMessageSet共同构成一个LogSegment对象。OffsetIndex索引文件的格式: 每一个索引项为8字节,其中相对offset占用4字节,消息的物理地址(position)占用4个字节 这样就实现了相对offset原创 2017-05-31 16:57:46 · 5099 阅读 · 0 评论 -
Log分析
Log是多个LogSegment的顺序组合,形成一个逻辑上的日志,为了实现快速定位LogSegment,Log使用跳跃表SkipList对LogSegment进行管理private val segments:ConcurrentNavigableMap[java.lang.Long, LogSegment] = new ConcurrentSkipListMap[java.lang.Lon原创 2017-05-31 16:54:13 · 1198 阅读 · 0 评论 -
LogSegment分析
为了防止Log文件过大,将Log切分成多个日志文件来管理,每一个日志文件对应着一个LogSegment。在LogSegment封装了TimeIndex,OffsetIndex以及FileMessageSet对象,提供日志文件和索引文件的读写功能和其他功能 一 LogSegment的核心字段log: 用于操作对应消息日志文件的FileMessageSet对象index: 用于操作原创 2017-05-31 16:52:37 · 1753 阅读 · 0 评论 -
LogManager分析
在一个broker上的log都是通过LogManger来管理的,LogManager主要负责日志管理,包括日志创建,日志获取,日志清理,所有的读写操作都要委托的那个日志实例一 核心字段logDirs: 日志目录flushCheckMs: flush检查时间retentionCheckMs: 日志保留检查时间scheduler:KafkaScheduler调度器,用于调度线程原创 2017-05-31 16:41:06 · 8526 阅读 · 0 评论 -
FileMessageSet分析
在Kafka中使用FileMessageSet管理日志文件,它对应着磁盘上一个真正的日志文件。FileMessageSet继承了MessaeSet抽象类,MessageSet。保存的数据格式分为三部分:8字节的ofset和4字节的size以及size子集的message 数据,前两个部分被称为LogOverhead。Kafka使用Message表示消息,Message使用ByteB原创 2017-05-31 16:34:24 · 794 阅读 · 0 评论 -
ByteBufferMessageSet分析
ByteBufferMessageSet底层使用ByteBuffer保存数据,它主要提供以下三种功能:# 将Message Set按照指定的压缩类型进行压缩,此功能主要用于构建ByteBufferMessageSet对象,通过create方法完成# 提供迭代器,实现深层迭代和浅层迭代2种方式# 提供消息验证和offset分配功能 create方法private defc原创 2017-05-31 16:30:32 · 674 阅读 · 0 评论 -
ControllerBrokerRequestBatch分析
为了提高KafkaController Leader和集群其他broker的通信效率,实现批量发送请求的功能 leaderAndIsrRequestMap:保存了发往指定broker的LeaderAndIsrRequest请求相关的信息stopReplicaRequestMap: 保存了发往指定broker的StopReplicaRequest请求相关的信息updateMetada原创 2017-05-31 17:10:10 · 759 阅读 · 0 评论 -
ControllerChannelManager分析
ControllerChannelManager是用来管理KafkaController Leader和集群中其他broker之间的网络交互,其中ControllerBrokerStateInfo表示与一个broker连接的各种信息,ControllerBrokerStateInfo的一些字段:networkClient:NetworkClient 负责维护controller 和 对应b原创 2017-05-31 17:11:35 · 1046 阅读 · 0 评论 -
ControllerContext分析
ControllerContext维护了Controller使用到的上下文信息,而且还会缓存zookeeper一些数据 一 核心字段controllerChannelManager: ControllerChannelManager: 负责和kafka集群内部Server之间建立channel来进行通信shuttingDownBrokerIds:mutable.Set[Int] 正原创 2017-05-31 17:12:47 · 2132 阅读 · 0 评论 -
GroupCoordinator介绍
GroupCoodinator 和KafkaController一样,在每一个broker都会启动一个GroupCoodinator,Kafka 按照消费者组的名称将其分配给对应的GroupCoodinator进行管理;每一个GroupCoodinator只负责管理一部分消费者组,而非集群中全部的消费者组。一 功能# 记录消费者组的信息# 通过心跳消息检测消费者状态#原创 2017-06-01 17:02:43 · 1257 阅读 · 0 评论