csxj2026/junhong_cmp_fiber

Fork 0

Files

huang 7308afe801

构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 7m18s

Details

归档

2026-04-13 15:03:02 +08:00

4.4 KiB

Raw Permalink Blame History

轮询系统手动触发功能 - 执行摘要

快速评估

维度	评分	说明
功能完整性	⭐⭐⭐⭐	支持单卡、批量、条件筛选三种方式，权限控制完善
使用价值	⭐⭐	缺乏明确业务需求，频次限制不合理
代码质量	⭐⭐⭐	884行代码，结构清晰但存在设计问题
维护成本	⭐⭐	涉及多个系统，权限检查逻辑复杂
性能影响	⭐⭐⭐⭐	不影响自动轮询，异步处理
综合评价	⭐⭐⭐	保留但需要改进

核心问题

1. 频次限制不合理 ❌

当前限制：
- 每日100次触发
- 单次1000张卡

问题：
- 如果用于故障恢复，100次/天 过高（实际需求<10次）
- 如果用于业务集成，100次/天 过低（实际需求>1000次）
- 没有业务依据支撑这些数字

2. 去重机制时间不对齐 ⚠️

当前实现：
- 去重 key 1小时过期
- 日限制按天计算

问题：
- 23:00 触发的卡，1小时后（00:00）去重 key 过期
- 同一张卡可能在同一天内被触发两次

3. 权限检查过度设计 ⚠️

当前实现：3个权限检查函数
- canManageCard()
- canManageCards()
- applyShopPermissionFilter()

问题：
- 代码重复
- 逻辑复杂
- 易出错

4. 功能过度设计 ⚠️

6个接口中，必要性评估：
- 单卡触发：✅ 高（快速测试）
- 批量触发：✅ 中（批量修复）
- 条件筛选：⚠️ 低（可用 API 查询后再批量触发）
- 进度追踪：⚠️ 低（异步处理，用户无法实时看到）
- 任务取消：❌ 低（无法真正取消已入队的任务）
- 历史查询：⚠️ 低（可用日志系统查询）

实际使用价值

高价值场景 ✅

场景	频率	价值	说明
故障恢复	<1次/天	高	轮询失败时快速重试
数据修复	<1次/周	高	修复错误数据后重新检查

低价值场景 ❌

场景	频率	价值	说明
日常运维	1-10次/天	低	自动轮询已足够
业务集成	>100次/天	低	频次限制过低

改进建议

短期（保留功能）

明确使用场景
- 文档化手动触发的适用场景
- 定义频次限制的业务依据
- 添加使用指南

优化频次限制

选项A：提高限制
- 每日限制：100 → 1000 次
- 单次限制：1000 → 10000 张卡

选项B：移除限制
- 由业务层控制频率
- 系统层不做限制

修复 Bug
- 修复去重 key 过期时间与日限制的不对齐
- 添加 Redis 缓存优化 CountTodayTriggers 查询
- 改进异步处理的错误处理

长期（重新设计）

简化功能
- 移除条件筛选触发
- 移除进度追踪
- 移除任务取消
改进设计
- 统一权限检查逻辑
- 简化数据库表结构
- 使用事件驱动而不是 API 驱动
考虑替代方案
- 使用优先级队列替代手动触发队列
- 使用配置调整替代手动触发
- 使用事件系统替代 API 调用

成本收益分析

成本：
- 代码行数：884 行
- 维护成本：中等
- 测试成本：高
- 性能成本：低

收益：
- 故障恢复：高
- 数据修复：高
- 日常运维：低
- 业务集成：低

结论：
- 如果只用于故障恢复和数据修复，成本收益比 = ✅ 值得
- 如果用于日常运维和业务集成，成本收益比 = ❌ 不值得

最终建议

保留还是删除？

建议：保留，但需要改进

理由：

✅ 故障恢复和数据修复场景有实际价值
✅ 代码已经实现，删除成本高
✅ 可以通过改进来提高价值
❌ 当前实现存在问题，需要修复

优先级

P0（必做）：修复去重机制的时间不对齐问题
P1（应做）：明确使用场景和频次限制的业务依据
P2（可做）：优化频次限制和性能
P3（长期）：重新设计和简化功能

详细分析

完整的深入分析报告请参考：manual-trigger-analysis.md

报告生成时间：2025-04-13 分析范围：

代码行数：884 行
API 接口：6 个
触发方式：3 种
权限检查：3 个函数

4.4 KiB Raw Permalink Blame History Unescape Escape