Replication简介
Kafka中的Replication功能是为了给每个partition提供备份，当某个Broker挂掉时可以迅速实现故障切换（failover)。
我们可以在创建或修改topic时指定replica factor，来设定备份数目。请阅读如下实例来准确理解该参数作用：
如果一个Topic A的replica factor为3，则该topic的每一个partition都是3备份，包括1个leader和2个follower。
外界在访问Topic A时，读写只能通过leader partition进行。
注意：Kafka中默认总是打开Replication机制（如果你想为你的topic关闭该功能，一个变通的办法是指定Topic的replica factor为1。）
Kafka ISR vs Majority Vote(Quorum) .
Kafka会在Zookeeper中为每个Partition维持一个ISR (In-Sync Replicas，这里面的Replica能能跟得上对应Leader的消息更新)。一个被写入Leader的message, 只有当其被ISR中所有的replica都复制成功时，才能被Customer消费。
这保证了一个Customer不会消费到一个只在leader中保存的message（当leader挂掉时，message就会丢失。）另一方面，对于Producer来说，他可以选择是否等待一个message被所有replica复制成功，这取决于他对latency（延迟）和durability（可靠性）的偏好，可通过request.required.acks设定。
写到这里不得不提一下多数选举机制(Majority Vote),尽管Kafka没有采用。假设有replica factor设为3（2n+1）， 则message写入leader后一旦有一个follower写入成功(n+1个replica写入成功)，则该message就被认为"committed", 从而能被消费者访问。
Majority Vote的优势是其延迟取决于最快的replica, 而不是像Kafka现在的策略一样，延迟取决于最慢的replica。但Majority Vote的缺点也很明显，为了容忍一个failure, 需要3备份，这对大型系统来说很浪费资源。所以他更适合于管理元数据的分布式系统（规模较小），例如Zookeeper。
Kafka通过基于Message Set的Block I/O优化和Zero Copy技术, 来补偿ISR中潜在的延迟问题。
Partition Leader选举
Kafka的replica机制，还有一个缺点。当一个Broker挂掉时，其未flush到硬盘的数据是无法找回的。也就是说，Kafka的设计理念不保证Down机时内存数据的及时写回。这一点Kafka官方做了两点解释：
（1） 如果物理硬盘故障，很可能也不能保证数据完整性；
（2） 即使物理硬盘在故障时能保证完整性，每次写都做fsync将会对性能产生很大影响。
因而Kafka允许Replica重新加入ISR的条件是：这个Replica必须和相应的leader保持一致（完成resync)才能重新加入ISR,尽管他丢掉了故障时未写入硬盘的数据。
最坏的情况下，如果一个partition所有的replica都发生故障（相关的Broker均掉线），目前Kafka的策略是第一个重新恢复的replica默认为leader, 尽管有可能不属于原来的ISR.
未来Kafka希望能通过配置满足使用场景对于down机和dataloss的不同关切程度。也就是说，如果使用方需要保证数据不丢失，可以选择等待原有ISR中的replica复活作为Leader。代价是down机时间可能更长。