searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

Kafka常见问题及解决方案

2023-08-18 09:59:11
71
0

       Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写,Kafka是一种高吞吐量的分布式发布订阅消息系统,具有高吞吐量、高可靠性、分布式、水平扩展等优点,适用于大规模、高并发、高可靠的数据处理和通信场景。
       针对Kafka 在实际应用中可能遇到的各种故障,下面列举几种常见的情况和解决方案:
1、怎么保证数据不丢失
1)生产者数据不丢失
Kafka的ack机制:在kafka发送数据的时候,每次发送消息都会有一个确认反馈机制,确保消息正常能够被收到,其中有3个状态
ack = 0:producer不等待broker同步完成的确认,继续发送下一条(批)信息。
ack = 1(默认):producer要等待leader成功收到数据并确认,才发送下一条message。
ack = -1:producer得到follower确认,才发送下一条数据。
对于同步模式:ack一般不建议设置为0,即使设置为1,也会随着leader宕机丢失数据,如果要严格保证生产端数据不丢失,可设置为-1。
对于异步模式:通过buffer来进行控制数据的发送,有两个值来进行控制,时间阈值与消息的数量阈值,如果buffer满了数据还没有发送出去,有个选项是配置是否立即清空buffer,可以设置为-1,永久阻塞,也就数据不再生产,在异步模式下,即使设置为-1,也存在不规范操作导致数据丢失,比如kill -9。
2)消费者数据不丢失
通过offset commit来保证数据的不丢失,kafka每次记录消费的offset数值,下次继续消费时会按上次的offset进行消费。offset信息在kafka0.8版本之前保存在zookeeper中,在0.8版本后保存到topic中,即使消费者在运行过程中挂掉了,再次启动时会找到之前消费消息的位置接着消费,由于 offset 的信息写入时不是每条消息消费完后都写入,所以可能会造成重复消费,但不会丢失消息。唯一例外的情况是,在程序中给原本做不同功能的两个consumer组设置 KafkaSpoutConfig.bulider.setGroupid的时候设置成了一样的groupid,会导致这两个组共享同一份数据,就会产生组A消费partition1、partition2中的消息,组B消费partition3的消息,这样每个组消费的消息都会丢失, 为了保证每个组都独享一份消息数据,groupid不能重复。
3)broker数据不丢失
每个broker中的partition一般设置有replication(副本)个数,生产者写入的时候首先根据分发策略(有partition按partition,有key按key,都没有按轮询)写入到leader中,follower(副本)再跟leader同步数据,有了备份也可以保证消息数据不丢失。
2、消息乱序问题
发送端配置了重试机制的话,kafka不会等之前那条消息完全发送成功才去发送下一条消息,这样会出现消息乱序,为保证全链路消息顺序消费,需要从发送端开始,将所有有序消息发送到同一个分区,然后用一个消费者去消费,但是这种性能比较低,可以在消费者端接收到消息后将需要保证顺序消费的几条消费发到内存队列(可以搞多个),一个内存队列开启一个线程顺序处理消息。
3、Kafka 幂等性问题
 生产者Producer幂等性是指当发送同一条消息时,数据在 Server 端只会被持久化一次,数据不丟不重,不过幂等性满足以下条件。
1)只能保证 Producer 在单个会话内不丟不重,如果 Producer 出现意外挂掉再重启是无法保证的,幂等性情况下无法获取之前的状态信息,故无法做到跨会话级别的不丢不重。
2)幂等性不能跨多个 Topic-Partition,只能保证单个 Partition 内的幂等性,当涉及多个Topic-Partition 时,这中间的状态并没有同步。
4、kafka节点宕机问题
当 Kafka 集群中某个节点宕机时,会导致数据不一致、数据丢失等问题,建议使用多副本机制,在各个节点之间进行数据的同步和复制,保证集群中的节点宕机时,数据不会丢失。
5、leader 选举问题
当 Kafka 集群中的 leader 节点宕机时,Kafka 会选举新的 leader 节点来提供服务。但是,某些情况下可能会存在 leader 选举失败或延时的情况。解决方案可以通过调整 Kafka 配置来提高 leader 选举的成功率和速度,如调整 `unclean.leader.election.enable` 参数,增加重新选举的次数等。
6、消费者无法获取数据问题
当 Kafka 消费者无法获取数据时,可能是由于消费者程序出现故障,也有可能是 Kafka 本身存在问题。解决方案可以通过检查消费者程序的运行日志,查看 Kafka 服务器的运行日志,以及检查网络配置等方面来排查问题。
7、消息积压问题
1)当 Kafka 队列中存在大量的未处理消息时,可能会导致消息积压和延迟。解决方案可以通过优化 Kafka 集群的性能,增加消费者数量,以及增加分区数等方案来提高 Kafka 的吞吐量。
2)消息数据处理不及时,提高每批次拉取的数量,批次拉取数据过少(拉取数据/处理时间<生产速度),使处理的数据小于生产的数据,也会造成数据积压。
       总而言之,需要从Kafka的硬件配置、软件设置、运维流程等方面进行全面的规划、设计和实践,并结合业务应用运行情况,不断地进行部署优化和性能优化,来保障 Kafka 集群的高可用性和高性能。

0条评论
作者已关闭评论
赖****生
9文章数
0粉丝数
赖****生
9 文章 | 0 粉丝
原创

Kafka常见问题及解决方案

2023-08-18 09:59:11
71
0

       Kafka是由Apache软件基金会开发的一个开源流处理平台,由Scala和Java编写,Kafka是一种高吞吐量的分布式发布订阅消息系统,具有高吞吐量、高可靠性、分布式、水平扩展等优点,适用于大规模、高并发、高可靠的数据处理和通信场景。
       针对Kafka 在实际应用中可能遇到的各种故障,下面列举几种常见的情况和解决方案:
1、怎么保证数据不丢失
1)生产者数据不丢失
Kafka的ack机制:在kafka发送数据的时候,每次发送消息都会有一个确认反馈机制,确保消息正常能够被收到,其中有3个状态
ack = 0:producer不等待broker同步完成的确认,继续发送下一条(批)信息。
ack = 1(默认):producer要等待leader成功收到数据并确认,才发送下一条message。
ack = -1:producer得到follower确认,才发送下一条数据。
对于同步模式:ack一般不建议设置为0,即使设置为1,也会随着leader宕机丢失数据,如果要严格保证生产端数据不丢失,可设置为-1。
对于异步模式:通过buffer来进行控制数据的发送,有两个值来进行控制,时间阈值与消息的数量阈值,如果buffer满了数据还没有发送出去,有个选项是配置是否立即清空buffer,可以设置为-1,永久阻塞,也就数据不再生产,在异步模式下,即使设置为-1,也存在不规范操作导致数据丢失,比如kill -9。
2)消费者数据不丢失
通过offset commit来保证数据的不丢失,kafka每次记录消费的offset数值,下次继续消费时会按上次的offset进行消费。offset信息在kafka0.8版本之前保存在zookeeper中,在0.8版本后保存到topic中,即使消费者在运行过程中挂掉了,再次启动时会找到之前消费消息的位置接着消费,由于 offset 的信息写入时不是每条消息消费完后都写入,所以可能会造成重复消费,但不会丢失消息。唯一例外的情况是,在程序中给原本做不同功能的两个consumer组设置 KafkaSpoutConfig.bulider.setGroupid的时候设置成了一样的groupid,会导致这两个组共享同一份数据,就会产生组A消费partition1、partition2中的消息,组B消费partition3的消息,这样每个组消费的消息都会丢失, 为了保证每个组都独享一份消息数据,groupid不能重复。
3)broker数据不丢失
每个broker中的partition一般设置有replication(副本)个数,生产者写入的时候首先根据分发策略(有partition按partition,有key按key,都没有按轮询)写入到leader中,follower(副本)再跟leader同步数据,有了备份也可以保证消息数据不丢失。
2、消息乱序问题
发送端配置了重试机制的话,kafka不会等之前那条消息完全发送成功才去发送下一条消息,这样会出现消息乱序,为保证全链路消息顺序消费,需要从发送端开始,将所有有序消息发送到同一个分区,然后用一个消费者去消费,但是这种性能比较低,可以在消费者端接收到消息后将需要保证顺序消费的几条消费发到内存队列(可以搞多个),一个内存队列开启一个线程顺序处理消息。
3、Kafka 幂等性问题
 生产者Producer幂等性是指当发送同一条消息时,数据在 Server 端只会被持久化一次,数据不丟不重,不过幂等性满足以下条件。
1)只能保证 Producer 在单个会话内不丟不重,如果 Producer 出现意外挂掉再重启是无法保证的,幂等性情况下无法获取之前的状态信息,故无法做到跨会话级别的不丢不重。
2)幂等性不能跨多个 Topic-Partition,只能保证单个 Partition 内的幂等性,当涉及多个Topic-Partition 时,这中间的状态并没有同步。
4、kafka节点宕机问题
当 Kafka 集群中某个节点宕机时,会导致数据不一致、数据丢失等问题,建议使用多副本机制,在各个节点之间进行数据的同步和复制,保证集群中的节点宕机时,数据不会丢失。
5、leader 选举问题
当 Kafka 集群中的 leader 节点宕机时,Kafka 会选举新的 leader 节点来提供服务。但是,某些情况下可能会存在 leader 选举失败或延时的情况。解决方案可以通过调整 Kafka 配置来提高 leader 选举的成功率和速度,如调整 `unclean.leader.election.enable` 参数,增加重新选举的次数等。
6、消费者无法获取数据问题
当 Kafka 消费者无法获取数据时,可能是由于消费者程序出现故障,也有可能是 Kafka 本身存在问题。解决方案可以通过检查消费者程序的运行日志,查看 Kafka 服务器的运行日志,以及检查网络配置等方面来排查问题。
7、消息积压问题
1)当 Kafka 队列中存在大量的未处理消息时,可能会导致消息积压和延迟。解决方案可以通过优化 Kafka 集群的性能,增加消费者数量,以及增加分区数等方案来提高 Kafka 的吞吐量。
2)消息数据处理不及时,提高每批次拉取的数量,批次拉取数据过少(拉取数据/处理时间<生产速度),使处理的数据小于生产的数据,也会造成数据积压。
       总而言之,需要从Kafka的硬件配置、软件设置、运维流程等方面进行全面的规划、设计和实践,并结合业务应用运行情况,不断地进行部署优化和性能优化,来保障 Kafka 集群的高可用性和高性能。

文章来自个人专栏
容器与中间件
9 文章 | 1 订阅
0条评论
作者已关闭评论
作者已关闭评论
0
0