Apache Kafka源码剖析

Apache Kafka源码剖析

暂无评价综合评分的显示会考虑用户真实性等多项因素,每部作品出现综合评分的时间不定。
8.385 评价豆瓣读书
免费试读

作品简介

《Apache Kafka源码剖析》以Kafka 0.10.0版本源码为基础,针对Kafka的架构设计到实现细节进行详细阐述。《Apache Kafka源码剖析》共5章,从Kafka的应用场景、源码环境搭建开始逐步深入,不仅介绍Kafka的核心概念,而且对Kafka生产者、消费者、服务端的源码进行深入的剖析,最后介绍Kafka常用的管理脚本实现,让读者不仅从宏观设计上了解Kafka,而且能够深入到Kafka的细节设计之中。在源码分析的过程中,还穿插了笔者工作积累的经验和对Kafka设计的理解,希望读者可以举一反三,不仅知其然,而且知其所以然。

《Apache Kafka源码剖析》旨在为读者阅读Kafka源码提供帮助和指导,让读者更加深入地了解Kafka的运行原理、设计理念,让读者在设计分布式系统时可以参考Kafka的优秀设计。《Apache Kafka源码剖析》的内容对于读者全面提升自己的技术能力有很大帮助。

徐郡明 编著。

作品目录

载入中

热门划线

  1. Kafka的网络层是采用多线程、多个Selector的设计实现的。核心类是 SocketServer,其中包含一个Acceptor用于接受并处理所有的新连接,每个Acceptor对应多个Processor线程,每个Processor线程拥有自己的Selector,3 人
  2. Apache Kafka是一种分布式的、基于发布/订阅的消息系统2 人
  3. 。当Consumer Group中的一个Consumer出现故障下线时,会通过Rebalance操作将下线Consumer负责处理的分区分配给其他Consumer继续处理;当下线Consumer重新上线加入Consumer Group时,会再进行一次Rebalance操作,重新分配分区。当然,一个COnsumer Group可以订阅很多不同的Topic,每个Consumer可以同时处理多个分区。2 人
  4. 每个Topic可以划分成多个分区(每个Topic都至少有一个分区),同一Topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时,都会被分配一个offset,它是消息在此分区中的唯一编号,Kafka通过offset保证消息在分区内的顺序,offset的顺序性不跨分区,即Kafka只保证在同一个分区内的消息是有序的2 人
  5. 分区在逻辑上对应着一个Log,当生产者将消息写入分区时,实际上是写入到了分区对应的Log中。Log是一个逻辑概念,可以对应到磁盘上的一个文件夹。Log由多个Segment组成,每个Segment对应一个日志文件和索引文件。在面对海量数据时,为避免出现超大文件,每个日志文件的大小是有限制的,当超出限制后则会创建新的Segment2 人
  6. 稀疏索引2 人
  7. 为了避免磁盘被占满,Kafka会配置相应的“保留策略”(retention policy),以实现周期性地删除陈旧的消息。2 人
  8. 可以开启Kafka的日志压缩功能,Kafka会在后台启动一个线程,定期将相同key的消息进行合并,只保留最新的value值。2 人
  9. HW标记了一个特殊的offset,当消费者处理消息的时候,只能拉取到HW之前的消息,HW之后的消息对消费者来说是不可见的。与ISR集合类似,HW也是由Leader副本管理的。当ISR集合中全部的Follower副本都拉取HW指定消息进行同步后,Leader副本会递增HW的值。Kafka官方网站将HW之前的消息的状态称为“commit”,其含义是这些消息在多个副本中同时存在2 人
  10. LEO(Log End Offset)是所有的副本都会有的一个offset标记,它指向追加到当前副本的最后一个消息的offset。2 人

喜欢这本书的人也喜欢