【从2023往前回顾两年——2021-2022的填坑日记】

最近两年部门同事们找我解决过挺多问题的，都有记录下来，时不时我还会回顾一下，避免踩坑。也有一些是当我知道别人最近踩过了坑，我也会记录起来

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