2018年05月31日 13:26:59 xiaoguozi0218 阅读数:2018更多 个人分类: 大数据   年后上线的系统,与其他业务系统的通信方式采用了第三代消息系统中间件Kafka.由于是第一次使用,踩了很多坑,通过这篇博客和大家分享一下,也算是做个总结,以便以后温故而知新. 一.线上问题 系统平稳运行两个多月,基本上没有问题,知道最近几天,突然出现Kafka手动提交失败,堆栈信息如下: 通过堆栈信息可以看出,有两个重要参数: session.timeout  和 max.poll.…

线上kafka消息堆积,所有consumer全部掉线,到底怎么回事? 最近处理了一次线上故障,具体故障表现就是kafka某个topic消息堆积,这个topic的相关consumer全部掉线. 整体排查过程和事后的复盘都很有意思,并且结合本次故障,对kafka使用的最佳实践有了更深刻的理解. 好了,一起来回顾下这次线上故障吧,最佳实践总结放在最后,千万不要错过. 1.现象 线上kafka消息突然开始堆积 消费者应用反馈没有收到消息(没有处理消息的日志) kafka的consumer group上看…

文章首发于[陈树义的博客],点击跳转到原文<线上Kafka突发rebalance异常,如何快速解决?> Kafka 是我们最常用的消息队列,它那几万.甚至几十万的处理速度让我们为之欣喜若狂.但是随着使用场景的增加,我们遇到的问题也越来越多,其中一个经常遇到的问题就是:rebalance(重平衡)问题. 什么是消费组 要想了解 rebalance,那就得先了解消费组(consumer group). 消费组指的是多个消费者(consumer)组成起来的一个组,它们共同消费 topic 的所有消息…

记一次线上bug排查,与各位共同探讨. 概述:使用quartz做的定时任务,正式生产环境有个任务延迟了1小时之久才触发.在这一小时里各种排查找不出问题,直到延迟时间结束了,该任务才珊珊触发.原因主要就是后台有几个5分钟一刷的定时任务,调度器不停的调度后台任务,阻塞了别的任务,出现了问题. 本文主要目的:1.记录排查过程(思路): 2. 分析quartz的线程调度规则: 3. 针对本问题的相关解决方案: 排查过程:1…

解Bug之路-记一次线上请求偶尔变慢的排查 前言 最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章. Bug现场 这是一个偶发的性能问题.在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过1s,让我们业务耗时监控的99.99线变得很尴尬.如下图所示: 为了精益求精,更为了消除这个尴尬的指标,笔者开始探寻起这100多慢请求笔的原因. 先找一笔看看 由于笔者写的框架预留了traceId,所以找到这笔请求的整个调用的链路还是非常简单的. 而且…

1.事故背景 上周三凌晨,我负责的某个模块在多台机器上连续发生coredump,幸好发生在业务低峰期,而且该模块提供的功能也不是核心流程功能,所以对线上业务影响比较小.发生coredump后,运维收到报警后立马拉起了服务,服务宕机时间为3分钟左右. 2.事故分析 第二天立即组织了事故分析小组,对事故发生原因进行了排查,coredump的时候JVM保存了coredump文件,运维帮忙转换成了问题分析结果文件,如下 ## There is insufficient memory for the Ja…

线上某dubbo服务A调用dubbo服务B的接口X方法,调用端A日志中出现了很多超时的情况,提供端B该接口X超时时间设置为60s: 查看提供端B的日志,报了很多线程池满的异常: Caused by: java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-10.1.5.69:20914, Pool Size: 700 (active: 70…

收到某业务组的小伙伴发来的反馈,具体问题如下: 项目中某 kafka 消息组消费特别慢,有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组. 从服务端日志看到如下信息: 该消费组在短时间内重平衡了 600 多次. 从 cat 查看得知,每条消息处理都会有 4 次数据库的交互,经过一番沟通之后,发现每条消息的处理耗时大概率保持在 200ms 以上. Kafka 发生重平衡的有以下几种情况: 消费组成员发生变更,有新消费者加入或者离开,或者有消费者崩溃: 消费组订阅的主题数量发…

   为了同学们看起来一目了,特按如下思路进行讲解. 1.出现的场景    2.分析及解决的过程    3.总结 最近公司要使用zookeeper做配置管理(后面简称ZK),然后自己就提前用虚拟机进行了ZK三台集群的搭建.之后开始选择使用zookeeper的java client工具,google了半天,发现了一个很名强大的Apache的Curator工具,很多底层的东西都已经给你封装好了,所以用起来很方便,因为我使用的场景是做配置管理,所以使用Curator的Framework就够了.Cura…

今天线上的hadoop集群崩溃了,现象是namenode一直在GC,长时间无法正常服务.最后运维大神各种倒腾内存,GC稳定后,服务正常.虽说全程在打酱油,但是也跟着学习不少的东西. 第一个问题:为什么会频繁GC 有过JVM经验的开发者都应该知道,GC是在内存不够时,JVM自动进行的自我救赎(删除不用的数据,释放内存空间).那么NameNode在什么情况下会进行GC呢?在解释这个问题之前,需要明白GC的几种级别,以及触发的条件: Minor GC:清理新生代,一般都是复制回收算法 Full GC:…