Kafka寫入流程：
1.producer 先從 zookeeper 的 "/brokers/.../state" 節點找到該 partition 的 leader
2. producer 將消息發送給該 leader
3. leader 將消息寫入本地 log
4. followers 從 leader pull 消息，寫入本地 log 后 leader 發送 ACK
5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 並向 producer 發送 ACK
副本策略：
Kafka的高可靠性的保障來源於其健壯的副本（replication）策略。
1) 數據同步
kafka在0.8版本前沒有提供Partition的Replication機制，一旦Broker宕機，其上的所有Partition就都無法提供服務，而Partition又沒有備份數據，數據的可用性就大大降低了。所以0.8后提供了Replication機制來保證Broker的failover。
引入Replication之后，同一個Partition可能會有多個Replica，而這時需要在這些Replication之間選出一個Leader，Producer和Consumer只與這個Leader交互，其它Replica作為Follower從Leader中復制數據。
[root@tourbis kafka_2.10-0.8.2.1]# bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test
Topic:test PartitionCount:3 ReplicationFactor:3 Configs:
Topic: test Partition: 0 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
Topic: test Partition: 1 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
Topic: test Partition: 2 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
1個Topic,3個分區，每個分區有3個副本。
2) 副本放置策略
為了更好的做負載均衡，Kafka盡量將所有的Partition均勻分配到整個集群上。Kafka分配Replica的算法如下：
將所有存活的N個Brokers和待分配的Partition排序
將第i個Partition分配到第(i mod n)個Broker上，這個Partition的第一個Replica存在於這個分配的Broker上，並且會作為partition的優先副本
將第i個Partition的第j個Replica分配到第((i + j-1) mod n)個Broker上
假設集群一共有4個brokers，一個topic有4個partition，每個Partition有3個副本。下圖是每個Broker上的副本分配情況。
1 2 3 4
3）同步策略
Producer在發布消息到某個Partition時，先通過ZooKeeper找到該Partition的Leader，然后無論該Topic的Replication Factor為多少，Producer只將該消息發送到該Partition的Leader。Leader會將該消息寫入其本地Log。每個Follower都從Leader pull數據。這種方式上，Follower存儲的數據順序與Leader保持一致。Follower在收到該消息並寫入其Log后，向Leader發送ACK。一旦Leader收到了ISR中的所有Replica的ACK，該消息就被認為已經commit了，Leader將增加HW【high watermark】並且向Producer發送ACK。
為了提高性能，每個Follower在接收到數據后就立馬向Leader發送ACK，而非等到數據寫入Log中。因此，對於已經commit的消息，Kafka只能保證它被存於多個Replica的內存中，而不能保證它們被持久化到磁盤中，也就不能完全保證異常發生后該條消息一定能被Consumer消費。
Consumer讀消息也是從Leader讀取，只有被commit過的消息才會暴露給Consumer。