尺有所短，寸有所长；不忘初心，方得始终。
KafKa核心概念补充
Consumer Group
consumer group是kafka提供的可扩展且具有容错性的消费者机制。组内有多个消费者共享一个公共的group ID。组内的所有消费者会协调在一起平均消费订阅主题的所有分区。
- Kafka Consumer Group 的特点
- 一个partition中的消息只能被同一个consumer group中的一个consumer消费
- 一个partition中的消息可以同时被多个consumer group消费
- 一个组内consumer只会消费某一个或几个特定的partition
- 总结：
- Consumer Group内consumer与partition的关系是1:n，
- partition与组内consumer的关系则是1:1，即在稳定状态下，一旦为某组内consumer分配了某一个或几个partition后，就不会变化。反过来说，一旦为某partiton分配了组内cosumer，就不会再为其分配其它组内consumer了。
Consumer Group 中consumer数量与partition数量的对应关系如下:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
Broker Controller
Kafka集群的多个broker中，有一个会被选举为controller，负责管理整个集群中partition和副本replicas的状态。broker controller负责partiton leader的选举。
Partition Leader
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责消息读写的partition。即所有读写操作只能发生于Leader分区上。
Zookeeper
Zookeeper负责维护和协调broker，负责Broker Controller的选举
Coordinator
Coordinator一般指的是运行在每个broker上的group Coordinator进程，用于管理Consumer Group中的各个成员，主要用于offset位移管理和Rebalance。一个Coordinator可以同时管理多个消费者组。
Kafka工作原理与过程
一、Kafka的Message组成
Message消息：是通信的基本单位，每个 producer 可以向一个 topic（主题）发布一些消息。
Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition，每个partition存储一部分Message。
-
Message包含三个属性
- offset：消息唯一标识:对应类型 long
- MessageSize： 消息的对应类型 int32
- data：消息的具体内容，其具体又由 7 部分组成:
- crc：四个字节，用于判断 body 消息体是否正常
- magic ：文件格式，一个字节
- Attribute 代表了属性，比如是否压缩、压缩格式等等
- key-length 和 value-length 分别代表 key 和 value 的长度，
- key 和 value 分别代表了其对应的内容。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
当 magic 的值为 1 的时候，会在 magic 和 crc32 之间多一个字节的数据：attributes(保存一些相关属性，比如是否压缩、压缩格式等等)；如果 magic 的值为 0，那么不存在 attributes 属性
二、消息路由策略
在通过API方式发布消息时，生产者是以Record为消息进行发布的。Record中包含key才是消息本身，而key用于路由消息所要存放的Partition。
消息路由策略分为：
- 若指定了partition，则直接写入到指定的partition；
- 若未指定partition但指定了key，则通过对key的hash值与partition数量取模选出partition索引
- 若partition和key都未指定，则使用轮询算法选出一个partition。
三、生产者生产消息
producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。
消息生产者将消息发送给broker，并形成最终的可供消费者消费的log，是一个比较复杂的过程。
-
producer向broker集群提交连接请求，其所连接上的任意broker都会向其发送broker controller的通信URL，即broker controller主机配置文件中的listeners地址，producer向broker controller发送请求。
-
broker controller接受该请求，并根据消息路由策略计算出该消息要写入的partition。
-
broker controller根据 topic 和 partition 去 zookeeper 中找对应的znode状态中该partition的leader。
-
broker controller 向producer反馈消息要写入的partition leader。
-
producer发送消息给该leader。
-
leader接受消息并将该消息写入本地log，通知ISR中的followers进行消息同步。
-
ISR中的followers从leader中同步消息后向leader发送ACK（pull方式）。
-
leader收到所有ISR中的followers的ACK后，增加HW， 并向 producer 发送 ACK。
四、HW截断机制
如果 partition leader 接收到了新的消息， ISR 中其它 Follower 正在同步过程中，还未同步完毕时leader挂了。此时就需要选举出新的leader。若没有HW截断机制，将会导致partition中 leader 与 follower 数据的不一致。
HW 截断机制：宕机的机器恢复时，将LEO恢复到宕机时HW的位置，然后进行数据同步
五、消息发送的可靠性机制
生产者向 kafka 发送消息时，可以选择需要的可靠性级别。通过 acks 参数的值进行设置。
-
0 值
异步发送。生产者向 kafka 发送消息而不需要 kafka 反馈成功 ack。该方式效率最高，但可靠性最低，会存在消息丢失的情况。
-
1 值
同步发送，默认值。生产者发送消息给 kafka，broker 的 partition leader 在收到消息后马上发送成功 ack，生产者收到后才会再发送消息。如果一直未收到 kafka 的 ack，则生产者会认为消息发送失败，会重发消息。
该方式不能使 producer 确认其发送的消息是成功的，可能没有同步消息。但可以确认消息发送失败。
-
-1 值
同步发送。其值等同于 all，可靠性最高。生产者发送消息给 kafka，kafka 收到消息后要等到 ISR 列表中的所有副本都同步消息完成后，才向生产者发送成功 ack。如果一直未收到 kafka 的 ack，则认为消息发送失败，会自动重发消息。
-
-1值只有在特殊情况下会有消息丢失的情况
批量发送的时候缓存满了正准备发送还没发的时候，新的消息是写入不到缓存的，这个消息就会丢失，即消息从生产者端丢失的情况（很少）。
-
-1值可能会出现部分 Follower 重复接收消息的情况
Leader挂了，收不到ack，选举后新的Leader可能已经同步过部分数据，然后生产者重新发送消息的情况会导致重复消息。
-
六、Partition Leader选举范围
当 leader 挂了后 broker controller 会从 ISR 中选一个 follower 成为新的 leader。但如果 ISR中的所有副本都挂了，就会通过 unclean.leader.election.enable 的取值来设置 Leader选举的范围。
unclean.leader.election.enable的值为false，true
-
true
必须等待ISR列表中有副本活过来才进行新的选举。该策略可靠性有保证，但可用性低。
什么时候可以从OSR回到ISR，由Broker Controller完成，它会定期检测OSR的follower，判断是否符合进入ISR的条件，符合就会加进去，是个定时任务
-
false
在 ISR 中没有副本的情况下可以选择任何一个该 Topic 的 partition 作为新的 leader，该策略可用性高，但可靠性没有保证，可能会导致大量消息的丢失。
即ISR没有从OSR找
七、消费者消费过程解析
生产者将消息发送到 topic 中，消费者即可对其进行消费，其消费过程如下：
- consumer 向 broker 集群提交连接请求，其所连接上的任意 broker 都会向其发送 broker controller 的通信 URL，即 broker controller 主机配置文件中的 listeners 地址
- 当 consumer 指定了要消费的 topic 后，其会向 broker controller 发送 poll 请求
- broker controller 会为 consumer 分配一个或几个 partition leader，并将该 partitioin 的当前 offset 发送给 consumer
- consumer 会按照 broker controller 分配的 partition 对其中的消息进行消费
- 当消费者消费完该条消息后，消费者会向 broker 发送一个该消息已被消费的反馈，即该消息的 offset
- 当 broker 接到消费者的 offset 后，会更新到相应的__consumer_offset 中
- 以上过程一直重复，直到消费者停止请求消息
- 消费者可以重置 offset，从而可以灵活消费存储在 broker 上的消息