项目结构采用了star方法,Situation:概括性的总结业务背景和挑战;Task:介绍你负责的任务已经需要达成的目标;Action:项目中你采取的关键行动;Result:项目落地后的实际效果。本文是项目实战第十讲:使用事务消息实现店铺与仓库的数据一致性
文章目录
-
- 1、项目背景
- 2、项目职责
- 3、主要技术
- 4、数据库相关
- 5、业务逻辑
- Action1:不允许店铺名称重复
- Action2:排查用户中心是否发过消息?
- Action3:店铺名称变更后,商品主表中店铺名称没有联动?
- Action4: “创建店铺失败” 确认下是否是正常逻辑,还是上次没改全
- Action1:线上问题修复,实例店铺需要支持授权类目、授权品牌为空
- Action1:存在的问题,前后台类目绑定关系变更了,的确是需要重新计算绑定关系,这时是怎么解决的呢?
- Action:为啥放入redis缓存需要异步操作?
- Action1、shop正式供应商没有店铺创建
- Action2、店铺创建成功但是默认仓库创建失败的场景
- Action3、店铺名称更新
- Action4、店铺名称联动
- Action5:traceId是单调递增的吗?
- Action6:前台类目只支持最多3级类目
- Action7:需要咨询搜索,supplierSearchFacade支持查询超过1万条数据吗?
- Action8:应用重启后,Job能接着跑吗?
- Action9:线上报错,同名店铺已存在
- Action10:全量店铺类目树聚合,执行需要的时间多少?
- Action1、调用链中有RM是http接口,如何处理?
- Action2、各个模式之间是否可以混用?
- Action3、异常不抛如何处理?
- 6、项目结果
1、项目背景
背景:店铺属标准中心业务,基础数据
2、项目职责
①开发实例店铺(旗舰店、专卖店、综合卖场)逻辑
②接口调用量巨大,加缓存
3、主要技术
①使用Guava Cache 工具类 + Redis 记录缓存
②使用MQ解耦业务
③在店铺和仓库的数据一致性问题中:使用事务消息实现分布式事务
4、数据库相关
- 店铺表:数据量:100万
create table shop(
id bigint unsigned auto_increment