复制
Kafka可以通过可配置的服务器数量复制每个主题分区的日志（可以为每个主题设置复制因子）。这允许在集群中的服务器发生故障时自动故障转移到其他副本，因此在存在故障的情况下，消息仍然可用。
其他消息传递系统提供了一些复制相关的功能，这似乎是一个固定的事情，没有被大量使用，并且有很大的缺点：从站是非活动的，吞吐量受到很大的影响，虚拟手动配置等。默认情况下，Kafka旨在与复制配合使用 - 事实上，我们将复制因子为1的未复制的主题实现为复制主题。
复制单位是主题分区。在非故障条件下，Kafka的每个分区都有一个leader和零个或多个follower。包括领导者的副本总数构成复制因子。所有的读写操作都在leader分区进行。通常，leader的数量多于broker数量，leader在broker之间平均分配。follower上的日志与leader上的日志相同 - 所有这些日志都以相同的顺序具有相同的偏移量和消息（尽管当然，在任何给定的时间，leader可能在其日志结尾处有一些尚未复制的消息）。
Follower像Consumer那样从kafka leader消费消息，并应用到自己的日志中。让Kafka的follower从leader中拉取数据可以很好的进行批处理。
与大多数分布式系统自动处理故障一样，需要对节点“活着”的意义进行精确定义。对于kafka节点活跃有两个条件：
- 节点必须能够与ZooKeeper保持会话（通过ZooKeeper的心跳机制）
- 如果它是一个follower，它必须复制发生在leader上写操作，而不是落后于“太远”
我们将满足这两个条件的节点称为“同步”，以避免“活着”或“失败”的模糊。leader跟踪一组“同步”节点。如果follower死亡，卡住或落后，领导者将从同步副本列表中删除它。滞后副本的确定由replica.lag.time.max.ms配置控制。
在分布式系统术语中，我们只尝试处理一个“失败/恢复”模式的失败，其中节点突然停止工作，然后再恢复）。Kafka不处理所谓的“拜占庭”故障，其中节点产生任意或恶意的响应。
当该分区的所有同步副本已将其应用于其日志时，消息被视为“已提交”。只有“提交”的消息才会被给予消费者。这意味着消费者无需担心如果leader失败，可能会看到可能丢失的消息。另一方面，生产者可以选择等待消息被提交，这取决于他们偏好延迟和耐久性之间的权衡。此偏好由生产者使用的acks设置控制。
Kafka提供的保证是，只要至少有一个同步复制存活的情下消息不会丢失.
Kafka在并节点故障短时间故障转移期后仍然可用，但在网络分区存在的情况下可能无法保持可用。
Unclean leader election: What if they all die?
Kafka对数据丢失的保证是基于至少一个副同保持同步。如果复制分区的所有节点都宕机，则此保证不再成立。当所有副本死亡时，有两种行为可以执行：
- 等待ISR中的一个副本重新存活，并选择这个副本作为Leader（希望它仍然拥有所有的数据）。
- 选择第一个副本（不一定在ISR中）作为领导者恢复生活的。
这是在可用性和一致性之间的折衷。如果我们等待ISR中的副本，那么只要这些副本已经关闭，我们将保持不可用。如果这样的副本被毁坏或数据丢失，那么我们永久性地失效。另一方面，如果不同步的副本恢复生活，并且允许它成为领导者，那么它的日志也成为真理的根源，即使它不保证每一个已经提交的消息，默认情况下，Kafka选择第二种策略，并且在ISR中的所有副本都死亡时选择潜在的不一致副本。可以使用配置属性unclean.leader.election.enable禁用此行为，以支持停机时间优于不一致的用例。
这个困境不是kafka特有的。它存在于任何基于quorum-based scheme。例如在多数投票计划中，如果大多数服务器遭受永久性故障，那么您必须选择丢失100％的数据或违反一致性，将现有服务器上剩下的内容作为新的真实来源。
可用性和耐久性保证
在生产者写入消息到Kafka时，生产者可以选择是否等待消息被0,1或全部（-1）副本确认。请注意，“所有副本的确认”不能保证全部已分配的副本已收到该消息。默认情况下，当acks = all时，一旦所有当前在ISR中的副本收到消息，就会发生确认。例如，如果主题仅配置了两个副本，并且一个主题失败（即中只有一个副本在ISR），则指定acks = all的写入将成功。但是，如果剩余副本也失败，这些写入可能会丢失。尽管这确保了分区的最大可用性，但是对于那些喜欢持久性超过可用性的用户而言，这种行为可能是不希望的。因此，Kafka提供两个主题级别的配置，可用于优先于消息持久性超过可用性：
- 禁止unclean leader election:如果所有副本都不可用，则分区将保持不可用，直到最近的领导者再次可用(最近指的是副本中保存的数据可leader最近)。这样做有效地避免了消息丢失的风险。
- 指定最小ISR大小 ：如果ISR的大小大于某个最小值，则分区才接受数据写入，以防止写入单个副本的消息在副本不可用时丢失。此设置仅在生产者使用acks = all并且确保该消息至少会被许多ISR中副本确认的情况下生效。此设置提供了一致性和可用性之间的权衡。更大的最小ISR设置保证更好的一致性，因为消息被保证被写入更多的副本，这降低了丢失的可能性。但是，如果同步副本的数量下降到最小阈值以下，则分区对于写入将不可用，因此可以降低可用性。
复制管理
在Kafka集群将管理数百或数千个Topic分区。kafka以round-robin方式来平衡群集中的分区，以避免将大量topic的所有分区都聚集在少量的节点上。同样，kafka尝试平衡broker上的leader数量，以便每个节点都是其分区的比例份额的leader。
优化领导选举过程同样重要，因为这是不可用的关键窗口。一个幼稚的傻的实现是当节点故障，leader将在运行中的所有分区中选举一个节点来托管。相反的，我们选出一个broker作为“控制器”。这个控制器检查broker级别故障和负责改变所有故障的broker中的受影响的leader的分区，这样的好处是，我们能够批量处理多个需要leader变更的分区，这使得选举更廉价、更快。如果控制器发生故障，在幸存的broker之中，将选举一个成为新的控制器。