Replication in Kafka

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机时间可能更长。

posted @ 2014-11-25 16:40 TonyChai 阅读(...) 评论(...) 编辑 收藏