我使用kafka作为Micro Service架构的消息总线，因此多个服务侦听消息的主题。因此，服务高度依赖于要生效的主题。
但是，在很多情况下，我会在主题上获得leader not available，broker not available和leader= - 1。
现在，我不确定我是否可以依赖kafka主题，因为当平台上存在原因问题的主题存在问题时服务会中断。
有人可以对主题的可靠性和可靠性有所了解，如果我们可以解决上述问题，我们是否可以恢复。
我将通过解释Kafka的一般工作方式以及它如何处理失败来回答您的问题。
每个主题都是特定的数据流（类似于数据库中的表）。主题，分为多个分区（尽可能多），其中分区中的每条消息都获得一个增量ID，称为偏移量，如下所示。
分区0：
+---+---+---+-----+
| 0 | 1 | 2 | ... |
+---+---+---+-----+
分区1：
+---+---+---+---+----+
| 0 | 1 | 2 | 3 | .. |
+---+---+---+---+----+
现在，Kafka集群由多个经纪人组成。每个代理都使用ID标识，并且可以包含某些主题分区。
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），这样当经纪人关闭时，另一个人可以提供主题的数据。例如，假设我们有一个带有2个分区的主题，其中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的数据。因此，3的replication-factor总是一个好主意，因为它允许一个经纪人被拆除用于维护目的，另一个经纪人被意外取消。因此，Apache-Kafka提供强大的耐用性和容错保证。
关于领导者的注意事项：任何时候，只有一个经纪人可以成为分区的领导者，只有该领导者才能接收和提供该分区的数据。其余的代理只会同步数据（同步副本）。另请注意，当replication-factor设置为1时，当代理失败时，领导者无法移动到其他位置。通常，当分区的所有副本都失败或离线时，leader将自动设置为-1。