日志聚合、数据监控、流处理等等
Kafka将消息写入到低俗大容量的硬盘，但仍然保持了超高的吞吐率，是因为：
分区，一个topic下的消息存在于若干分区中，一个分区只能由一组消费者中的一个消费，类似于RocketMQ中的queue
段，一个partition分成了若干segment文件，每个segment文件的最大大小相等，顺序写。segment文件名代表当前segment之前有多少条消息（每个partition单独算，其第一个segment全24个0）
segment文件由两部分组成，.index文件和.log文件，这两名字一样，后缀不同。
index文件存索引，每条数据两部分组成，第一部分代表在这个segment中相对位置，比如第一个数据为0，第二部分为数据在log文件中存储的物理位置
log文件存数据，每条数据三部分组成，第一部分为该消息在partition中的位置，第二部分是消息的大小，第三部分为消息的具体内容
消息查找的过程：1、根据消息编号二分法找到index文件 2、计算相对位置找到index中对应数据记录 3、根据数据的第二部分去log文件找消息
partition的数量一般设置为是broker的整数倍，即一个Topic在每个broker中平均存在一个或多个partition
将消息发送到Topic下的对应partition中
一组消费者组成一个消费者组，这组消费者平均消费partition
每个Partition会有备份，备份不会处理请求。备份称为Partition Follower，主机称为Partition Leader
ISR，需要同步的Follower
OSR，同步失败的Follower，一旦同步失败，从ISR中移到OSR中
AR，所有的Follower，ISR+OSR
偏移量，每个partition单独计算，指消息在partition中的名次
消费者消费完消息后，会将已消费消息的offset同步给broker。
当消费者或者partition数量发生变化时，会触发rebalance，重新调整每个消费者消费partition的关系，在此期间，消费者无法消费消息。
之前由ZooKeeper来维护消费进度，但之后由broker自己维护。消费者提交的offset被封装成特殊的消息，写入到由系统创建的、名称为__consumer_offset的特殊主题中，该主题下有50个分区，由 Math.abs(groupID.hashCode())%50 计算投放的分区
集群中有多个broker，会有一个被选举为controller，负责管理Partition和其副本的管理，包括Leader的选举，默认选举规则是谁先创建，谁当Leader。还有比如从OSR中恢复follower到ISR
Zookeeper负责维护和协调broker，负责Broker Controller的选举
这是运行在broker上的进程，主要用于消费者组中每个消费者的offset的管理和Rebalance。同时管理当前broker的所有消费者组。
consumer是从coordinator的缓存中获取消费进度的，当consumer消费完毕提交offset到__consumer_offsets的partiton，会同时提交到这个缓存
原文：https://www.cnblogs.com/walker993/p/14801306.html