kafka保证数据可靠性的方式

可靠性保证和复制机制

Kafka的以下几个基本特性保证了基本的可靠性：

• Kafka保证一个分区的消息是FIFO的
• 只有消息写入了所有分区的同步副本时，才认为是已提交的
• 只要有一个副本活跃，则消息就不会丢失
• 消费者只能读取已提交的消息

生产者可以进行有关配置，使得不一定等到数据认为是已提交的之后，才进行下一轮的投递，这是在可用性和一致性的之间的平衡

分区副本复制方式和同步条件：

• 每个分区所在的broker需要向分区首领所在的broker每6s（可配置）发送一个zk的消息
• 分区副本过去10s（可配置）内从分区首领那里获取过消息，且获取过最新消息。这是尽最大努力保证一致性。
• 不同副本通过zk建立连接，并获取最新的数据
• 滞后的副本会使得生产者和消费者变慢，因为生产者可能要配置确认的方式，而消费者必须等所有副本都同步，此时数据是已提交的之后，才可以读取

broker配置

复制系数及其意义
replication.factor：复制系数，指定了一个分区的副本个数，默认是3，意思是每个分区在不同的broker上有三个数据副本，会比原来多三倍的空间。

borker.rack：配置机架参数，一般要把不同的broker配置在不同的机架上。

不完全首领选举

• 定义：不同步的副本分区之间，选取新的分区首领
• 应用场景：首领分区的broker不可用，而且各个副本分区的broker都是不同步的情况。
  给出两个常见的场景：
  • 3个broker，某个partition有两个副本broker，而且都崩溃了。生产者写入数据，仍然会被记录（此时是主分区在读写），此时首领不可用，而有一个副本可用了，则副本会成为首领broker，但是数据是不同步的
  • 3个broker，由于网络问题导致两个副本不同步，此时首领崩溃，另外两个副本也无法同步
• 具体方案：一般来说，只能在可用性和一致性之间抉择。选择集群不可用的情况；或者不一致的可用集群，此时副本会把就的消息删除，消费者无法获取对应的消息。

最少同步副本
多个副本的情况，可能出现部分副本不同的情况，为了保证一致性，需要设置min.insync.replicas参数，如果不同步或者不可用副本超过该数，则首领分区broker会停止接收生产者的数据，此时生产者会报错；但是消费者仍然可读。恢复可写的情况，需要重新让同步副本不小于该数。

生产者可靠性保证

两种常见的不可靠场景

• 多个broker的集群，首领分区和副本分区都是同步的，在某一个时刻写入数据，此时首领分区的broker崩溃，而副本分区仍然认为自己是同步的；生产者的ack=1，首领分区在回复ack之后崩溃的。此时这条消息永远丢失
• 多个broker集群，ack=all，此时如果有任一个broker不可用，生产者都会收到错误，因此需要生产者自己处理这种错误。

发送确认的保证

• ack=0，此时只要发送成功即可，也不需要等首领分区的ack，因此吞吐量高，没有任何保证，一般仅用于基准测试。
• ack=1，如果正在进行分区首领选举或者集群首领选举，则会受到错误；如果首领回复ack，也可能出现上面提到的不可靠情况，首领回复ack后瞬间崩溃。
• ack=all和min.insunc.replicas混合使用，生产者一直重试直到所有的成功提交。生产者等待发送成功并发送下一条消息前，需要收到所有副本的确认。可以使用异步和增大批次的方式，提高效率。

生产者本身也要能处理自身的错误

消费者可靠性保证

消费者可靠性主要在两方面：

• offset偏移量提交
  • 自动提交偏移量
  • 每次处理完成任务之后
• 轮询设定，如果任务时间长，一定要保证心跳，心跳通过轮询发送

auto.offset.reset：如果没有偏移量可以提交，或者请求的偏移量不存在时，消费者的行为：

• lastest：从分区的末尾读取，减少数据重复
• earliest：从分区头部读取，会产生大量的重复数据