Kafka架构(0.11后)

一个partition(leader)，只能被消费组里的一个消费者消费，但是可以同时被多个消费组消费。(2.4版本可以直接消费follower)consumer 发送heartbeat请求给coordinator，返回IllegalGeneration的话，就说明consumer的信息是旧的了，需要重新加入进来，进行reblance。返回成功，那么consumer就从上次分配的partition中继续执行。reblance过程consumer reblance过程：1、consumer给coordinator发送JoinGroupRequest请求。2、这时其他consumer发heartbeat请求过来时，coordinator会告诉他们，要reblance了。3、其他consumer发送JoinGroupRequest请求。4、所有记录在册的consumer都发了JoinGroupRequest请求之后，coordinator就会在这里consumer中随便选一个leader。然后回JoinGroupRespone，这会告诉consumer你是follower还是leader，对于leader，还会把follower的信息带给它，让它根据这些信息去分配partition5、consumer向coordinator发送SyncGroupRequest，其中leader的SyncGroupRequest会包含分配的情况。6、coordinator回包，把分配的情况告诉consumer，包括leader。at least once消费者处理消息，业务处理成功后，更新offset失败，消费者重启的话，会重复消费。at most once消费者处理消息，先更新offset，再做业务处理，做业务处理失败，消费者重启，消息就丢了。exactly once下游系统保证幂等性，重复消费也不会导致多条记录。把commit offset和业务处理绑定成一个事务。

Partion1(follower)

高水位的意思，就是所有ISR中都有的最新一条记录。因为新的leader选出来后，follower上面的数据，可能比新leader多，所以要截取。从leader的角度来说高水位的更新会延迟一轮，例如写入了一条新消息，ISR中的broker都fetch到了，但是ISR中的broker只有在下一轮的fetch中才能告诉leader，也正是由于这个高水位延迟一轮，在一些情况下，kafka会出现丢数据和主备数据不一致的情况，0.11开始，使用leader epoch来代替高水位。

segment2

Consumer1

Producer

segment1

0000000000000000000.log

TopicB

zk选出Controller，负责partition分配和leader选举

......

Broker2（Coordinator）

replicate

zookeeper

0000000000000000000.index

TopicA

ConsumerGroup

Partion0(leader)

zookeeper1.zk记录了所有 broker 的存活状态，broker 会向 zookeeper 发送心跳请求来上报自己的状态。2.kafka 集群中有多个 broker，其中有一个会被zk选举为控制器例如某个分区的 leader 故障了，控制器会选举新的 leader。4.zk记录着 ISR 的信息，而且是实时更新的，只要发现其中有成员不正常，马上移除。5.zk 保存了所有 node 和 topic 的注册信息，可以方便的找到每个 broker 持有哪些    topic每个 topic 的 partition 数量、副本的位置等等。6.kafka 老版本中，consumer 的消费偏移量是默认存储在zk中的。7.zk提供了consumer的注册及每个 partition 只能被消费组中的一个 consumer 消费的partition 与 consumer 的关系保存注册管理。

Consumer0

2.4版本后可消费follower

Partion0(follower)

幂等

Partion1(leader)

ISR列表是所有的follower列表，follower会从leader去fetch数据。当leader死了，controller会从ISR列表选个follower'做leader配合producer的acks=-1保证数据一致性。ISR列表会剔除和加入机制，比如长时没fetch会从ISR列表剔除。

幂等思路是这样的，为每个producer分配一个pid，作为该producer的唯一标识。producer会为每一个维护一个单调递增的seq。类似的，broker也会为每个记录下最新的seq。当req_seq == broker_seq+1时，broker才会接受该消息。因为：1、消息的seq比broker的seq大超过时，说明中间有数据还没写入，即乱序了。2、消息的seq不比broker的seq小，那么说明该消息已被保存。

Broker1(Controller)

看offset保存在哪个partition该partition leader所在的broker就是被选定的coordinator

ConsumerN

事务性