Broker配置

1. Kafka可以同时拥有可靠的主题和非可靠的主题。非可靠的主题允许丢失。

复制系数

主题级别的配置参数是 replication.factor，在Broker级别则可以通过default.replication.factor 来配置自动创建的主题。

1. 在主题创建之后，可以通过新增或移除副本来改变复制系数。
2. 较高的复制系数会带来更高的可用性，可靠性，和更少的故障。
3. 复制系数N，需要至少N个broker，会有N个数据副本。
4. 默认副本数量是3。如果配置了机架名字，broker.rack，那么Kafka会保证分区的副本会被分布到多个机架上，防止机架上的交换机出现故障，导致所有副本全部失效。

不完全的首领选举

unclean.leader.election 只能在Broker级别配置，它默认是true。

当分区首领不可用时，一个同步副本会被选为新首领。在选举过程中其他的副本同时全部都是同步的，那么这个选举就是完全的。

这种情况会在两种场景中出现。

1. 副本数量为3，当两个Broker 发生崩溃，这两个Broker都是跟随者，那么首领Broker还能继续写入数据，所有消息都会被确认并且被提交。如果之前的一个Broker恢复，那么他成为唯一的不同步副本。
2. 副本数量为3，因为网络问题两个跟随者副本发生滞后，尽管他们还在复制消息，但是已经不同步了。唯一的同步副本首领仍然还在接收消息。这个时候，如果首领变得不可用，另外两个副本在也无法变成同步的了。

如果不同步的副本不能被提升为新首领，分区在旧首领恢复之前是不可用的。有时候这个情况会持续数个小时。

如果不同步的副本可以被提升为新首领，这个副本变为不同步之后的消息全部丢失，导致数据不一致。

unclean.leader.election.enable=true 将面临消息丢失的风险。

如果设置为false，则会降低可用性。

最少同步副本

在主题级别和Broker级别上，min.insync.replicas。如果一个主题包含三个副本，且该值为2，那么至少要存在两个同步副本才能向分区写入数据。

如果3个副本，或2个副本都不会有问题。如果两个副本变为不可用，那么Broker会停止接收生产请求。尝试发送数据会接收到NotEnoughReplicasException异常。此时它变成只读的了。

生产者的责任

1. 生产者acks=1，则存在首领收到消息之后立即崩溃导致消息丢失的问题。
2. 生产者acks=all，则Kafka在选举过程中出现首领不可用的异常，那么生产者如果没有正确处理这个异常，没有重试机制，则也会丢失消息。

在生产环境监控可靠性

Kafka的Java客户端包含了JMX度量指标，这些指标可以用于监控客户端的状态和事件。对于生产者来说，最重要的两个可靠性指标是 error-rate和retry-rate。

对于消费者来说，最重要的指标是consumer-lag。Burrow是LinkedIn公司开发的一个conusmer-lag检测工具。