Kafka可靠性的保证

当我们谈论可靠性时，我们通常会谈到保证，保证是系统在不同情况下保留的行为。
可能最着名的可靠性保证是ACID，这是关系数据库普遍支持的标准可靠性保证。 ACID代表原子性，一致性，隔离性和耐久性。当供应商解释他们的数据库符合ACID时，这意味着数据库保证了有关交易行为的某些行为。

这些保证是人们信任关系数据库及其最关键应用程序的原因 —— 他们确切知道系统承诺的内容以及它在不同条件下的行为方式。他们理解这些保证，并可以依靠这些保证来编写安全的应用程序。

了解Kafka提供的保证对于那些寻求构建可靠应用程序的人来说至关重要。这种理解允许系统的开发人员弄清楚它在不同故障条件下的行为方式。那么，Apache Kafka保证什么？

• Kafka提供分区中消息的顺序保证。 如果消息B在消息A之后写入，在同一分区中使用相同的生成器，则Kafka保证消息B的偏移量将高于消息A，并且消费者将在消息A之后读取消息B.
• 当生成的消息在所有同步副本中写入分区时（但不一定刷新到磁盘），它们被视为“已提交”。 当消息完全提交，写入领导者或通过网络发送消息时，生产者可以选择接收已发送消息的确认。
• 只要至少有一个副本保持活动状态，提交的消息就不会丢失。
• 消费者只能读取已提交的消息。

在构建可靠系统时可以使用这些基本保证，但在本身，不要使系统完全可靠。 在构建可靠的系统时需要权衡利弊，而Kafka的构建是为了让管理员和开发人员通过提供允许控制这些权衡的配置参数来决定他们需要多少可靠性。 权衡取舍通常涉及可靠和一致地存储消息与其他重要考虑因素（如可用性，高吞吐量，低延迟和硬件成本）的重要性。

Kafka的复制机制

Kafka的复制机制，即每个分区有多个副本，是Kafka所有可靠性保证的核心。在多个副本中编写消息是Kafka如何在发生崩溃时提供消息的持久性。

• 每个Kafka主题都分解为分区，这些分区是基本的数据构建块。
• 分区存储在单个磁盘上。
• Kafka保证分区内事件的顺序，分区可以是在线（可用）或离线（不可用）。
• 每个分区可以有多个副本，其中一个是指定的领导者。所有事件都生成并从领导者副本中消费。其他副本只需要与领导保持同步，并按时复制所有最近的事件。如果领导者变得不可用，则其中一个同步副本成为新的领导者。

如果副本是分区的领导者，或者如果它是以下关注者，则认为副本是同步的：

• 与Zookeeper有活动会话 —— 意味着它在最近6秒内向Zookeeper发送了一个心跳（可配置）。
• 在过去10秒内从领导者处获取消息（可配置）。
• 在过去10秒内获取领导者的最新消息。也就是说，追随者仍然从领导者那里得到消息是不够的;它几乎没有滞后。

如果副本失去与Zookeeper的连接，停止获取新消息，或者落后并且在10秒内无法赶上，则副本被视为不同步。当一个不同步的副本再次连接到Zookeeper并赶上写入该领导者的最新消息时，它将恢复同步。这通常在临时网络故障被修复后很快发生，但如果存储副本的代理停止了较长时间，则可能需要一段时间。