概述
之前处理过一个购物车故障,觉得还挺经典的,在这里跟大家分享一下。这个故障直接导致前端添加购物车、获取用户购物车列表等操作都失败了。购物车是入口,一旦出现问题,影响极其严重。
临时处理
购物车服务所有接口,是有打印响应时间的,发现比平时慢了很多。由于情况已是十万火急了,我只能先重启购物车,缓冲一下,然后利用这段缓冲时间,赶紧定位问题。
问题定位
之前对购物车应用基于Spring Cloud
微服务化了,已经稳定运行了几个月了,且当时上线前也经过压测,接口性能是没问题的。怎么突然之间就有问题了呢?根据以往的经验,大部分故障都是SQL
语句引起的,因此首先导出数据库的所有慢SQL
(腾讯云有导出慢SQL的工具)语句,发现大部分慢查询都是来自库存查询的SQL
语句,有些甚至是10秒钟才执行完。
后来仔细一看,库存慢查询语句,要查询库存的商品比平时多很多。商品个数少的话,这条语句还是非常快的,一旦多了就开始慢了。
解决方案
由于库存计算体系的历史原因,这条SQL
是很难优化的。情况又是十万火急的,大老板一直在问咋回事。因此临时改代码,将商品库存放到Redis
缓存起来。购物车服务的话,是允许库存数据不实时的,因为后面的结算和支付会实时计算库存,库存不足的时候,会提示用户的。
注意:
- 由于购物车是入口,流量很大,而从购物车到结算页再到支付,由于有一个操作步骤,因此结算页和支付页的流量是没有购物车那么大的;
- 部分用户购物车上的商品数据是非常多的,但是未必都会买,用户也可以勾选要买的商品,然后下单;
- 部分用户没有清理购物车失效商品的习惯,导致购物车上的商品非常多。
终极解决方案
将库存服务独立出去,将商品库存数据放置到缓存,并引入实时刷新缓存中库存数据的机制,让缓存中的数据尽量保证新鲜。这样的话,查询库存的时候,大部分都可以从缓存中获取,不会穿透到数据库上。
补充
我们对接口进行压测的时候,部分场景下,要考虑入参的个数,不能简单的用几个数据压测,觉得性能OK就不管了。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。如果你想了解更多相关内容请查看下面相关链接
更新动态
- 小骆驼-《草原狼2(蓝光CD)》[原抓WAV+CUE]
- 群星《欢迎来到我身边 电影原声专辑》[320K/MP3][105.02MB]
- 群星《欢迎来到我身边 电影原声专辑》[FLAC/分轨][480.9MB]
- 雷婷《梦里蓝天HQⅡ》 2023头版限量编号低速原抓[WAV+CUE][463M]
- 群星《2024好听新歌42》AI调整音效【WAV分轨】
- 王思雨-《思念陪着鸿雁飞》WAV
- 王思雨《喜马拉雅HQ》头版限量编号[WAV+CUE]
- 李健《无时无刻》[WAV+CUE][590M]
- 陈奕迅《酝酿》[WAV分轨][502M]
- 卓依婷《化蝶》2CD[WAV+CUE][1.1G]
- 群星《吉他王(黑胶CD)》[WAV+CUE]
- 齐秦《穿乐(穿越)》[WAV+CUE]
- 发烧珍品《数位CD音响测试-动向效果(九)》【WAV+CUE】
- 邝美云《邝美云精装歌集》[DSF][1.6G]
- 吕方《爱一回伤一回》[WAV+CUE][454M]