Kafka-如何保证可靠性

标签：mic   必须   分区   基本   产生   ali   完成   strong   主题   

Kafka-可靠性保证-保证了哪些可靠性

ACID是关系型数据库普遍支持的标准可靠性保证。

ACID：原子性(atomicity)、一致性(consistency)、隔离性(isolation)、持久性(durability)

如果数据库遵循ACID规范，那么该数据库就支持与事务相关的行为。

kafka在哪些方面做出保证？

• 1.kafka可以保证分区消息的顺序。如果使用同一个生产者往同一个分区写入消息，而且消息B在消息A之后写入，那么kafka可以保证消息B的偏移量比消息A的偏移量大。而且消费者会先读取消息A再读取消息B。
• 2.只有当消息被写入分区的所有同步副本时（但不一定要写入磁盘），它才被认为是”已提交“的。生产者可以选择接收不同类型的确认，比如在消息被完全提交时的确认，或者在消息被写入首领副本时的确认，或者在消息被发送到网络时的确认。
• 3.只要还有一个副本是活跃的，那么已经提交的消息就不会丢失
• 4.消费者只能读取已经提交的消息。

Kafka-可靠性保证-复制机制

kafka的复制机制和分区的多副本架构是kafka可靠性保证的核心。把消息写入多个副本可以使kafka在发生崩溃时仍能保证消息的持久性。

kafka的主题被分为多个分区，分区是基本的数据块。分区存储在单个磁盘上，kafka可以保证分区里的事件是有序的，分区可以在线（可用），也可以离线（不可用）。每个分区可以有多个副本，其中一个副本是首领。所有的事件都直接发送给首领副本，或者直接从首领副本读取事件。其它副本只需要与首领保持同步，并及时复制最新的事件。当首领副本不可用时，其中一个同步副本将成为新首领。

分区首领时同步副本，而对于跟随者副本来说，他需要满足以下条件才能被认为是同步的。

• 1.与zookeeper之间有一个活跃的会话，跟随者副本在过去的6s(可配置)内向zookeeper发送过心跳
• 2.在过去的10s内(可配置)从首领那里获取过消息
• 3.再过去的10s内从首领那里获取过最新的消息。光从首领那里获取消息是不够的，它还必须是几乎零延迟的。

如果跟随者副本不能满足以上任何一点，比如与zookeeper断开连接，或者不再获取新消息，或者获取消息滞后10s以上，那么它就被认为是不同步的。一个不同步的副本通过与zookeeper重新建立连接，并从首领那里获取最新消息，可以重新变成同步的。这个过程在网络出现临时问题并很快得到修复的情况下会很快完成，但如果broker发生崩溃就需要较长时间。

一个滞后的同步副本会导致生产者和消费者变慢，因为在消息被认为已提交之前，客户端会等待所有同步副本接收消息。而如果一个副本不再同步了，我们就不再关心它是否已经收到消息。虽然非同步副本同样滞后，但它并不会对性能产生任何影响。但是，更少的同步副本意味着更低的有效复制系数，在发生宕机时丢失数据的风险更大。

注意：如果一个或多个副本在同步和非同步状态之间快速切换，说明集群内部出现了问题，通常是Java不恰当的垃圾回收配置导致的。不恰当的垃圾回收配置会造成几秒钟的停顿，从而让broker与zookeeper之间断开连接，最后变成不同步的，进而发生状态切换。

Kafka-如何保证可靠性

标签：mic   必须   分区   基本   产生   ali   完成   strong   主题   

原文地址：https://www.cnblogs.com/EnzoDin/p/13308444.html