最近两年部门同事们找我解决过挺多问题的,都有记录下来,时不时我还会回顾一下,避免踩坑。也有一些是当我知道别人最近踩过了坑,我也会记录起来
- E系统某电商平台调用下单超时问题排查,排查了两个星期没解决。找到我,我尝试了抓包使用wireshark分析,使用arthos监控线上代码等方式,排查了好久。最终发现是一个细节问题导致的,原因是虽然Feign线程池配了1000,但Feign 默认线程池(httpClient)配置每个域名最大并发链接数为50(per router),httpClient连接池除了设置maxTotal以外,还需设置maxPerRoute
- X系统业务出错,业务方配置出错,同步数据先后,缓存导致不一致
- Oracle数据库,durid开启cachePrepareStatment会导致表在线加字段报错,因为prepareStatment被缓存了,加了字段还用原来的prepareStatment就会报错
- (某系统生产表现为kafka一直rebalance,领导让我分析下原因),分析原因为Oracle连接池长个别连接太久没通信被防火墙掐断,形成了一个数据包黑洞,当使用这种连接执行sql,由于odbc一直发送数据包都被丢包了,由于tcp超时重传(指数退避算法),需要9分钟才会向odbc抛出网络异常。消费卡住了,所以kafka每隔几分钟进行一次rebalance。解决方案,连接池增加心跳机制keepalive。
- 领导让我排查一个kafka报错CommitFailException最终导致丢消息的问题,业务代码排查了很久没有问题。最终读中间件团队封装客户端,发现一个线程PackThread 打包存在线程安全问题,最终提交问题给中间团队,受到了中间件团队群里表扬。
- S系统的同事让我看个问题,客户端请求接口超时,但服务端日志显示执行时间很短。通过tcpdump抓包排查下来是客户端网络不好。因为一个大的json文件发送给客户端要算时间的。
- 同事使用ES _id 排序,把ES内存打爆,需要使用doc_values代替。禁止使用fieldData类型排序
- 同事使用索引未设置合适分片,导致单块磁盘打爆,es锁定变只读
- 同事扩容遇到一个坑,有个系统Kafka在线扩容导致消息丢失,了解下来消费者auto.offset.reset=latest。在rebalance好之前,新分区被写入了n条数据,然后新分区offset reset为n + 1, 导致消费丢消息了。
- P系统同事使用mybatis 一级索引引发的问题,代码对查询出来的对象进行了赋值,导致别的地方再查询,从缓存取到了缓存对象,从而获取到了错误的值。
- 某系统同事删除数据库表分区后,导致全局索引不可用(失效),产生大量慢查询。Oracle删除分区需要谨慎 https://www.modb.pro/db/14033
- 领导说有个系统oracle数据库in超过1000个会报错,让各系统排查下所有in
- 同事找到我,说指定了同一个key,发到了不同的Partition,排查了一个星期没有找到问题。我当时给的思路是看看partioner组件配置是否一致。最终同事告诉我原因是,中间的kafka客户端同事支持0.8和2.5,客户端请求版本超时,导致使用了0.8的client版本。当然0.8和2.5的client的partioner组件算法是不一样的。kafka版本不一致,导致同一个分区key发送到了不同的partition,导致消息乱序。原因是不同版本的patitioner分区算法不一样
- 我在设计的时候,在思考热点数据问题,有一个热点的结算账户,其他账户都和它结算,考虑可通过拆分子账户的方式避免热点账户问题
- 一个基于redis的消费幂等解决,使用redis存储消费消息的id。消费幂等问题,发生并发消费,轮训消费结果。重复消费幂等
- 领导说O系统加字段的时候,mycat select * 导致报错,原因是每个分片加字段的速度不一样,导致一个查询有的查询查到是3个字段,有的是4个字段,mycat做聚合时报错。所有字段需要指定字段。让我们注意一下。
- S系统遇到spring data mongo报IllegalArgumentException,帮忙排查,我没找到原因。最终在spring的github找到了issue,原因是Spring底层有个Lazy类有bug,少写了volatile
- 我最近遇到的问题是bigint类型调用max(id) min(id)结果不对,mycat merge分片结果时按照字符串排序而不是整形返回了max和min。文档上没有写,自己通过填充0解决。select max(id) from (select lpad(max(id), 18, ‘0’) as id from js_charge_result) t; 每个单库返回maxId的时候填充0,在外层再求一次max,这样可以走到主键索引。
- X系统信号量限流没有考虑重入场景,导致信号量用完死锁。解决方法,修改为可重入的。
- 全链路压测loadClass死锁,原因待排查,最终发现是全链路压测的agent和apm的agent有冲突导致的
- X系统压测消费速率速率怎么都上不去,mycat、mysql cpu、IO都不高,消费能力上不去。最终发现mycat上层的LB网卡瓶颈导致
- 容灾库一条超慢查询导致所有查询阻塞。最终向DBA请教。原因是:容灾有备份任务,备份的时候要flush table,查询就会阻塞这个flush table的操作,后续所有的查询又会被flush table堵住
- 我们配置一个账号到application.yml,配置值以0开头被spring自动当做8进制转换了,幸好在测试环境验证出来了
- 大数据计算数据汇总,由于数据表是按照update_time >= ‘前一天’ && update_time < '今天’抽取到大数据hive,每天1点执行,如果一个数据在昨天更新了,今天0点之后又更新了,就会导致这个条件拉不到数据。发生数据漂移问题。解决方案有两个1. 只用update_time >= '前一天’抽取到hive 2.使用binlog + flink + hudi + hive 实时数据湖方式抽取数据。
- S系统让帮忙看个问题。记一次循环依赖导致的bean初始化方法被调用时报NPE。本地无法复现,测试环境可以复现,我说可以使用测试环境远程调试-Xdebug -Xrunjdwp:transport=dt_socket,address=8888,server=y,suspend=y,最终我排查发现Bean有循环依赖,然后bean的init方法调用时,依赖注入还没有注入,导致NPE,因为本地环境和测试环境 bean 的初始化顺序不一样,所以测试环境才能复现。还有一种会依赖的bean没注入报NPE错是bean没有经过spring IOC容器管理,如自己不小心new了一个Service