1.1 应用场景
日志聚合、数据监控、流处理等等
1.2 高吞吐率实现
Kafka将消息写入到低速大容量的硬盘，但仍然保持了超高的吞吐率，是因为：
- 顺序读写：在segment中采用顺序写
- 零拷贝：生产者、消费者对Kafka中的消息操作采用零拷贝实现
- 批量发送：Kafka允许使用批量消息发送模式
- 消息压缩：Kafka支持对消息集合进行压缩
1.3 基本术语
1.3.1 Topic
1.3.2 Partition
分区，一个topic下的消息存在于若干分区中，一个分区只能由一组消费者中的一个消费，类似于RocketMQ中的queue
1.3.3 Segment
段，一个partition分成了若干segment文件，每个segment文件的最大大小相等，顺序写。segment文件名代表当前segment之前有多少条消息（每个partition单独算，其第一个segment全24个0）
segment文件由两部分组成，.index文件和.log文件，这两名字一样，后缀不同。
index文件存索引，每条数据两部分组成，第一部分代表在这个segment中相对位置，比如第一个数据为0，第二部分为数据在log文件中存储的物理位置
log文件存数据，每条数据三部分组成，第一部分为该消息在partition中的位置，第二部分是消息的大小，第三部分为消息的具体内容
消息查找的过程：1、根据消息编号二分法找到index文件 2、计算相对位置找到index中对应数据记录 3、根据数据的第二部分去log文件找消息
1.3.4 Broker
partition的数量一般设置为是broker的整数倍，即一个Topic在每个broker中平均存在一个或多个partition
1.3.5 Producer
将消息发送到Topic下的对应partition中
1.3.6 Consumer Group
一组消费者组成一个消费者组，这组消费者平均消费partition
1.3.7 Replicas of partition
每个Partition会有备份，备份不会处理请求。备份称为Partition Follower，主机称为Partition Leader
1.3.8 Partition Leader
1.3.9 Partition Follower
1.3.10 ISR
ISR，需要同步的Follower
OSR，同步失败的Follower，一旦同步失败，从ISR中移到OSR中
AR，所有的Follower，ISR+OSR
1.3.11 offset
偏移量，每个partition单独计算，指消息在partition中的名次
1.3.12 offset commit
消费者消费完消息后，会将已消费消息的offset同步给broker。
1.3.13 Rebalance
当消费者或者partition数量发生变化时，会触发rebalance，重新调整每个消费者消费partition的关系，在此期间，消费者无法消费消息。
1.3.14 __consumer_offsets
之前由ZooKeeper来维护消费进度，但之后由broker自己维护。消费者提交的offset被封装成特殊的消息，key是消费者组Id，写入到由系统创建的、名称为__consumer_offset的特殊主题中，该主题下有50个分区，由 Math.abs(groupID.hashCode())%50 计算投放的分区
1.3.15 Broker Controller
集群中有多个broker，会有一个被选举为controller，负责管理Partition和其副本的管理，包括Leader的选举，默认选举规则是谁先创建，谁当Leader。还有比如指挥Leader从OSR中检测并恢复follower到ISR
1.3.16 Zookeeper
Zookeeper负责维护和协调broker，负责Broker Controller的选举
1.3.17 Group Coordinator
这是运行在broker上的进程，主要用于消费者组中每个消费者的offset的管理和Rebalance。同时管理当前broker的所有消费者组。
consumer是从coordinator的缓存中获取消费进度的，当consumer消费完毕提交offset到__consumer_offsets的partiton，会同时提交到这个缓存