三方商品同步整体流程

三方同步商品信息— 监听器

• 收到消息，接入所有商品变化相关消息
• 处理这些消息，明白那些消息需要处理，哪些消息不用处理
• 处理消息准备发送第三方

指令机使用状态机实现

1. 需要明确指令的各个状态，待处理，处理中，已处理。
2. 各个状态的分别对应不同的处理逻辑
3. 建立事件类型和映射机制
4. 状态转换少，没必要使用状态机

查询商品信息Service，文描，价格，库存，上下架， 通过 builder 组装需要返回的数据，入参 skuId

品牌Service，查询信息，添加缓存，转换数据，返回model , 入参 页码和条件查询

店内分类Service，查询信息，添加缓存，转换数据，返回model 入参 业态

商品分类Service，查询信息，添加缓存，转换数据，返回model入参页码和条件查询

监听器实现

问题：

1. 监听队列如何实现，百万级别消息发送过来，系统如何实现，是否可以抗的住。
2. 具体实现的规则是什么？
3. 实现结构如何设计，如何开发？
   
   

监听器方案1：

监听消息变化 Provider 将消息添加至队列中 （每一个消息 对应 一个 Service 和类 ）

添加队列 前置检查 Checker ，作用去重，判断队列中是否有这个任务，以及队列中的任务数； 初始化 设置没有Checker 最大合并数，消息等待时间

• 缓存以 key - value，String - Set 存储到 redis 中

任务数没有到最大值，且没有超时，添加到redis中，不操作

设置定时器，定时检查任务是否超时

任务数到最大值，同步，清空队列，更新最后同步时间，同步至缓存

同步时会调用的Service

1. 库存变换调用Service
2. 价格变化调用Service
3. 上下架变化调用Service
4. 文描变化调用Service

问题：

1. 是使用redis存储需要同步任务数，还是使用内存缓存记录同步任务？
2. 超时任务怎么判断，系统内部定时器，定时检查？
3. 设置多少同步队列，数据量小没问题，如果数据量增加了该怎么处理？

使用内存缓存来记录需要同步的任务长度

监听器方案2（有风险）：

每个商品存redis,设置10s过期，监听过期消息发送；但是 redis发送消息的时间是 数据实际删除的时间，不是过期时间到0的时间；中间可能会有延迟。

监听器方案3：

收到商品消息，判断10s内该skuId是否发送过延迟消息；

没有发送，发送MQ设置10s延迟，skuId存redis，加锁

发送过，则不发送

监听延迟消息，反查数据，直接同步，去锁

监听器方案4：

收到商品消息, TODO

指令机方案1：

查询不同的指令然后寻找不同的指令返回。

在指令查询前，查询后 会有相应的操作

商品查询抽象为商品指令集，分为

• 商品基本信息查询指令
• 商品库存查询指令
• 商品价格查询指令
• 商品状态查询指令
• 商品文描查询指令

实践中是使用状态机来实现事件的流转操作，事件流转是有状态操作的

如果我们要实现的是无状态流转呢？

参考命令行，也可以使用状态机实现操作。