性能文章>业务逻辑复杂,历史久远的接口出现数据错误怎么办?>

业务逻辑复杂,历史久远的接口出现数据错误怎么办?原创

5月前
216756

接口返回数据错误,如何快速找到问题原因并进行修复?

01背景

1.1 下班时,业务反馈:线上数据错了

1.2 分析

找前端同学确认控制“点击咨询期货”是由接口返回的“skuLt”字段控制:

02BugShooting

2.1 排查思路1:梳理接口逻辑找到原因

业务太复杂链路太长,难以快速找到重点

数据链路长,业务逻辑多,难以快速找到原因。。。

这是2-3年前的代码了,上线后就没有再去过了,都不记得了。

想快速fix bug,通过梳理业务逻辑较难以办到。梳理业务逻辑,放到第二象限。看看有没有别的办法可以快速bugshooting

2.2 换个思路:同样的接口,为什么有的sku信息是正确的呢?

 

会不会是因为这些参数关联的sku不同导致的?
譬如“爆款精选”中的有一些特殊的sku信息缺失,导致获取"skuLt"时出现了未知错误

✪ 查询参数不同的原因?

这个地方的确应该不同,线索断了。

走,去看看日志中有没有其它线索

✪ 日志

“爆款精选”楼层的接口有报错信息!

问题是,这两个sku是存在的,且可以正常展示:

并且,sku信息有缓存,不应该再次去【商品中心中台】去查!

✪ 很可能是查询参数的问题!

果然:

请求参数果然有问题!

"%C2%A0"被转换为空格字符" ",因为它是URL编码中表示空格字符的形式。

ChatGPT3

✪ 错误的数据是从哪来的?

配置的数据就是错的!

 

解决办法:通过后台管理把这个“空格”删除就好了。

如果有两种或两种以上的方式去做某件事情,而其中一种选择方式将导致灾难,则必定有人会做出这种选择。

墨菲定律
在整个数据链路上,只要有任何一个地方对sku编号进行trim操作,都不会引发这个问题。
但,没有一个地方!!!

03小结

3.1 业务场景

1、线上出现问题,通过梳理业务逻辑不能快速fix bug

2、分析接口发现:接口相同,有的正确,有的错误,怀疑有错误的入参

3、分析日志:发现有报错,且报错的代码与当前bug业务域相同

4、发现配置的参数有错误

5、更改错误的参数,问题解决。

 

点赞收藏
bit01
请先登录,查看5条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

【全网首发】一次NSF FeignClient支持Apache HttpClient的优化

【全网首发】一次NSF FeignClient支持Apache HttpClient的优化

麻了啊!一个烂分页,踩了三个坑!

麻了啊!一个烂分页,踩了三个坑!

几行代码轻松复现druid连接泄露的BUG之keepalive

几行代码轻松复现druid连接泄露的BUG之keepalive

JVM coredump分析系列(5):使用netty-tcnative出现SIGSEGV crash分析

JVM coredump分析系列(5):使用netty-tcnative出现SIGSEGV crash分析

6
5