shopify 刊登流程优化

## 背景
 1.由于shopify刊登过程中需要上传图片，包含描述中图片&附件图片，而图片上传平台又是异步，需要等待图片ready 才能执行后续接口流程。而目前系统设计该刊登任务属于串行化执行长任务接口，图片状态在非ready 状态下，主线程一直处理等待状态，影响批量刊登效率。
 
###  shopify 现状刊登时序

![](/media/202507/2025-07-27_093727_9833050.9561691357154856.png)

### shopify 优化后刊登时序

![](/media/202507/2025-07-27_094307_1992140.29484137894644724.png)

通过添加两个redis 节点的任务队列，监听图片待ready任务队列&监听图片就绪开始刊登主商品任务队列
==redis 本身具备原子性特点，能够避免多pod 情况下被重复拉取消费特点==

改进点：通过新增监听图片待ready 任务队列 & 监听图片就绪开始刊登主商品任务队列释放主线程，不用阻塞等待，接收新刊登任务，提高刊登吞吐量。
缺点: 
- 无法能够做到长任务中部分节点失败，重试刊登不能做到幂等返回，还需要从头执行，影响效率。
- 长任务工作流节点分散，只能阅读代码，才能了解整个刊登流程分为多少个子节点，不能直观感受任务具体进行到哪个工作节点从而导致的失败，处理工单有一定的延迟性。

### 长任务工作流程抽象方案
目标:
- **一个任务是多个阶段组成的，后续阶段必须依赖前置阶段的“成功完成结果”才能执行，任务可能同步执行，也可能异步回调**
- **要构建一个通用的长任务编排模型，既能处理同步响应，又能支持异步回调，同时保证前后任务间有依赖关系（依赖前置任务成功后再走下一步）**

![](/media/202507/2025-07-27_105758_1314540.49589619458609.png)

```sql
public class SubTask {
    private int order; // 步骤顺序
    private String name; // 比如 "uploadImage", "waitImageReady", "callPublishAPI"
    private SubTaskStatus status; // PENDING, RUNNING, SUCCESS, FAILED
    private boolean async; // 是否异步
    private String result; // 执行结果或中间数据
}
```