Kafka基础-可靠性数据传输

可靠的数据传输是系统的一个必要属性，就像性能一样，必须从一开始就设计到系统中。Apache Kafka在可靠的数据传输方面非常灵活，支持非常多的配置参数。

1. 可靠性保证

当我们讨论可靠性时，通常会提到保证这个术语。最著名的可靠性保证ACID，它是关系型数据库普遍支持的标准可靠性保证。理解Kafka提供的保证对于创建可靠的应用是至关重要的，Kafka能够保证：

• 同一个分区消息的顺序保证。在同一分区里使用相同的生产者，如果消息B是在消息A之后写入的，那么Kafka保证消息B的offset会大于消息A，并且消费者会先读取消息A。
• 只要至少有一个副本保持alive状态，已经提交的消息就不会丢失。
• 消费者只能读取已经提交的消息。

2. Broker配置

Broker有三个可以改变Kafka关于可靠消息存储行为的配置参数：

2.1 复制因子

default.replication.factor：自动创建topic时默认的复制因子，默认为1
replication.factor：在Kafka Streams client library配置，默认为1

复制因子N允许在N-1个brokers故障时仍能够可靠地读取和写入数据。因此，设置更大的复制因子可以提高可用性和可靠性。在另一方面，对于复制因子N需要至少N个brokers，存储N个数据副本，意味着需要N倍的磁盘空间，基本上就是使用更多的硬件换取更高的可用性。

那么如何决定一个topic的复制因子？答案取决于topic的重要程度和预算。如果对于重启一个broker（集群的正常操作之一）导致特定的topic不可用时觉得OK，那么复制因子1可能就足够了。复制因子2表示可以在一个broker故障时仍然可用，但要注意的是，在一个broker故障的情况下也有可能导致集群不稳定（大多数发生在旧版本）。因此，我们建议设置复制因子至少为3。

副本的放置位置也是非常重要的，默认地，Kafka将确保分区的每个副本都放到不同的broker。然而，在某些情况下，这还不够安全。如果分区所有副本的brokers都放在同一机架上，而且机架顶部的交换机出现问题，那么无论复制因子是多少，分区都不可用。为了防止机架的故障，建议把brokers放到多个机架上，并使用broker.rack配置参数为每个broker配置机架名字。如果配置了机架名字，Kafka将确保分区的副本分布在多个机架上，以确保更高的可用性。

2.2 Unclean Leader选举

如之前所述，当分区的leader不再可用时，其中一个同步副本会被选举为新的leader。这种leader选举是“clean”的，因为它保证已经提交的数据不会丢失。但如果除了刚刚变为不可用的leader之外没有in-sync副本时，Kafka会怎样处理？这种情况可能发生在以下两种情况之一：

• 分区有3个副本，其中2个followers因故障变为不可用。在这种情况下，当生产者继续写入数据到leader时，所有消息都会被认为已经提交（因为这个时候leader是唯一的同步副本）。如果leader也出现故障，而其中一个非同步副本重新启动，那么该非同步副本将变为分区唯一可用的副本。
• 分区有3个副本，但由于网络问题，其中2个followers在默认10秒内没有同步到最新的消息从而变为非同步副本。这个时候leader是唯一的同步副本，如果leader出现故障，2个followers不会再变为同步副本。

在这两种情况下，我们要决定：

• 如果不允许非同步副本变成新的leader，相应的分区将一直保持不可用直到原来的leader重新恢复可用。
• 如果确实要允许非同步副本变成新的leader，这样会丢失已经写入到原来的leader但没有同步到副本的数据，并且还会导致消费者的某些不一致。

总之，如果允许非同步副本变成新的leader就会面临数据丢失和不一致的风险。如果不允许，将面临较低的可用性。unclean.leader.election.enable设置默认为false。

2.3 最少同步副本数

在topic和broker的配置都是min.insync.replicas，默认是1。

正如上述提到的，有些情况下即使配置了三个副本，也可能会留下只有一个同步副本。如果此副本变得不可用，我们不得不在可用性和一致性之间进行取舍，这通常不是一个容易的选择。如果希望确保已提交的数据写入多个副本，需要增大最少同步副本数。例如一个topic有3个副本，把min.insync.replicas设置为2，那么只有至少有2个副本完成同步数据时