我将kafka用作微服务体系结构的消息总线,因此多个服务在一个主题上侦听一条消息。因此,服务高度依赖于要直播的主题。
但是,我有很多这样的例子 leader not available
, broker not available
以及 leader= - 1
关于主题。
现在,我不确定我是否可以依赖Kafka主题,因为当平台中的主题出现问题时,服务就会中断。
有没有人能解释一下这些主题的可靠性和可信性,如果我们能跨越上述问题,我们能恢复过来呢。
我将kafka用作微服务体系结构的消息总线,因此多个服务在一个主题上侦听一条消息。因此,服务高度依赖于要直播的主题。
但是,我有很多这样的例子 leader not available
, broker not available
以及 leader= - 1
关于主题。
现在,我不确定我是否可以依赖Kafka主题,因为当平台中的主题出现问题时,服务就会中断。
有没有人能解释一下这些主题的可靠性和可信性,如果我们能跨越上述问题,我们能恢复过来呢。
1条答案
按热度按时间t40tm48m1#
我将通过解释Kafka是如何工作的以及它如何处理失败来回答你的问题。
每个主题都是一个特定的数据流(类似于数据库中的表)。主题被划分为多个分区(可以任意多个分区),分区中的每条消息都获得一个增量id,称为偏移量,如下所示。
分区0:
分区1:
现在,Kafka集群由多个代理组成。每个代理都用一个id标识,并且可以包含某些主题分区。
2个主题的示例(每个主题分别有3个和2个分区):
经纪人1:
经纪人2:
经纪人3:
请注意,数据是分布式的(broker 3不包含主题2的任何数据)。
主题,应该有一个
replication-factor
>1(通常是2或3),这样当一个代理关闭时,另一个代理可以提供一个主题的数据。例如,假设一个主题有两个分区,每个分区有一个replication-factor
设置为2,如下所示:经纪人1:
经纪人2:
经纪人3:
现在假设代理2失败了。代理1和3仍然可以为主题1提供数据。所以
replication-factor
3总是一个好主意,因为它允许一个经纪人为了维护的目的被拆掉,也允许另一个经纪人意外地被拆掉。因此,apachekafka提供了强大的持久性和容错保证。关于引线的注意:在任何时候,只有一个代理可以是分区的引线,并且只有该引线可以接收和服务该分区的数据。其余的代理将只同步数据(同步副本)。还要注意的是
replication-factor
如果设置为1,则在代理失败时不能将引线移到其他位置。通常,当一个分区的所有副本都失败或脱机时leader
将自动设置为-1
.