Kafka从入门到精通（十）消息不丢失机制

1. 消息不丢失机制

1.1 broker数据不丢失

生产者通过分区的leader写入数据后，所有在ISR中follower都会从leader中复制数据，这样，可以确保即使leader崩溃了，其他的follower的数据仍然是可用的。

1.2 生产者数据不丢失

• 生产者连接leader写入数据时，可以通过ACK机制来确保数据已经成功写入。ACK机制有三个可选配置
  1.配置ACK响应要求为 -1或者ALL 时 —— 表示所有的节点都收到数据(leader和follower都接
  收到数据）
  2.配置ACK响应要求为 1 时 —— 表示leader收到数据
  3.配置ACK影响要求为 0 时 —— 生产者只负责发送数据，不关心数据是否丢失（这种情
  况可能会产生数据丢失，但性能是最好的）
• 生产者可以采用同步和异步两种方式发送数据（如果报异常了，就重新发一次就好了）
• 同步：发送一批数据给kafka后，等待kafka返回结果。
• 异步：发送一批数据给kafka，只是提供一个回调函数。

1.3 消费者数据不丢失

在消费者消费数据的时候，只要每个消费者记录好offset值即可，就能保证数据不丢失。

• At-most once：最多一次（只管把数据消费到，不管有没有成功，可能会有数据丢失）
  

• At-least once：最少一次（有可能会出现重复消费）
  

• Exactly-Once：仅有一次（事务性性的保障，保证消息有且仅被处理一次）文中都是在说kafka的offset默认存储在zk，实际上kafka的offset存储在kafka中，详情请看https://www.jianshu.com/p/90a15fe33551

2. 数据积压

Kafka消费者消费数据的速度是非常快的，但如果由于处理Kafka消息时，由于有一些外部IO、或者是产生网络拥堵，就会造成Kafka中的数据积压（或称为数据堆积）。如果数据一直积压，会导致数据出来的实时性受到较大影响。

2.1解决数据积压问题

当Kafka出现数据积压问题时，首先要找到数据积压的原因。以下是在企业中出现数据积压的几个类场景。

2.1.1 数据写入MySQL失败

消费这个topic的代码比较简单，主要就是消费topic数据，然后进行判断在进行数据库操作。运维通过kafka-eagle找到积压的topic，发现该topic的某个分区积压了几十万条的消息。
最后，通过查看日志发现，由于数据写入到MySQL中报错，导致消费分区的offset一自没有提交，所以数据积压严重。

2.1.2 因为网络延迟消费失败

问题描述
基于Kafka开发的系统平稳运行了两个月，突然某天发现某个topic中的消息出现数据积压，大概有几万条消息没有被消费。

问题分析
通过查看应用程序日志发现，有大量的消费超时失败。后查明原因，因为当天网络抖动，通过查看Kafka的消费者超时配置为50ms，随后，将消费的时间修改为500ms后问题解决。

3. Kafka中数据清理（Log Deletion）

Kafka的消息存储在磁盘中，为了控制磁盘占用空间，Kafka需要不断地对过去的一些消息进行清理工作。Kafka的每个分区都有很多的日志文件，这样也是为了方便进行日志的清理。在Kafka中，提供两种日志清理方式：

• 日志删除（Log Deletion）：按照指定的策略直接删除不符合条件的日志。
• 日志压缩（Log Compaction）：按照消息的key进行整合，有相同key的但有不同value值，只保留最后一个版本。

在Kafka的broker或topic配置中：

配置项	配置值	说明
log.cleaner.enable	true（默认）	开启自动清理日志功能
log.cleanup.policy	delete（默认）	删除日志
log.cleanup.policy	compaction	压缩日志
log.cleanup.policy	delete,compact	同时支持删除、压缩

3.1 日志删除

日志删除是以段（segment日志）为单位来进行定期清理的。

3.2 定时日志删除任务

Kafka日志管理器中会有一个专门的日志删除任务来定期检测和删除不符合保留条件的日志分段文件，这个周期可以通过broker端参数log.retention.check.interval.ms来配置，默认值为300,000，即5分钟。当前日志分段的保留策略有3种：

1. 基于时间的保留策略
2. 基于日志大小的保留策略
3. 基于日志起始偏移量的保留策略

3.2.1 基于时间的保留策略

以下三种配置可以指定如果Kafka中的消息超过指定的阈值，就会将日志进行自动清理：

• log.retention.hours
• log.retention.minutes
• log.retention.ms

其中，优先级为 log.retention.ms > log.retention.minutes > log.retention.hours。默认情况，在broker中，配置如下：
log.retention.hours=168
也就是，默认日志的保留时间为168小时，相当于保留7天。

删除日志分段时:
1.从日志文件对象中所维护日志分段的跳跃表中移除待删除的日志分段，以保证没有线程对这些日志分段进行读取操作
2.将日志分段文件添加上“.deleted”的后缀（也包括日志分段对应的索引文件）
3.Kafka的后台定时任务会定期删除这些“.deleted”为后缀的文件，这个任务的延迟执行时间可以通过file.delete.delay.ms参数来设置，默认值为60000，即1分钟。

3.2.2 基于日志大小的保留策略

日志删除任务会检查当前日志的大小是否超过设定的阈值来寻找可删除的日志分段的文件集合。可以通过broker端参数 log.retention.bytes 来配置，默认值为-1，表示无穷大。如果超过该大小，会自动将超出部分删除。

注意:
注意 log.retention.bytes 配置的是 Log 中分区日志文件的大小，而不是单个日志分段（确切地说应该为.log 日志文件）的大小，一个日志文件包含多个日志分段。。单个日志分段的大小由 broker 端参数 log.segment.bytes 来限制，默认值为 1073741824，即 1GB。。

3.2.3 基于日志起始偏移量保留策略

每个segment日志都有它的起始偏移量，如果起始偏移量小于 logStartOffset，那么这些日志文件将会标记为删除。

3.2.4 日志压缩（Log Compaction）

Log Compaction是默认的日志删除之外的清理过时数据的方式。它会将相同的key对应的数据只保留一个版本。

• Log Compaction执行后，offset将不再连续，但依然可以查询Segment
• Log Compaction执行前后，日志分段中的每条消息偏移量保持不变。Log Compaction会生成一个新的Segment文件
• Log Compaction是针对key的，在使用的时候注意每个消息的key不为空
• 基于Log Compaction可以保留key的最新更新，可以基于Log Compaction来恢复消费者的最新状态、、

4. Kafka配额限速机制（Quotas）

生产者和消费者以极高的速度生产/消费大量数据或产生请求，从而占用broker上的全部资源，造成网络IO饱和。有了配额（Quotas）就可以避免这些问题。Kafka支持配额管理，从而可以对Producer和Consumer的produce&fetch操作进行流量限制，防止个别业务压爆服务器。

4.1 限制producer端速率

为所有client id设置默认值，以下为所有producer程序设置其TPS不超过1MB/s，即1048576‬/s，命令如下：

kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --add-config 'producer_byte_rate=1048576' --entity-type clients --entity-default

运行基准测试，观察生产消息的速率

bin/kafka-producer-perf-test.sh --topic test --num-records 500000 --throughput -1 --record-size 1000 --producer-props bootstrap.servers=node1.itcast.cn:9092,node2.itcast.cn:9092,node3.itcast.cn:9092 acks=1

结果：
50000 records sent, 1108.156028 records/sec (1.06 MB/sec)

4.2 限制consumer端速率

对consumer限速与producer类似，只不过参数名不一样。

为指定的topic进行限速，以下为所有consumer程序设置topic速率不超过1MB/s，即1048576/s。命令如下：

bin/kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --add-config 'consumer_byte_rate=1048576' --entity-type clients --entity-default

运行基准测试：

bin/kafka-consumer-perf-test.sh --broker-list node1.itcast.cn:9092,node2.itcast.cn:9092,node3.itcast.cn:9092 --topic test --fetch-size 1048576 --messages 500000

结果为：
MB.sec：1.0743

5. 取消Kafka的Quota配置

使用以下命令，删除Kafka的Quota配置

bin/kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --delete-config 'producer_byte_rate' --entity-type clients --entity-default
bin/kafka-configs.sh --zookeeper node1.itcast.cn:2181 --alter --delete-config 'consumer_byte_rate' --entity-type clients --entity-default