复制-Kafka 的核心
复制功能是 Kafka 架构的核心。在 Kafka 的文档里, Kafka 把自己描述成“一个分布式的、可分区的、可复制的提交日志服务”。复制之所以这么关键, 是因为它可以在个别节点失效时仍能保证 Kafka 的可用性和持久性。
Kafka 使用主题来组织数据, 每个主题被分为若干个分区,每个分区有多个副本。那些副本被保存在 broker 上, 每个 broker 可以保存成百上千个属于 不同主题和分区的副本。
replication-factor
用来设置主题的副本数。每个主题可以有多个副本，副本位于集群中不同的 broker 上，也就是说副本的数量不能超过 broker 的数量，否则创建主题 时会失败。
比如partitions 设置为 2，replicationFactor 设置为 1. Broker 为 2 个的话，分区会均匀在 broker kafka-topics.bat --zookeeper localhost:2181/kafka --create --topic topicB --replication-factor 1 --partitions 2
比如partitions 设置为 2，replicationFactor 设置为 2. Broker 为 2 个的话，每个 broker 都有副本存在 kafka-topics.bat --zookeeper localhost:2181/kafka --create --topic topicA --replication-factor
副本类型。
优先副本和优先副本的关系：
古代皇帝选太子，皇帝有三个儿子，大儿子、二儿子、三儿子，优先副本是大儿子（优先副本这个关系定下来了就不会变），首领副本就是太子， 皇帝选太子时，一般也会将优先副本选为首领副本，但是太子是有可能变动变动的，如果大儿子犯事了，那么二儿子就会成为太子）
首领副本
每个分区都有一个首领副本。为了保证一致性,所有生产者请求和消费者请求都会经过这个副本 。
跟随者副本
首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求,它们唯一一的任务就是从首领那里复制消息, 保持与首领一致的状态 。 如 果首领发生崩溃, 其中的一个跟随者会被提升为新首领 。
优先副本
除了当前首领之外, 每个分区都有一个优先副本（首选首领），创建主题时选定的首领分区就是分区的优先副本。 之所以把它叫作优先副本, 是因 为在创建分区时, 需要在 broker 之间均衡首领副本。 因此, 我们希望首选首领在成为真正的首领时, broker 间的负载最终会得到均衡。 默认情况下, Kafka 的 auto.leader.rebalance.enable 被设为 true,它会检査优先副本是不是当前首领,如果不是,并且该副本是同步的, 那么就会触发首领选举, 让优先副本成为 当前首领。
工作机制
首领的另一个任务是搞清楚哪个跟随者的状态与自己是一致的。跟随者为了保持与首领的状态一致，在有新消息到达时尝试从首领那里复制消息, 不 过有各种原因会导致同步失败。例如,网络拥塞导致复制变慢, broker 发生崩演导致复制滞后,直到重启 broker 后复制才会继续。
为了与首领保持同步, 跟随者向首领发送获取数据的请求, 这种请求与消费者为了读取消息而发送的请求是一样的。首领将响应消息发给跟随者。请 求消息里包含了跟随者想要获取消息的偏移量, 而且这些偏移量总是有序的 。
一个跟随者副本先请求消息 1,接着请求消息 2,然后请求消息 3,在收到这 3 个请求的响应之前,它是不会发送第 4 个请求消息的。如果跟随者发送了请 求消息 4,那么首领就知道它已经收到了前面 3 个请求的响应。 通过査看每个跟随者请求的最新偏移量, 首领就会知道每个跟随者复制的进度。如果跟随者在 10s 内没有请求任何消息,或者虽然在请求消息,但在 10s 内没有请求最新的数据,那么它就会被认为是不同步的。如果一个副本无法与首领保持一致, 在首领发生失效时,它就不可能成为新首领，因为它没有包含全部的消息。
相反,持续请求得到的最新消息副本被称为同步副本。在首领发生失效时,只有同步副本才有可能被选为新首领。