浏览工夫：6 分钟
在较早的博客中，咱们介绍了 Kafka 的根本术语，并进一步深刻了 Zookeeper。当初，让咱们具体探讨主题分区和正本。
主题分区
主题 (Topic) 或称音讯队列，是您在 Kafka 中数据的寄存地位。主题的数据进一步分为多个分区(Partition)。每个分区都是有序的，不可变的记录序列，这些记录间断地附加到结构化的提交日志中。
当公布带有密钥的音讯（带密钥的音讯）时，Kafka 依据密钥的哈希确定性地将音讯映射到分区。这样能够保障具备雷同密钥的音讯始终被路由到同一分区。对于没有密钥的音讯，Kafka 会将其随机映射到任何分区中。
偏移量
分区中的每个音讯都有一个称为其 偏移量 (offset) 的标识符。它是音讯队列的不可被生产者或消费者更改的序号，由 Kafka 系统维护。消费者能够从特定的偏移量开始读取音讯，并能够从他们抉择的任何偏移量点进行读取，从而容许消费者在他们认为适合的任何工夫点退出集群。
分区越多，吞吐量越高
主题分区是 Kafka 中并行性的单位。在使用者角度来看，Kafka 始终将单个分区的数据提供给一个使用者线程。因而，使用者（在使用者组内）的并行度受要应用的分区数限度。因而，通常，Kafka 群集中的分区越多，能够实现的吞吐量就越高。
更多分区的陷阱
- 须要更多文件处理程序
每个分区都映射到代理中文件系统中的目录。在该日志目录中，每个日志段将有两个文件（一个用于索引，另一个用于理论数据）。对于每个日志段，每个代理都关上蕴含索引文件和数据文件的文件句柄。
如果存在大量分区，则关上文件的总数可能十分宏大。尽管这能够通过调整配置来解决。
咱们能够应用以下命令查看关上的文件数：lsof | wc -l
应用以下命令能够解决此问题：ulimit -n <noOfFiles> - ** 端到端提早
** 从生产者公布的音讯到消费者读取的音讯之间的工夫称为提早。Kafka 仅在提交音讯后（即，将音讯复制到所有同步正本时）才将音讯公开给使用者。因而，提交音讯的工夫可能是端到端提早的重要局部。鉴于默认状况下，对于在两个代理之间共享正本的所有分区，默认状况下，Kafka 代理仅应用一个线程从另一个代理复制数据。
例如，假设一个代理上有 1000 个分区领导者，并且它是两个具备复制因子为 2 的代理的 Kafka 集群。第二个代理须要从第一个代理中获取 500 个分区。一个线程负责将这些分区从代理 1 提取到代理 2。这将破费足够的工夫。然而，在大型群集的状况下，这一点不会引起问题，因为每个代理只需累赘大量复本。
在 Kafka 中复制
复制（Replication）意思是在集群上保留数据的正本，以便在任何应用程序中晋升可用性功能。Kafka 中的复制处于分区级别。每个分区在群集上具备 0 个或多个正本。
上例中，咱们在代理（Broker）1 和 2 中具备分区 0，在代理 1 和 4 中具备分区 1，在代理 3 和 4 中具备分区 2。在这些正本中，其中一个分区将充当领导者（主分区），而其余分区将作为跟随者（从分区）。
领导者负责发送和接管该分区的数据。
因而，当咱们说一个主题的复制因子为 2 时，这意味着其每个分区领有两个正本。当同步正本集（In-Sync Replica set, 简称 ISR）中的所有正本均已确认已将记录写入磁盘时，Kafka 认为记录已提交。
Kafak 确认机制
生产者能够抉择应用“acks”设置来接管对写入分区的数据的确认。
ack-value 是 Apache Kafka 中的生产者配置参数，它定义仅应从同步正本中期待的确认数。能够将其设置为以下值：
ACK=0 [NONE]
当 ack 值设置为 0 时，生产者将永远不会期待来自代理的确认。无奈保障代理已收到音讯。生产者不会尝试再次发送记录，因为生产者从不晓得记录失落了。此设置提供了较低的提早和较高的吞吐量，但以更高的音讯失落危险为代价。
ACK=1 [LEADER]
将 ack 值设置为 1 时，生产者将在领导者收到记录后失去 ack。领导者会将记录写入其日志，但会在不期待所有关注者的齐全确认的状况下做出响应。仅当领导者在确认记录之后但在追随者复制它之前立刻失败时，该音讯才会失落。此设置是提早，吞吐量和持久性的两头根据。它比 acks = 0 慢，但更耐用。
ACK= -1 [ALL]
将 ack 值设置为 all 意味着当所有同步正本都收到记录时，生产者将取得 ack。领导者将期待全套同步正本确认记录。这意味着发送带有所有 ack 值的音讯要花费更长的工夫，然而它提供了最强的音讯持久性。
什么是 ISR？
同步正本是与其领导者（即与领导者具备雷同音讯 / 或同步信息的跟随者）同步的复制分区 ISR 数并不强制性要求等于正本数。
“同步”的定义取决于主题配置，然而默认状况下，这意味着正本在最近 10 秒钟内曾经或曾经齐全与领导者同步。此时间段的设置为：replica.lag.time.max.ms，并具备服务器默认值，能够按每个主题笼罩该服务器默认值。
追随者通过定期发送获取申请（默认状况下每 500 毫秒发送一次）来将数据从领导者复制到本人。
如果追随者失败，则它将进行发送获取申请，并且在默认值 10 秒钟之后，将从 ISR 中删除。同样，如果追随者速度变慢，可能是与网络无关的问题或服务器资源受限，那么一旦它落后于领导者超过 10 秒钟，就会将其从 ISR 中删除。
min.insync.replicas 值指定了必须全副确认写入后能力视为写入胜利的最小正本数，因而，它对负责写入的生产方具备影响。此配置参数对生产方没有任何间接影响，这就是为什么它不影响消费者的起因，即便无效经纪人的数量小于的值 min.insync.replicas。
当生产者将 acks 设置为“all”（或“-1”）时，min.insync.replicas 指定必须确认写入能力使写入胜利的最小正本数。如果不能满足此最小值，则生产者将引发异样（NotEnoughReplicas或NotEnoughReplicasAfterAppend）。
一起应用时，min.insync.replicas 和 acks 可使您施行更大的可用性保障。典型的状况是创立一个复制因子为 3 的主题，将 min.insync.replicas 设置为 2，并设产生者确认为“all”。如果未收到大多数正本写入，这将确保生产者引发异样。
有什么益处？
如果任何一个代理解体或因为网络问题而无法访问，其中一个正本将成为领导者。
只有属于同步正本列表的一部分的正本才有资格成为领导者，并且无论何时对其进行任何更改，同步正本的列表都会保留给 zookeeper。同样，只有在至多有一个同步正本时，Kafka 才会保障不会失落数据。
如果没有此类正本，则此保障不实用。
这就是主题分区，复制和 ISR 的全部内容。我将在进一步的博客中介绍无关 Kafka 的更多信息。编码欢快！