Kafka之Partition及Propagate原理

Leader

将消息写入本地Log

ACK

Follower从Leader那里Pull数据

发送请求寻找PartitionLeader

Leader收到ISR系统中所有Follower的ACK包后认为该消息已经commit了

Producer

Follower将数据写入本地Log

Topic

Replication机制的引入： 在没有Replication的情况下，一旦某机器宕机或者某个Broker停止工作则会造成整个系统的可用性降低。随着集群规模的增加，整个集群中出现该类异常的几率大大增加，因此对于生产系统而言Replication机制的引入非常重要;引入replica，需要保证同一个Partition的多个Replica之间的数据一致性和有序性。1. Kafka尽量将所有Partition均匀分配到整个集群上。典型的部署方式是一个Topic的Partition数量等于Broker的数量。2. 同时为了提高Kafka的容错管理，需要将同一个Partition的Replica分散到不同的机器。

Partition 1

Propagate消息时序图:

Replica 3

ACK:-1

Replica N

(N =1)

Replica 2

向Topic发送消息时序图

Follower

ACK:1

Push数据到Partition的Replica 3

返回Partition的LeaderReplica 3

Partition

Partition N

ISR列表

ZooKeeper

向Partition的LeaderPush消息

实际方案：

Follower收到消息就立即返回ACK

理论方案：

ACK:0

从Leader执行拷贝sync任务

Replica 1

选 Replica 3为Leader

算法

Replica 3就是被选出和producer及consumer进行交互的partition主分区

Partition 2