我使用kafka作为Micro Service架构的消息总线，因此多个服务侦听消息的主题。因此，服务高度依赖于要生效的主题。
但是，在很多情况下，我会在主题上获得leader not available，broker not available和leader= - 1。
现在，我不确定我是否可以依赖kafka主题，因为当平台出现原因问题时，服务会中断。
有人可以对主题的可靠性和可靠性有所了解，如果我们可以解决上述问题，我们是否可以恢复。
答案 0 :(得分：3)
我将通过解释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＆gt; 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 |
| |
| |
| |
| |
+-------------------+
现在假设 Broker 2 失败了。 Broker 1 和3仍然可以提供主题1的数据。因此，replication-factor 3总是一个好主意，因为它允许一个代理被删除用于维护目的，也用于另一个意外被取消。 因此，Apache-Kafka提供强大的耐用性和容错保证。
关于领导者的说明：
在任何时候，只有一个代理可以是分区的领导者，只有该领导者可以接收和提供该分区的数据。其余的代理只会同步数据（同步副本）。另请注意，当replication-factor设置为1时，如果代理失败，则 leader 无法移动到其他位置。通常，当分区的所有副本都失败或离线时，leader将自动设置为-1。