raj*_*ota 4 apache-kafka microservices apache-zookeeper
我使用 kafka 作为微服务架构的消息总线,因此多个服务监听一个主题以获取消息。因此,服务高度依赖于要直播的主题。
但是,在很多情况下,我都得到了leader not available
,broker not available
以及leader= - 1
主题。
现在,我不确定我是否可以依赖 kafka 主题,因为当主题出现问题并导致平台出现问题时,服务就会中断。
有人可以对这些主题的可靠性和可靠性有所了解吗,如果我们可以解决上述问题,我们是否可以恢复。
我将通过解释 Kafka 的一般工作原理以及它如何处理故障来回答您的问题。
每个主题,都是一个特定的数据流(类似于数据库中的表)。主题被分成多个分区(任意多),分区中的每条消息都有一个增量 ID,称为偏移量,如下所示。
分区 0:
+---+---+---+-----+
| 0 | 1 | 2 | ... |
+---+---+---+-----+
Run Code Online (Sandbox Code Playgroud)
分区 1:
+---+---+---+---+----+
| 0 | 1 | 2 | 3 | .. |
+---+---+---+---+----+
Run Code Online (Sandbox Code Playgroud)
现在一个Kafka集群由多个broker组成。每个代理都用一个 ID 标识,并且可以包含某些主题分区。
2 个主题的示例(每个主题分别有 3 个和 2 个分区):
经纪人1:
+-------------------+
| Topic 1 |
| Partition 0 |
| |
| |
| Topic 2 |
| Partition 1 |
+-------------------+
Run Code Online (Sandbox Code Playgroud)
经纪人2:
+-------------------+
| Topic 1 |
| Partition 2 |
| |
| |
| Topic 2 |
| Partition 0 |
+-------------------+
Run Code Online (Sandbox Code Playgroud)
经纪人3:
+-------------------+
| Topic 1 |
| Partition 1 |
| |
| |
| |
| |
+-------------------+
Run Code Online (Sandbox Code Playgroud)
请注意,数据是分布式的(并且Broker 3不保存主题 2 的任何数据)。
主题,应该有一个replication-factor
> 1(通常是 2 或 3),这样当一个代理宕机时,另一个代理可以提供一个主题的数据。例如,假设我们有一个包含 2 个分区的主题,分区replication-factor
设置为 2,如下所示:
经纪人1:
+-------------------+
| Topic 1 |
| Partition 0 |
| |
| |
| |
| |
+-------------------+
Run Code Online (Sandbox Code Playgroud)
经纪人2:
+-------------------+
| Topic 1 |
| Partition 0 |
| |
| |
| Topic 1 |
| Partition 0 |
+-------------------+
Run Code Online (Sandbox Code Playgroud)
经纪人3:
+-------------------+
| Topic 1 |
| Partition 1 |
| |
| |
| |
| |
+-------------------+
Run Code Online (Sandbox Code Playgroud)
现在假设Broker 2失败了。代理 1和 3 仍然可以为主题 1 提供数据。因此,a replication-factor
of 3 始终是一个好主意,因为它允许一个代理出于维护目的而被关闭,也允许另一个代理意外关闭。因此,Apache-Kafka 提供了强大的持久性和容错性保证。
关于领导者的注意事项:
在任何时候,只有一个代理可以成为分区的领导者,并且只有该领导者可以为该分区接收和提供数据。其余的代理只会同步数据(同步副本)。另请注意,当replication-factor
设置为 1 时,当代理失败时无法将领导者移动到其他地方。一般来说,当一个分区的所有副本都失败或离线时,leader
将自动设置为-1
。
归档时间: |
|
查看次数: |
2025 次 |
最近记录: |