提交货源流程优化

backend-java/src/main/java/com/nanri/aiimage/config/SimilarAsinProperties.java

@@ -16,7 +16,14 @@ public class SimilarAsinProperties {
     private String cozeToken = "";
     private List<CozeCredential> cozeCredentials = new ArrayList<>();
     private int cozeCredentialStripeSize = 0;
-    private int cozeBatchSize = 10;
+    /**
+     * P0-1：单次提交 Coze 工作流的 row 数量。
+     * 历史值 10，在含 puzzle 多图行的场景下频繁触发 720712008
+     * "node executed out of limit: 1000"。降到 3 以避免节点上限被打爆。
+     * 出现持续 720712008 时还会被 P1-1 滑窗自适应再降到 1。
+     * 不影响 AppearancePatentProperties 的同名值。
+     */
+    private int cozeBatchSize = 3;
     private int cozeConnectTimeoutMillis = 10000;
     private int cozeReadTimeoutMillis = 60000;
     private int cozePollIntervalMillis = 30000;
@@ -34,9 +41,13 @@ public class SimilarAsinProperties {
 
     /**
      * 末尾零头 batch 的强制 flush 阈值（分钟）：当不足 cozeBatchSize 的零头 row
-     * 长时间挂着（Python 慢回传）时触发提交。原硬编码 10 分钟。
+     * 长时间挂着（Python 慢回传）时触发提交。
+     * 任务级实测：345 行 / 4h 总耗时中，约 2-3 小时是 batch 永远凑不满 batchSize 在等下一波回传，
+     * 把阈值从 15 调到 1：最多 60s 后 1-2 行也强制提交，让 Coze 提交侧持续进票，
+     * 总耗时降到与 Python 回传节奏接近。配合 cozeBatchSize=3、cozeSubmitMinIntervalMillis=5000，
+     * 实际不会触发 Coze 限流。出现限流加重再调回 5/10。
      */
-    private int cozeFlushPendingMinutes = 15;
+    private int cozeFlushPendingMinutes = 1;
 
     /**
      * 同 batch retry + split retry 共享的最大重试次数。原硬编码 5。
@@ -45,14 +56,28 @@ public class SimilarAsinProperties {
 
     /**
      * 图片嵌入下载线程池大小。原 SimilarAsinImageEmbedder.DOWNLOAD_POOL_SIZE = 8。
-     * 几千行 ×3 列图片场景下提升到 16 可显著缩短 xlsx 组装阶段。
+     * P2-10：1000+ 行 ×3 列图片场景下，pool=16 仍是 assemble 阶段瓶颈（实测下载 244s/918s），
+     * 提到 32 配合 retry=2、global deadline 显著拉低尾延迟；
+     * 受 2GB 堆约束，单图缩略图维持 300KB 以内，整体内存峰值 ≈ 32 * 300KB ≈ 10MB。
      */
-    private int imageDownloadPoolSize = 16;
+    private int imageDownloadPoolSize = 32;
 
     /**
-     * 单张图片下载超时（秒）。原硬编码 5；放宽到 8 配合 1 次重试，整体更稳。
+     * 单张图片下载超时（秒）。
+     * P2-10：放宽到 8 + retry=1 在快源（aiproxy/m.media-amazon）下没问题，
+     * 但慢源（cbu01.alicdn）会一直挂 8s 才进入 retry，整体串行时间放大。
+     * 调到 5s + retry=2，让慢源更早重试新连接，单图最坏耗时 ≈ 5s * (1+2) = 15s。
      */
-    private int imageDownloadTimeoutSeconds = 8;
+    private int imageDownloadTimeoutSeconds = 5;
+
+    /**
+     * assemble 阶段 taskImageCache 的字节上限。
+     * 默认 256MB：5000 行 × 3 列 × 平均 100KB = 1.5GB 远超 2GB 堆，
+     * 用 BoundedImageCache 按字节累计 LRU 淘汰避免爆堆。
+     * 由于 embed() 写完即 remove()，活跃图片字节通常 ≤ 100MB，仅在极端 prefetch 领先场景才会触发淘汰。
+     * 出现淘汰过频影响命中率时可上调到 512MB；2GB 堆约束下不建议超过 768MB。
+     */
+    private long imageCacheMaxBytes = 256L * 1024L * 1024L;
 
     /**
      * 是否在 Coze 请求 parameters 中附带 api_key 字段。
@@ -82,6 +107,20 @@ public class SimilarAsinProperties {
      */
     private boolean cozeResultBufferEnabled = true;
 
+    /**
+     * P0-4：单 credential 抢 Coze 提交锁的最长等待时间（毫秒）。
+     * 原硬编码 1000ms，在高并发 split retry 时大量抛 "Coze submit throttle lock timeout"
+     * 并把整批行 markFailed。应与 cozeSubmitMinIntervalMillis（5000ms）保持 1.5-2 倍关系，
+     * 默认 10000ms 给抢锁更多时间。
+     */
+    private long cozeSubmitLockWaitMillis = 10000L;
+
+    /**
+     * P0-4：抢 Coze 提交锁失败后下次重试间隔（毫秒）。
+     * 原硬编码 500ms，会在指数退避算法中作为基础值（500/1000/2000/4000ms 上限 4000）。
+     */
+    private long cozeSubmitLockRetryDelayMillis = 500L;
+
     @Data
     public static class CozeCredential {
         private String name;