Kafka会把topic partitions的数据复制到一组server上，当一个Server宕机时可以做自动的故障恢复（automatic failover）。实际是把日志复制到一组机器上，一种基于日志的复制状态机（这里就不讨论这个）。
Kafka的每个topic portition的都会有一个leader，并且有0~n个follower。每个follower都会像一个普通的consumer一样，从leader消费上的message，也就是从leader上拉取message，并且把拉取到的message写入到自己的日志中，写入自己的日志后会（ack）通知leader写入成功。
当Producer向leader写入一条新的message时，一般是不会等follower的通知就返回，并且认为写入成功了。这时这条消息可能还没有被任何的follow拉取并且写入到自己的log中。如果这是leader宕掉的话，这条message就会丢失。
Producer有一个acks的选项，可以让producer等待收到follower后ack再认为是写入成功。收到follower的ack的message是committed的message。
那这里就会出现一个问题，producer收到多少个ack才能认为这条message是committed，也就是写入成功了那？Kafka用一种叫做ISR的策略来确定等待多少个ack。
满足以下2个条件的leader和follower被认为处于一种叫做'in sync'的状态：
- 与zookeeper保持会话session
- 如果是follower，它在从leader上复制message，并且没有落下太多（参数制定）。
Leader会记录具有'in sync'状态的所有节点的集合，当某个节点不满足上面的条件时，leader会把从集合中去除。
当所有in sync的副本已经把一条message写入到自己的log里，那么这条message就被认为是committed。
以上就是ISR副本复制策略，还是比较简单的，下面我们分析一下Kafka的可用性、数据可靠性。
显而易见，如果某个partition有f+1个副本，那么是可以容忍f个副本宕机的，并且保证数据是可靠不会丢的。
但是因为in sync集合是动态决定的，那有可能出现，集合中只有leader一个节点，其他的节点都已被移出集合，如果这时，便便Leader宕掉了，那么这种情况下数据是可能丢失的。
所以Kafka有一个参数配置可以指定集合中节点的最小数量，这可以保证即时f个副本宕机，数据也不会丢失，但是集合中的节点数如果小于最小阈值，则这个partition就不可用了。
