项目结构采用了star方法,Situation:概括性的总结业务背景和挑战;Task:介绍你负责的任务已经需要达成的目标;Action:项目中你采取的关键行动;Result:项目落地后的实际效果。本文是项目实战第六讲:观察者模式实现协议变更联动商品变更
文章目录
-
-
- 1、项目背景
- 2、项目职责
- 3、主要技术
- 4、项目实现
-
- 4.1、总体的流程图
- 4.2、协议续签整体逻辑
- 4.3、使用消息队列制作任务处理器
- 4.4、使用了redis来统计任务数量
- Action1:限流逻辑是怎么做的?
- Action2:如何精确地统计数据?
- Action3:如何提升任务处理器的拓展性?
- Action4:如何使用任务处理器实现普通消息、有序消息和定时消息?
- Action5:大数据量的处理,一份协议最多挂30万个商品,变更协议,如何做到系统稳定呢?
- Action6:使用ES来快速查找商品
- Action7:在这个项目中的收获?
- Action8:可以优化的地方?
- Action9:需要设置消息消费超时时间
- Action10:状态变更dump 优化
- Action11:协议状态变化,搜索es失败3次,但商品没下架
- 5、项目结果
- 6、问题记录
-
1、项目背景
项目背景
商品销量、成交记录是采购人在采购商品过程,非常重要的参考信息,而目前商家重新签订协议后,需要商家重新签订协议,并基于新的协议重新发布新的协议商品,导致了销量和成交记录数据丢失。
面临的挑战
①数据量大 协议与商品是一对多的关系,按线上数据,一份协议最多可能对应30万商品;
- 使用异步限流处理,我们使用了MQ解耦了协议状态变更与商品的变更
②影响面广 涉及四个上下游团队;
- 控制好调用频率和消费速率
- 评估影响面,制定开发接口
2、项目职责
- ①使用批量任务(Redis + MQ)避免数据异步处理该变更任务,能支持普通/顺序/延迟任务;
- ②使用策略模式 + 模板模式提升系统可扩展性;
- ③查询商品详情接入ES,提升系统查询