我们正在考虑将kafka用于分布式开发，但也希望将其用作数据库。具体案例：我们在kafka写“transact”主题，并希望依靠它来存储所有交易。 问题是：此设计是否需要恢复计划，Kafka是否会因崩溃，磁盘故障而丢失数据？ 或者也许Kafka拥有自己的恢复机制，因此用户不需要他们的恢复计划？
答案 0 :(得分：2)
您的问题的简短回答：
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＆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。
关于保留期的说明 如果您计划将Kafka用作存储，则还需要了解每个主题的可配置保留期。如果您不处理此设置，则可能会丢失数据。根据{{3}}：
Kafka集群持久地保留所有已发布的记录 - 无论是否 不是他们已被消费 - 使用可配置的保留期。对于 例如，如果保留策略设置为两天，则为两者 记录发布后的几天，它可供消费， 之后它将被丢弃以释放空间。
答案 1 :(得分：0)
请阅读Kafka文档的docs部分，尤其是“可用性和耐久性保证”小节。阅读文档后，如果遇到问题，请随意发布另一个问题。