隔壁老王呀的专栏

根本原因已经消费的数据，但是offset没有成功提交具体情况：1. 消费者宕机、重启，导致消息已经消费但是未提交offset。2. 消费者处理比较耗时，一次poll的数据，在max.poll.interval.ms达到最大值后仍未完成，未提交offest，触发rebalance。3. 消费者使用自动提交offset，但当还没有到auto.commit.interval.ms的时间，没来的及提交。有新的消费者加入或者移除，发生了rebalance。4. 超过session.timeout.ms

1. 增大partition个数2. 增加消费者数量3. 消费堆积数据入库保存4. 减少consumer处理时长5. 避免产生rebalance注意：同一个消费群组的consumer个数要等于partition个数，这样能让consumer的消费能力提升到最大。

公司的一哥们在使用事务时未进行commit，链接断开后数据库执行了回滚操作，导致线上直播相关库的部分数据丢失，本文通过mysql命令行模拟该事故，并提供解决该问题的思路。希望对大家有帮助。一、场景模拟二、紧急处理三、原因分析四、相关命令1、查看正在执行的事务2、查看正在锁的事务3、查看等待锁的事务4、查看所有的线程列表5、定位未提交的事务执行的sql语句

文章目录1、查看内存占用高的进程2、查看对象个数和占用内存大小3、导出内存镜像4、安装独立版本的Memory Analyzer工具5、使用MAT工具进行分析6、注意以下代码没有特殊说明，都是指终端命令行操作1、查看内存占用高的进程top2、查看对象个数和占用内存大小jmap -histo 624可以看到程序中各个对象所占用内存的情况，根据占用字节数大小降序显示，这里只能看出哪些对象占用内存高，但是还不能具体定位到问题代码，需要进一步排查。有个自定义的类Animal，个数和占用内存比较高

文章目录1、查看占用CPU高的进程2、查看服务线程信息3、查看问题线程状态4、jstack查看线程信息5、代码问题排查以下代码没有特殊说明，都是指终端命令行操作1、查看占用CPU高的进程top2、查看服务线程信息ps -mp 183 -o THREAD,tid,time3、查看问题线程状态通过上一步，我们可以看到TID为220的线程占用cpu比较高。转化为16进制方便后续查询。printf "%x\n" 220查看该线程运行状态。jstack 183 | grep dc