for循环嵌套带来的超长耗时

博客讲述了在增量库存同步过程中,由于for循环嵌套导致的长时间运行问题。当数据量增大时,7万多商品数据运行了3天。经过问题分析,发现是6万对6万的循环运算造成。解决方案是将内层循环改为key-value结构,提高效率。建议避免大数据量的嵌套循环,以提升性能。
摘要由CSDN通过智能技术生成

1.场景描述
我们在做增量库存同步的时候,有这样的逻辑:
(1).从库存系统拿到指定时间到当前时间期间库存变动的货品编码;
(2).从本系统的数据库和redis中拿到本店铺的货品编码[涉及到重复铺货];
(3).取出两者的交集,就是本店铺中这段时间有库存变动的货品编码集合;
(4).用这个交集做入参查询对应的库存;
(5).将这个变动的库存送到淘宝平台;

2.故障现象
如果我们设定的时间距离当前时间比较长,那么运行几乎是假死,其实是运算时间特别长,7万多的商品数据,运行了3天。
这个时间距离长,那么这个时间范围内库存变动的商品量就大,但是也不至于这么长时间。

可以看出,运行时间特别长,需要找出原因。

3.问题分析
这个问题,时间短、数据量小就看不出问题;时间长、数据量大就暴露问题,表面上好像代码逻辑是对的。
最后通过加各种日志到生产环境排查的。

我们可以看到各个地方的数据量有多大,并且每个小步骤运行的时间有多长,问题代码如下:

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值