项目结构采用了star方法,Situation:概括性的总结业务背景和挑战;Task:介绍你负责的任务已经需要达成的目标;Action:项目中你采取的关键行动;Result:项目落地后的实际效果。本文是项目实战第十七讲:使用异步编排优化商品详情页
文章目录
-
-
- 1、项目背景
- 2、主要技术
- 3、项目职责
- 4、项目实现
-
- 4.1、表结构
- 4.2、CompletableFuture异步编排背景知识
- 4.3、异步编排在商品详情页的使用(对外流量最大)
- Action1、商品详情页如何加速查询
- Action2:为什么数据存放Redis时,使用Md5加密
- Action3:存放数据时,是将集合转换为Redis key,会不会导致key的数据太多
- Action4:使用 MongoDB 保存商品属性数据,是更合适的选择
- Action5:商品列表页中有个价格字段,如果商品为多sku,那么这个价格是哪个sku的价格?
- Action6:商品列表页中有个库存字段,如果商品为多sku,那么这个库存字段是怎么计算出来的?
- Action7:发商品外挂 --商业模式:政采云外挂分析
- Action8:用户下单这个时刻,正好赶上商品调价,就有可能出现这样的情况:我明明在商详页看到的价格是 10 块钱,下单后,怎么变成 15 块了?你的系统是不是偷偷在坑我?
- Action9:Executor程序在debug时不执行
- 收获
- 5、项目结果
-
1、项目背景
商品中心提供对外使用,最重要的接口就是商品详情页,需要着重考虑两个问题
- 1、高并发的问题
- 目前商品详情页的日均调用量:
- 在设计存储的时候,如果没有考虑到高并发的问题,大促的时候,支撑商详页的商品中心系统必然是第一个被流量冲垮的系统。
- 2、商品数据规模的问题
- 目前
batchFindFullDetail内部会根据条件起14个任务查询不同的信息,返回的数据庞大,且内部对db和外部接口调用较多。 - 商品详情页在业务高峰期频繁超时,导致下游业务受到影响;
- 目前
- 难点:商详页是整个系统中日均访问次数最高的页面之一, 数量多(4亿一千万商品、11.3亿sku),重量大(商详页包含了大量文字、图片)
- 目标:降低db操作和外部调用;
2、主要技术
使用了设计模式
1、职责链模式,一次调用每一条规则
2、模板模式,提供了拓展点让子类实现
3、泛型编程,提供抽象父类
3、项目职责
项目职责:
- ①接口减负:提供大量入参上下文,减少数据量;
- ②提供缓存+批量查询:减少查询次数;
- ③异步编排:优化线程依赖关系,获取上一个任务返回的结果,并返回当前任务的返回值
Java8 CompletableFuture深度解析与商品详情页优化实践

订阅专栏 解锁全文
915

被折叠的 条评论
为什么被折叠?



