Kafka基本概念及术语
1 Topic
主题。在Kafka中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为topic。topic相当于消息的分类标签，是一个逻辑概念。
2 Partition
分区。topic中的消息被分割为一个或多个partition，其是一个物理概念，对应到系统上就是一个或若干个目录。 分区本身是一个FIFO的队列，所以分区中的消息是有序的。但当topic拥有多个partition的时候，那么多个partition就不存在其顺序性。
- 一般情况下一个topic的分区数量是broker数量的整数倍，即 partition % broker = 0
- 一个分区只允许同一个消费者组的一个消费者消费，不允许同组多个消费者同时消费一个partition
- 一个分区可以允许多个不同消费者组的消费者消费，每组有且只能有一个消费者消费
3 segment
段。将partition进一步细分为了若干的segment，每个segment文件的最大大小相等；segment有三个文件组成
前面的20位数字代表offset偏移量，.index为索引文件，.log为消息内容，.timeindex为时间文件。
4 Broker
Kafka 集群包含一个或多个服务器，每个服务器节点称为一个broker；假设某topic中具有N个分区（partition），集群中共有M个broker。则分区与broker间的关系是：
- 若N>M且N%M=0，则每个broker会平均存储这些分区
- 若N>M且N%M!=0，则每个broker中的分区是不平均的
- 若N<M，则会有N台broker中具有一个分区，另外M-N台broker中是没有分区的
5 Producer
生产者。即消息的发布者，其会将某topic的消息发布到相应的partition中。 生产者所生产的消息默认会平均分配到各个分区，但也可以直接指定要写入的分区，也可根据消息的key来计算路由。
6 Consumer
消费者。可以从broker中读取消息。
- 一个消费者可以消费多个topic中的消息
- 一个消费者可以消费同一个topic中的多个partition中的消息
- 一个分区中的消息允许多个无关的消费者（无关消费者即不在同一个消费者组Consumer Group）同时消费。
7 Consumer Group
consumer group是kafka提供的可扩展且具有容错性的消费者机制。组内可以有多个消费者，它们共享一个公共的ID，即group ID。组内的所有消费者会协调在一起平均消费（对分区的消费是平均的，但对于消息的消费不一定是平均的）订阅主题的所有分区。
Kafka可以保证在稳定状态下，一条消息只能被同一个consumer group中的一个consumer消费，当然，一个消息可以同时被多个consumer group消费。另外，Kafka还可以保证，在稳定状态下每一个组内consumer只会消费某一个或几个特定的partition；组中consumer数量与partition数量的对应关系如下。
8 Replicas of partition
分区副本。副本是一个分区的备份，是为了防止消息丢失而创建的分区的备份。
9 Partition Leader
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责消息读写的partition。即所有读写操作只能发生于Leader分区上。
- Leader与Follower是主备关系，不是主从关系。
- Leader宕机后，Broker Controller会从Follower中选举出一个新的Leader；注意，这个选举不是由zk完成的。
10 Partition Follower
所有Follower都需要从Leader同步消息，Follower与Leader始终保持消息同步。
11 ISR
ISR，In-Sync Replicas，是指副本同步列表；ISR列表是由Leader负责维护；Assigned Replicas，AR全副本列表初始化时AR = ISR；OSR，Outof-Sync Replicas，不可用副本列表，AR = ISR + OSR。
12 offset
偏移量。每条消息都有一个当前Partition下唯一的64字节的offset，它是相对于当前分区第一条消息的偏移量。查找具体消息消费需要通过定位偏移量来实现，例：需求查找第170213消息，通过2分法定位到partition分区中的00000000000000170210.index文件，在通过170213 - 170210 = 3，得到偏移量为3，定位到0348查找00000000000000170210.log文件，获取到m170213的这条消息。
13 Broker Controller
Kafka集群的多个broker中，有一个会被选举为controller，负责管理整个集群中partition和replicas的状态。 例如，partition leader故障，由Controller负责从ISR中的followr中重新选举出一个新的leader，其选举算法为轮训选举。
如图，现有leader为1，isr：[1,2]，当1故障后就是leader为2，如有3，那么当2故障leader即为3，恢复后列表顺位加入；
再如，当某个topic的partition数量发生变化时，由Controller负责管理partition与消费者间的分配关系，即Rebalance。
当前版本的Kafka只有Controller会向zk中注册Watcher。
早期版本的Kafka（0.8版本及之前），每一个broker及partition（所有副本）都会向zk中注册watcher。这种方式会导致Kafka的分区中出现脑裂，并且频繁更新造成zk性能下降。
14 HW与LEO
HW，HighWatermark，高水位，表示Consumer可以消费到的最高partition偏移量。HW保证了Kafka集群中消息的一致性。确切地说，是保证了partition的Follower与Leader间数据的一致性。
LEO，Log End Offset，日志最后消息的偏移量。消息是被写入到Kafka的日志文件中的，这是当前最后一个写入的消息在Partition中的偏移量。
对于leader新写入的消息，consumer是不能立刻消费的。leader会等待该消息被所有ISR中的partition follower同步后才会更新HW，此时消息才能被consumer消费。
15 Zookeeper
Zookeeper负责维护和协调broker，负责Broker Controller的选举。 从Kafka 0.9版本开始，offset的管理由broker负责管理与保存，不再由zk负责管理。
总结：zk负责Broker中Controller的选举，Partioin Leader是由Controller负责选举。
16 Coordinator
Coordinator一般指的是运行在每个broker上的group Coordinator进程，用于管理Consumer Group中的各个成员，主要用于offset位移管理和Rebalance。一个Coordinator可以同时管理多个消费者组。
17 Rebalance
当消费者组中消费者数量发生变化，或Topic中的partition数量发生了变化时， partition的所有权会在消费者间转移，即partition会重新分配，这个过程称为再均衡Rebalance。
再均衡能够给消费者组及broker集群带来高可用性和伸缩性，但在再均衡期间消费者是无法读取消息的，即整个broker集群有一小段时间是不可用的。因此要避免不必要的再均衡。
18 offset commit
Consumer从partition中取出一批消息写入到buffer对其进行消费，在规定时间内消费完消息后，会自动将其消费消息的offset提交给broker，以让broker记录下哪些消息是消费过的。当然，若在时限内没有消费完毕，其是不会提交offset。
发生Rebalance后会使用到之前提交的offset。
系统会将提交的offset作为消息写入到__consumer_offsets主题的partition中。不过需要注意，这个offset消息在写入时是有key的，其key为该offset所示消息的消费者的id。那么该offset应该放到哪个partition中呢？其会首先计算出key的hash值，然后再将此hash与50进行取模。其余数即为相应的partition编号。
