主题分区是否应该跨kafka集群中的所有代理节点复制?

hfsqlsce  于 2021-06-04  发布在  Kafka
关注(0)|答案(2)|浏览(321)

尽管类似的问题也有答案。我的好奇心在于假设n1-5节点在集群中,主题t1在n1、n2和n3上,主题t2在n3、n4和n5上。现在假设p1推送t1中的消息,c1消耗t1中的消息,类似地p2和c2消耗t2中的消息。
这就是我怀疑的地方?
假设节点n3-n5都关闭了,现在p1和c1仍然有到集群的活动连接,这对于发布和消费失败来说是无用的(度量连接\u计数大于0表示有来自生产者或消费者的到群集的连接)
将主题复制到kafka集群中的所有节点是否正确?
为什么我们要在bootstrap服务器属性中提供多个节点地址的详细信息一个地址就足够了?
注:我是一个初学者在Kafka的世界,仍然与本地设置实验,以发现潜在的问题,可能会发生在现实世界中。

ukxgm1gy

ukxgm1gy1#

假设节点n3-n5都关闭了,现在p1和c1仍然有到集群的活动连接,这对于发布和消费失败来说是无用的(度量连接\u计数大于0表示有来自生产者或消费者的到群集的连接)
答:如果作为主题副本的三个代理都已关闭,则无法从该主题生成或消费。为了避免这种情况,建议在不同的机架中放置代理并提供 broker.rack 代理配置中的信息。
broker.rack:代理的机架。这将在机架感知复制分配中用于容错。示例: RACK1 , us-east-1d 将主题复制到kafka集群中的所有节点是否正确?
答:这完全取决于您的容错需求。如果将主题复制到所有6个代理,那么最多可以容忍5个代理失败(当然 min.insync.replicas 以及 acks 配置也很重要。如果副本数为6, min.insync.replicas=2 , acks=all 然后,您最多可以容忍4个代理失败以继续发送消息)
为什么我们要在bootstrap服务器属性中提供多个节点地址的详细信息一个地址就足够了?
回答: bootstrap.servers config用于初始化到kafka集群的连接。是的,一个地址就够了,但是如果这个地址的代理坏了怎么办。无法连接到群集。所以建议提供多个地址,避免这种有冗余的情况。

kuuvgm7e

kuuvgm7e2#

为什么要失败?节点n1和n2仍在运行,并假设主题具有 replication-factor=3 所有的数据仍然可以访问。
我得说这要看情况了。跨所有节点复制主题不会有什么坏处,但有时是多余的(特别是当集群中有大量代理时)。要获得高可用性,应至少设置 replication-factor=3 . 例如,这允许一个代理被关闭进行维护,另一个代理意外失败。 bootstrap.servers 用于设置与kafka群集的连接。一个地址通常足以访问整个集群,但最好提供所有地址,以防其中一个服务器停机。请注意,客户机(生产者或消费者)使用所有代理,而与中指定的服务器无关 bootstrap.servers .
2个主题的示例(每个主题分别有3个和2个分区):
经纪人1:

+-------------------+
|      Topic 1      |
|    Partition 0    |
|                   |
|                   |
|     Topic 2       |
|   Partition 1     |
+-------------------+

经纪人2:

+-------------------+
|      Topic 1      |
|    Partition 2    |
|                   |
|                   |
|     Topic 2       |
|   Partition 0     |
+-------------------+

经纪人3:

+-------------------+
|      Topic 1      |
|    Partition 1    |
|                   |
|                   |
|                   |
|                   |
+-------------------+

请注意,数据是分布式的(broker 3不包含主题2的任何数据)。
主题,应该有一个 replication-factor >1(通常是2或3),这样当一个代理关闭时,另一个代理可以提供一个主题的数据。例如,假设一个主题有两个分区,每个分区有一个 replication-factor 设置为2,如下所示:
经纪人1:

+-------------------+
|      Topic 1      |
|    Partition 0    |
|                   |
|                   |
|                   |
|                   |
+-------------------+

经纪人2:

+-------------------+
|      Topic 1      |
|    Partition 0    |
|                   |
|                   |
|     Topic 1       |
|   Partition 0     |
+-------------------+

经纪人3:

+-------------------+
|      Topic 1      |
|    Partition 1    |
|                   |
|                   |
|                   |
|                   |
+-------------------+

现在假设代理2失败了。代理1和3仍然可以为主题1提供数据。所以 replication-factor 3总是一个好主意,因为它允许一个经纪人为了维护的目的被拆掉,也允许另一个经纪人意外地被拆掉。因此,apachekafka提供了强大的持久性和容错保证。
关于引线的注意:在任何时候,只有一个代理可以是分区的引线,并且只有该引线可以接收和服务该分区的数据。其余的代理将只同步数据(同步副本)。还要注意的是 replication-factor 如果设置为1,则在代理失败时不能将引线移到其他位置。通常,当一个分区的所有副本都失败或脱机时 leader 将自动设置为 -1 .

相关问题