微信公众号：molashaonian
业务背景
商品列表等场景需要展示商品销量，销量自然就跟订单关联，那么统计销量就需要统计商品订单销售的sku 数量
痛点：目前销量计算以 spu（商品） 维度，通过JOB定时查询订单商品表进行统计，以及更新销量缓存，对数据库表的全量查询消耗过大
优化方案初版（优化大多不能一步到位，请看到最后）
- 从计算入手。目前问题也知道了，全量查询计算消耗大，那就从计算销量入手。
- spu首次全量计算销量，并记录该spu最后计算销量得到的订单ID
- 存在spu最后计算的订单ID，根据该订单ID进行销量的增量计算
- 新增全量计算开关控制，用以销量校准
该优化方案解决了多次的全量查询消耗过大问题，只会有初始的一次全量计算，之后便是增量，同时为了校准销量，也保留了全量计算的功能，通过开关控制。
- 不足。虽然避免了全量计算，不过每次的Job都会对全部的 spu 进行销量计算，尽管有些 spu 在这期间并没有产生销售订单
优化方案升级版
为了解决初版无法避免对全部 spu 进行销量计算，在这一步决定把它干掉
- 找出销量有变动的 spu。订单支付成功则记为有效销量，所以在支付回调处入手
- 支付回调：对销量缓存进行更新，并对有销量新增的 spu 缓存起来
- 保留初版优化的全量计算销量Job处理方案，用以销量校准 (该Job默认不打开)
- 新增销量增量同步Job:从缓存中取销量数据（就是支付回调时存下的缓存数据）对数据库表，ES 同步
- 结合实现逻辑图理解
支付回调 Redis销量缓存 Redis销量增量缓存 同步JOB MySQL/ES 校准JOB 更新 更新 获取并删除增量缓存 增量缓存销量更新至MySQL、ES 统计订单商品表进行销量校准 默认不开打 支付回调 Redis销量缓存 Redis销量增量缓存 同步JOB MySQL/ES 校准JOB
- 对于销量解决方案欢迎留意评论
微信公众号：molashaonian
