报错（未解决）：Offsetcommitfailedonpartitionxxxatoff。。。
1.报错背景
服务器：Linux集 3台，32GB内存；
Kafka创建了⼤约140个Topic，和与Topic数⽬相同的Consumer，设置分区数量不祥；
每个Consumer都在GroupId，没有单独的standalone consumer；
项⽬在运⾏过程中突然出现了⼤量分区提交失败的现象。
2.报错现象
报错截图
报错⽇志（保密原因，groupId做过处理）
2020-04-28 at 16:59:36 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-1158, groupId=144rrr4001020008SYS18] Offset comm 2020-04-
28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-1330, groupId=144rrr4001020001SYS01] Offset comm 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-93, groupId=144rrr4001020012SYS02] Offset commit 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-872, groupId=144rrr4001020010SYS20] Offset commi 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-16, groupId=144rrr4001020012SYS03] Offset commit 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-820, groupId=144rrr4001020010SYS20] Offset commi 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 8
67 handle - [Consumer clientId=consumer-912, groupId=144rrr4001020003SYS01] Offset commi 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-719, groupId=144rrr4001020002SYS01] Offset commi 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-250, groupId=144rrr4001020006SYS18] Offset commi 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-66, groupId=144rrr4001020012SYS02] Offset commit 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-277, groupId=144rrr4001020004SYS03] Offset commi 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-880, groupId=144rrr4001020010SYS20] Offset commi 2020-04-28 at 16:59:37 CST traceId:[] ERROR org.apache.sumer.internals.Consumer
Coordinator$OffsetCommitResponseHandler 867 handle - [Consumer clientId=consumer-488, groupId=144rrr4001020009SYS01] Offset commi
3.报错原因
依据⽹上资料进⾏⼤胆猜测：
第⼀步
分析触发报错的直接原因：
Offset commit failed on partition 001020004SYS03-3 at offset 390: The coordinator is not aware of this member.
翻译过来：Offset提交失败，Kafka的group协调器不认识该成员。
第⼆步
分析造成Kafka的group协调器不认识该成员的原因：
（1）Consumer中出现单独的standalone consume，⽽且standalone consume的名字和某个GroupId名
字相同，这种现象就会触发报错，具体原因我未深究，因为本项⽬没有
standalone consume存在；
（2）组成员“崩溃”，造成kafka被动Rebalance，这样就会触发The coordinator is not aware of this member.报错，我猜测我的报错可能就是这个原因。
因为在崩溃时成员并不会主动地告知coordinator此事，coordinator有可能需要⼀个完整的session.timeout周期(⼼跳周期)才能检测到这种崩溃，这必然会造成consumer的滞后。
可以说离开组是主动地发起rebalance；⽽崩溃则是被动地发起rebalance。
第三步
分析造成组成员“崩溃”的原因：
他这⾥⾯的原因和我问题的原因可能不是相同，但是也可以作为⼀个排除点来看⼀下。
查看Linux的软硬连接限制数：
ulimit -Hn
ulimit -Sn
查看kafka创建链接数：
ls /proc/[kafka进程号]/fd | wc -l
看是否超出了Linux的最⼤限制
第四步
后来发现上⾯的原因分析有点⾛偏了，都开始系统的错误了，肯定是我的某些地⽅做错了。
再分析，分析造成Kafka的group协调器不认识该成员的原因：
很有可能是因为⼼跳检测已经检测不到它了，所以⼩组管理员就默认它死掉了，但是它真的死了吗？可能还没有。有可能只是它在忙别的事情，没听到组长叫它，所以就认定死
亡了，继⽽⼜被活埋了。造成了⾃动提交offset失败。
第五步
分析⼼跳检测失败的原因：
session数据错误是什么意思⼀般来说producer的⽣产消息的逻辑速度都会⽐consumer的消费消息的逻辑速度快，当producer在短时间内产⽣⼤量的数据丢进kafka的broker⾥⾯时，kafka的consumer会出现
以下⾏为：
（1）kafka的consumer会从broker⾥⾯取出⼀批数据，给消费线程进⾏消费；
（2）由于取出的⼀批消息数量太⼤，consumer在session.timeout.ms时间之内没有消费完成；
（3）consumer coordinator会由于没有接受到⼼跳⽽挂掉，并且出现⼀些⽇志（报错⽇志在上⾯）；
（4）⽇志的意思⼤概是coordinator挂掉了，然后⾃动提交offset失败，然后重新分配partition给客户端；
（5）由于⾃动提交offset失败，导致重新分配了partition的客户端⼜重新消费之前的⼀批数据；
（6）接着consumer重新消费，⼜出现了消费超时，⽆限循环下去。
这应该是报错的⼀个重要原因。
4.报错解决
第⼀步
查看kafka的进程号
第⼆步
进⼊kafka的进程⽬录查看：
cd /proc/11298/fd
可以看到⾥⾯有很多软连接，⽽且绝⼤多数都是失效的软连接，这样就很懵逼了，不知道这是什么操作。但是可以看到⾥⾯还有⼏个正常的⽇志⽂件，挨个打开看⼀下。
第三步
查看log⽂件，看看有没有异常
查看controller.log
第四步
上⾯这条路⾛不通了! 换了⼀条路...
针对上⾯原因第五步，提出优化⽅案：
（1）配置⽅⾯，要使consumer和patition⼀⼀对应，如果有多个patition，最好要均衡每个patition的数据量，防⽌出现数据倾斜，导致某个consumer挂掉；
（2）配置⽅⾯，提⾼了partition的数量，从⽽提⾼了consumer的并⾏能⼒，从⽽提⾼数据的消费能⼒；
（3）配置⽅⾯，automit.interval.ms ⼤⼀点，但是治标不治本；
（4）对于单partition的消费线程，增加了⼀个固定长度的阻塞队列和⼯作线程池进⼀步提⾼并⾏消费的能⼒（未验证过）；
（5）代码⽅⾯，把kafka-client的enable.automit设置成了false，表⽰禁⽌kafka-client⾃动提交offset，下⾯是我们项⽬中的⾃动提交设置，把它设置成flase，很有可能是⼀个优化点，但是这⾥设置成⼿动提交可能会有未知错误产⽣，要验证⼀下。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。