我使用 kafka 作为微服务架构的消息总线，因此多个服务在一个主题上侦听消息。因此，服务高度依赖于要直播的主题。
但是，在很多情况下，我会在主题上收到 leader not available、broker not available 和 leader= - 1。
现在，我不确定我是否可以依赖 kafka 主题，因为当主题出现问题并导致平台中出现问题时，服务会中断。
有人可以说明这些主题的可靠性和可靠性吗？如果我们可以解决上述问题，我们是否可以恢复。
【问题讨论】：
标签： apache-kafka apache-zookeeper microservices
我将通过解释 Kafka 的一般工作原理以及它如何处理故障来回答您的问题。
每个主题，都是一个特定的数据流（类似于数据库中的表）。主题，被分成 partitions（任意数量），其中分区中的每条消息都有一个增量 id，称为偏移量，如下所示。
分区 0：
+---+---+---+-----+
| 0 | 1 | 2 | ... |
+---+---+---+-----+
分区 1：
+---+---+---+---+----+
| 0 | 1 | 2 | 3 | .. |
+---+---+---+---+----+
现在一个 Kafka 集群由多个 brokers 组成。每个代理都有一个 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不保存topic 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 |
| |
| |
| |
| |
+-------------------+
现在假设 Broker 2 失败了。 代理 1 和 3 仍然可以为主题 1 提供数据。因此，replication-factor 为 3 始终是一个好主意，因为它允许一个代理被删除以进行维护，也允许另一个代理被删除出乎意料地被取下来。 因此，Apache-Kafka 提供了强大的持久性和容错保证。
关于领导者的注意事项：
在任何时候，只有一个代理可以成为分区的领导者，并且只有该领导者可以接收和提供该分区的数据。其余的代理只会同步数据（同步副本）。另请注意，当 replication-factor 设置为 1 时，leader 在代理失败时无法移动到其他位置。一般来说，当一个分区的所有副本都失败或下线时，leader 会自动设置为-1。
【讨论】：