文章目录
- 一、Kafka Offset自动控制
- 二、Acks & Retries
- 三、幂等性
- 四、数据同步机制
- 1、高水位HW
- 2、数据同步机制-Leader Eposch
- High Watermark Truncation followed by Immediate Leader Election(数据丢失)
- 数据一致性
- 五、kafkaEagle
- 六、Kafka Flume集成
一、Kafka Offset自动控制
Kafka消费者默认对于未订阅的topic的offset的时候，也就是系统并没有存储该消费者的消费分区的记录信息，默认Kafka消费者的默认首次消费策略:latest auto.offset.reset=latest
earliest-自动将偏移量重置为最早的偏移量
latest-自动将偏移量重置为最新的偏移量
none-如果未找到消费者组的先前偏移量，则向消费者抛出异常Kafka消费者在消费数据的时候默认会定期的提交消费的偏移量，这样就可以保证所有的消息至少可以被消费者消费1次,用户可以通过以下两个参数配置:
enable.auto.commit=true 默认
auto.commit.interval.ms=5000默认如果用户需要自己管理offset的自动提交，可以关闭offset的自动提交，手动管理offset提交的偏移量，注意用户提交的offset偏移量永远都要比本次消费的偏移量+1，因为提交的offset是kafka消费者下一次抓取数据的位置。
二、Acks & Retries
Kafka生产者在发送完一个的消息之后，要求Broker在规定的额时间Ack应答答，如果没有在规定时间内应答，Kafka生产者会尝试n次重新发送消息。 acks=1 默认
- acks=1-Leader会将Record写到其本地日志中，但会在不等待所有Follower的完全确认的情况下做出响应。在这种情况下，如果Leader在确认记录后立即失败但在Follower复制记录之前失败，则记录将丢失。
- acks=0-生产者根本不会等待服务器的任何确认。该记录将立即添加到套接字缓冲区中并视为已发送。在这种情况下，不能保证服务器已收到记录。
- acks=all-这意味着Leader将等待全套同步副本确认记录。这保证了只要至少个同步副本仍处于活动状态，记录就不会丢失。这是最有力的保证。这等效于
acks=-1设置。
如果生产者在规定的时间内，并没有得到Kafka的Leader的Ack应答，Kafka可以开启reties机制:
reauesttimeoutms=30000默认
retries=2147483647默认
三、幂等性
HTTP/1.1中对幂等性的定义是:一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外)。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
Methods can also have the property of“idempotence”in that (aside from
error or expiration issues) the side-effects of N>0 identical requests
is the same as for a single request.
Kafka在0.11.0.0版本支持增加了对幂等的支持。幂等是针对生产者角度的特性。幂等口以保证上生产者发送的消息，不会丢失，而目不会重复。实现幂等的关键点就是服务端可以区分请求是否重复，过滤掉重复的请求。要区分请求是否重复的有两点:
- 唯一标识:要想区分请求是否重复，请求中就得有唯一标识。例如支付请求中，订单号就是唯一标识
- 记录下已处理过的请求标识:光有唯一标识还不够，还需要记录下那些请求是已经处理过的，这样当收到新的请求时，用新请求中的标识和处理记录进行比较，如果处理记录中有相同的标识，说明是重复记录，拒绝掉。
幂等又称为exactly once。要停止多次处理消息，必须仅将其持久化到Kafka Topic中仅仅一次。在初始化期间，kafka会给生产者生成一个唯一的ID称为ProducerID或PID。
PID和序列号与消息捆绑在一起，然后发送给Broker。由干序列号从零开始并且单调递增，因此，仅当消息的序列号比该PID/TopicPartition对中最后提交的消息正好大1时 Broker才会接受该消息。如果不是这种情况，则Broker认定是生产者重新发送该消息。
enable.idempotence=false 默认注意:在使用幂等性的时候，要求必须开启retries=true和acks=all
四、数据同步机制
Kafka的Topic被分为多个分区，分区是是按照Seaments存储文件块，分区日志是存储在磁盘上的日志序列，Kafka可以保证分区里的事件是有序的。其中Leader负责对应分区的读写、Follower负责同步分区的数据.0.11 版本之前Kafka使用hiahwatermarker机制保证数据的同步，但是基于
highwatermarker的同步数据可能会导致数据的不一致或者是乱序。在Kafka数据同步有以下概念
- LEO:log end offset标识的是每个分区中最后一条消息的下一个位置，分区的每个副本都有自己的 LEO.
- HW: high
watermarker称为高水位线，所有HW之前的的数据都理解是已经备份的，当所有节点都备份成功，Leader会更新水位线。 - ISR:In-svnc-replicas.kafka的leader会维护一份处干同步的副本集和，如果在
replica.lag.time.max.ms`时间内系统没有发送fetch请求，或者已然在发送请求，但是在该限定时间内没有赶上Leader的数据就被剔除ISR列表。在Kafka-0.9.0版本剔除replicalagmax.messages消息个数限定，因为这个会导致其他的Broker节点频繁的加入和退出ISR。
1、高水位HW
——KAFKA0.11之前的版本
High Watermark Truncation followed by lmmediate Leader Election(数据丢失)
——KAFKA0.11之前的版本
Replica Divergence on Restart after Multiple Hard Failures(数据不一致)
2、数据同步机制-Leader Eposch
——KAFKA0.11+版本
可以看出0.11版本之前Kafka的副本备份机制的设计存在问题。依赖HW的概念实现数据同步，但是存在数据不一致问题和丢失数据问题，因此Kafka-0.11版本引入了 Leader
Epoch解决这个问题，不在使用HW作为数据截断的依据。而是已引入了Leader epoch的概念，任意一个Leader持有一个
LeaderEpoch该LeaderEpoch这是一个由 Controller管理的32位数字，存储在 Zookeeper的分区状态信息中，并作为
LeaderAndlsrRequest的一部分传递给每个新的Leader。Leader接受Producer请求数据上使用LeaderEpoch标记每个Message。然后，该LeaderEpoch编号将通过复制协议传播
并用于替换HW标记，作为消息截断的参考点
改进消息格式，以便每个消息集都带有一个4字节的Leader Epoch号。在每个日志目录中，会创建一个新的Leader Epoch Sequence文件，在其中存储Leader Epoch的序列和在该Epoch中生成的消息的Start Offset。它也缓存在每个副本中，也缓存在内存中。
follower变成Leader
当Follower成为Leader时，它首先将新的Leader Epoch和副本的LEO添加到Leader Epoch Sequence序列文件的末尾并刷新数据。给Leader产生的每个新消息集都带有新的“Leader Epoch”标记。
Leader变成Follower
如果需要需要从本地的Leader Epoch Sequence加载数据，将数据存储在内存中，给相应的分区的Leader发送epoch请求，该请求包含最新的EpochlD.StartOffset信息.Leader接收到信息以后返回该EpochlD所对应的LastOffset信息。该信息可能是最新EpochID的StartOffset或者是当前EpochlD的Log End Offset信息.
- 情形1:Fllower的Offset比Leader的小
- 情形2:用户的Leader Epoch的信息startOffset信息比Leader返回的LastOffset要大
Follower回去重置自己的Leader
Epoch文件，将Offset修改为Leader的LastOffset信息，并且截断自己的日志信息
Follower在提取过程中，如果关注者看到的LeaderEpoch消息集大于其最新的LeaderEpoch，则会在其LeaderEpochSequence中添加新的LeaderEpoch和起始偏移量，并将Epoch数据文件刷新到磁盘。同时将Fetch的日志信息刷新到本地日志文件。
High Watermark Truncation followed by Immediate Leader Election(数据丢失)
数据一致性
五、kafkaEagle
六、Kafka Flume集成
