生产故障分析：线程池配置错误导致的阻塞问题

2022-05-04

生产故障分析：线程池配置错误导致的阻塞问题

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/thread-pool-use-error.html 在生产环境中，我们遇到了一个由线程池配置错误导致的阻塞问题。本文将对这个问题进行详细分析，并提出相应的解决方案。问题背景后端在接收到前端用户请求后，会将请求分成4个线程交给一个线程池处理。这4个线程分别负责请求不同的查询接口，以获取查询结果。最后，将这些结果合并并同步返回给前端用户。 12345678910111213141516// 提交任务到线程池waybillNoQueryFuture = submitTask(waybillNoQueryService, waybillNo, currentUserName)orderInfoQueryFuture = submitTask(orderInfoQueryService, waybillNo, currentUserName)appointmentQueryFuture = submitTask(appointme...

2022-09-12

Hystrix熔断优化

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/Hystrix-optimization.html 简述本文说的其实就是合理配置熔断，防止依赖的第三方接口响应过慢导致系统tomcat链接大量阻塞，最终导致系统崩溃的问题顺便，将熔断配置从配置文件中提取出来，动态配置中心中，这样就可以通过动态配置中心来动态配置熔断参数了除此，主要是团队里大家对单线程并发数与QPS概念有些混淆且计算方式了解不多，以及信号量与线程池方案选择上有些歧义，需要花了不少时间在会议上让团队达成一致。背景&分析问题 SISP客服系统、SISP查单系统等系统提供的服务都通过HTTP依赖于大量外部各种接口的响应，这些接口的响应时间不可控，有时候会出现响应时间过长的情况，这时候如果不做任何处理，那么这些请求就会一直等待，这样就会导致系统的响应时间过长，甚至出现系统崩溃的情况。双十一期间，SISP客服系统出现了系统崩溃问题，经排查发现tomcat线程池被耗尽，进一步排查是因为所依赖的PIS接口响应慢了简单来说问题大概长...

2021-05-04

数据库数据倾斜

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/database-skew.html 其实改动不是很大，这里简单记录下背景 OMS订单系统，日数据量较大平均近3kw/日,高峰达8kw+/日的订单需要存到数据库中（之前64库，现在扩到了128库）；运维后台监控看到，各个库的压力不一，江浙沪，京津冀，深圳755等地区对应的数据库压力很高，而其他地区的数据库压力很低；分析数据库通过mycat，以分库号字段进行分库，以内部订单号分表内部订单号规则： 3位分库号+系统来源（2位）+MMDDHHmmssSSS+订单类型+6位随机数+1位校验码=26位分库号生成规则为根据地区、网点进行生成；因此，可以看出，同一地区的订单，分库号是一样的，因此，同一地区的订单，会落在同一个库中；解决直接粗暴修改分库号生成规则为0~127区间随机生成，因为原有订单的删、改、查最终都会带上原有的内部订单号，所以不会影响到历史数据，只是新的订单会落在不同的库中；上线方案因为是S级系统...

2022-01-04

缓存密集加载导致数据库崩溃问题

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/cache-load-database-crash.html 背景 SISP自己基本不存储业务数据，但是每个节点都需要本地缓存了一些网点、员工信息、月结用户信息等基础数据，生产监控发现数据库定期压力飙升，数据库CPU压力到达80+%如图：用脚趾头分析从图中可以看出，每天小时飙升一次，明显就是定时任务大批量查询数据库导致的，在SISP系统，也就只有加载缓存可能会导致找到运维获取慢日志，发现大量的查询语句，如下： 12345SELECT DISTINCT nd.division_code AS city_code, nnd.dist_cn_name , nnd.dist_en_name FROM tm_new_district nd, tm_new_district nnd WHERE nd.division_code IN( SELECT DISTINCT t.CITY_CODE FROM t...

2019-12-12

线上ElasticJob堵塞问题排查

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/elasticJob-bug-fix.html 背景刚进新公司3天正逢双十一，领导生产补数出问题了，补数速度不稳定时快时慢，百万条数据补了好几个小时，之前都是几分钟搞定的，导致通了个宵；早上我早到公司，领导截了个数据库的图给我，说交给我来看，然后刚通宵完的他就去开会汇报去了。。。我还没来得及熟悉环境，就被扔到了火坑里了，压力山大。。。具体的过程没记录,这里只能凭回忆记录下了问题描述给我的截图大概长这样：数据库分库号需要补数的运单数量分库0 12345 分库1 0 分库2 0 … *** 分库31 0 分库32 0 分库32 5w 分库33 4w 分库34 8w … *** 分库128 8w 知道的太少，跟同事了解业务,其实补数就是重推数据,把需要重推的单号记入表中,然后通过ElasticJob定时任务消费表中数据，实现重推数据问题分析没用过Ela...

2021-03-02

记一次ES查询优化

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/ES-Query-Optimization.html 背景难得有数据留存,写一篇^_^ 原逻辑 ES接收新单、改单、状态数据（占总数据的70%），写入ES的7天索引中 ES存在以天为单位的7个索引（如：20210101~20210107，7个索引）存储逻辑：根据订单创建时间，保存到对应月日的索引内，如：1月1日的保存到20210101 如果不再最近7天内的特殊订单,那么会存到今天最新的一天的索引内查询查询: 接收到查单请求后，根据订单创建时间，根据月日指定去查询这7个索引的某一个或多个如果是在最近7天的，那么保存到该日期对应的索引内如果在最近7天以外的订单，那么会保存到今天最新的一天的索引内更新逻辑: 先查询出原来的订单，然后更新，更新后保存到原来的索引内初步分析监控问题分析大数据监控显示：在双十一前后ES监控IO读写次数过高，出现读/写拒绝，CPU占用高，初步分析主要原因有以下：量大：写入ES的数据...