【Kafka】Kafka可靠的数据传递-编程知识

【Kafka】Kafka可靠的数据传递

Kafka可以保证分区中的消息时有序的，如果同一个生产者向同一个分区写入消息，消息B在消息A 之后写入，那么Kafka可以保证消息B的偏移量比消息A的大，并且消费者会先读取消息A再读取消息B
一条消息只有在被写入分区的所有副本时才会被认为是已提交。
只要还有一个副本是活动的，已提交的消息就不会丢失
消费者只能读取已提交的消息

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

broker中有3个参数影响Kafka的消息存储可靠性。
参数即作用于所有topic，也可仅作用于单个topic

replication.factor：主题级别的副本个数配置
default.replication.factor：broker级别，用来自动配置创建topic时的副本数。
假设副本个数是N，那么在N-1个broker失效的情况下，客户端仍能从主题读取数据或者写入数据。所以更高的副本数，能带来更高的可用性、可靠性和更少的灾难性事故。但是会占用N倍的磁盘空间。

副本个数设置考虑因素

可用性：如果一个分区仅有一个副本，那么broker重启期间将不可用，副本越多，可用性越高
持久性：每个副本都包含了一个分区的所有数据，如果仅有一个副本，一旦磁盘损坏，分区数据就丢失了。
吞吐量：每增加一个副本，都会增加broker内复制流量。如果以10MBps的速率向一个分区发送数据，在规划集群大小时，需要考虑该因素。
- 1个副本：不增加复制流量
- 2个副本：增加10MBps复制流量
- 3个副本：增加20MBps复制流量
端到端的延迟：每个消息，只有同步到所有副本之后，才能被消费者消费。当一个broker变慢，就会影响所有的客户端。
成本：数据副本越多，存储和网络成本就越高，所以非关键数据，副本数可以不用很高。

unclean.leader.election.enable：broker级别的配置，默认是false
当分区首领不可用时，一个同步副本会被选举为新首领，如果选举过程中未丢失数据，则成为彻底选举。

首领选举场景

min.insync.replicas：作用在topic和broker级别

如果一个topic有3个副本，最终只用一个同步副本，最后这个副本也变为不可用，那么需要在可用性和一致性做出选择。根据Kafka可靠性保证，一条消息被写入所有同步副本后才认为是已提交的，如果没有可用副本，则数据有可能丢失。

min.insync.replicas：可以设置消息最少要有同步副本，才能像分区写入数据。

消息没有被持久化到磁盘中，Kafka也可以向生产者发出确认，这取决于已经接收到晓得副本数量。我们可以配置flush.messages用于控制同步到磁盘的最大消息数和flash.ms用于控制同步频率。

如果broker我们配置了高可靠，但是生产者没有进行可靠性方面的配置，那么系统还是会有丢失数据的风险。

acks=0：broker配置副本数是3个，但是该参数下，仅关注消息是否发送，认为发送成功就代表写入Kafka，如果broker崩溃，就是丢失消息。发送完了，在所有副本没有同步完消息前，消费者是看不到消息的。
acks=1：首领副本写入消息后，就返回成功，与 acks=0类似的问题，消息丢失和消费者查看数据的延迟。
acks=all：等待所有听不副本收到消息再返回。这种最安全，在返回成功响应前会一直重试，直到消息提交成功。

消费者的可靠性主要依赖于偏移量的提交。
涉及到reblance时，新消费者对分区数据的消费

group.id：如果希望一个消费者消费topic所有分区数据，则需要设置一个唯一group.id
auto.offset.reset：指定了当没有偏移量时，消费者该如何处理
- earliest：从开始位置读取，会导致重复消费
- latest：从最新位置读取，会导致部分数据丢失
enable.auto.commit：自动提交偏移量；如果业务逻辑较为复杂，需要其他程序进行提交，则需要手动提交。
auto.commit.interval.ms：控制自动提交的频率，默认每5秒提交一次。