admin/xyzw_web_helper
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
xyzw_web_helper/MD说明文件夹/问题修复-发车任务超时优化v3.9.4.md
kirin 90094ccd5a 1.0
2025-10-17 20:56:50 +08:00

5.6 KiB
Raw Permalink Blame History

问题修复 - 发车任务超时优化 v3.9.4

📋 问题描述

在批量自动化执行"发车"任务时，6个账号中有5个出现 car_getrolecar 超时（5000ms），导致任务失败。

错误日志

❌ [token_xxx] 发车任务失败: Error: 请求超时: car_getrolecar (5000ms)

失败统计

  • 成功：1/6 账号 (16.7%)
  • 失败：5/6 账号 (83.3%)
  • 失败位置：所有失败都发生在第一步"查询车辆"

🔍 问题分析

根本原因

对比游戏功能模块和批量任务的实现，发现了超时配置的差异：

代码位置 调用方式 超时时间 并发数 结果
游戏功能模块 tokenStore.sendMessageAsync(tokenId, 'car_getrolecar') 1000ms (默认) 1个 ✅ 成功
批量任务 (修复前) client.sendWithPromise('car_getrolecar', {}, 5000) 5000ms 6个 (并发) ❌ 超时

关键发现

  1. 游戏功能模块：

    • 单用户点击查询，只有1个请求
    • 服务器响应快
    • 虽然默认超时只有1秒，但足够了

  2. 批量任务：

    • 6个账号并发查询
    • 服务器压力大，响应时间 > 5秒
    • 即使有连接延迟机制（300ms间隔），查询命令还是几乎同时发出

  3. 超时配置来源：

    • tokenStore.sendMessageAsync 是 sendMessageWithPromise 的别名
    • sendMessageWithPromise 的默认超时是 1000ms (src/stores/tokenStore.js:1414)
    • 如果不传第4个参数，就使用默认值

✅ 解决方案

修复措施

1. 批量任务超时优化 (src/stores/batchTaskStore.js)

命令 修复前 修复后 说明
car_getrolecar 5000ms 10000ms (10秒) 查询车辆，并发压力大
car_refresh 3000ms 5000ms 刷新车辆
car_claim 3000ms 5000ms 收获车辆
car_send 3000ms 5000ms 发送车辆

修改位置：

  • 第1134行：初次查询车辆
  • 第1209行：刷新后重新查询
  • 第1280行：发送前重新查询
  • 第1182行：刷新车辆
  • 第1250行：收获车辆
  • 第1293行：发送车辆

2. 游戏功能模块超时优化 (src/components/CarManagement.vue)

命令 修复前 修复后 说明
car_getrolecar 1000ms (默认) 10000ms 提高容错性
car_refresh 1000ms (默认) 5000ms 防止单独使用时超时
car_claim 1000ms (默认) 5000ms 防止单独使用时超时
car_send 1000ms (默认) 5000ms 防止单独使用时超时

修改位置：

  • 第505行：查询车辆
  • 第690-692行：刷新车辆
  • 第744-746行：收获车辆
  • 第787-791行：发送车辆

🎯 预期效果

批量任务

  • 查询车辆：从5秒增加到10秒，应对6个并发请求
  • 其他操作：从3秒增加到5秒，提高成功率
  • 预期成功率：从 16.7% 提升到 80%+

游戏功能模块

  • 从1秒默认值增加到5-10秒
  • 即使服务器偶尔响应慢，也能正常工作
  • 保持良好的用户体验

📊 技术细节

超时时间选择依据

  1. 查询车辆 (10秒)：

    • 并发6个账号同时查询
    • 需要等待服务器处理所有请求
    • 根据实际测试，5秒不够，10秒足够

  2. 其他操作 (5秒)：

    • 刷新/收获/发送是顺序执行，间隔300ms
    • 服务器压力相对小
    • 5秒足够处理单个操作

  3. 为什么不更长：

    • 超时时间太长会导致用户等待过久
    • 10秒是平衡点：既能保证成功率，又不让用户等太久

并发策略

批量任务使用了以下策略来降低服务器压力：

  1. 连接错开：每个账号间隔300ms建立连接

    await new Promise(resolve => setTimeout(resolve, staggerDelay * index))

  2. 操作间隔：每次操作后等待300ms

    await new Promise(resolve => setTimeout(resolve, 300))

  3. 步骤间隔：大步骤之间等待500ms

    await new Promise(resolve => setTimeout(resolve, 500))

🧪 验证方法

测试步骤

  1. 启动应用
  2. 打开批量自动化面板
  3. 选择6个账号
  4. 只勾选"发车"任务
  5. 点击"开始执行"

预期结果

  • ✅ 6个账号中至少5个成功完成查询（83%+ 成功率）
  • ✅ 查询车辆不再超时
  • ✅ 控制台显示 ✅ [token_xxx] 查询到 X 辆车
  • ✅ 总耗时约 60-120 秒（取决于车辆数量和操作数）

失败情况（可接受）

  • 如果仍有个别账号超时，可能是：
    • 网络波动
    • 服务器短暂高负载
    • Token失效
  • 这种情况下，可以使用"自动重试"功能

🔄 版本信息

  • 版本号：v3.9.4
  • 修复日期：2025-10-08
  • 影响范围：
    • src/stores/batchTaskStore.js
    • src/components/CarManagement.vue
  • 向后兼容：✅ 完全兼容

💡 后续优化建议

如果10秒超时仍然不够（在极端高并发情况下），可以考虑：

  1. 降低并发数：从6个降低到3个
  2. 使用完全串行执行：一个一个账号执行
  3. 增加更长的连接间隔：从300ms增加到500ms或1000ms
  4. 使用队列机制：让服务器端控制并发数

目前的10秒超时应该能解决大部分问题，无需立即实施上述优化。

📝 相关文档