Files
junhong_cmp_fiber/docs/polling-system/manual-trigger-summary.md
huang 7308afe801
All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 7m18s
归档
2026-04-13 15:03:02 +08:00

176 lines
4.4 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 轮询系统手动触发功能 - 执行摘要
## 快速评估
| 维度 | 评分 | 说明 |
|------|------|------|
| **功能完整性** | ⭐⭐⭐⭐ | 支持单卡、批量、条件筛选三种方式,权限控制完善 |
| **使用价值** | ⭐⭐ | 缺乏明确业务需求,频次限制不合理 |
| **代码质量** | ⭐⭐⭐ | 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次/天 | 低 | 频次限制过低 |
## 改进建议
### 短期(保留功能)
1. **明确使用场景**
- 文档化手动触发的适用场景
- 定义频次限制的业务依据
- 添加使用指南
2. **优化频次限制**
```
选项A提高限制
- 每日限制100 → 1000 次
- 单次限制1000 → 10000 张卡
选项B移除限制
- 由业务层控制频率
- 系统层不做限制
```
3. **修复 Bug**
- 修复去重 key 过期时间与日限制的不对齐
- 添加 Redis 缓存优化 CountTodayTriggers 查询
- 改进异步处理的错误处理
### 长期(重新设计)
1. **简化功能**
- 移除条件筛选触发
- 移除进度追踪
- 移除任务取消
2. **改进设计**
- 统一权限检查逻辑
- 简化数据库表结构
- 使用事件驱动而不是 API 驱动
3. **考虑替代方案**
- 使用优先级队列替代手动触发队列
- 使用配置调整替代手动触发
- 使用事件系统替代 API 调用
## 成本收益分析
```
成本:
- 代码行数884 行
- 维护成本:中等
- 测试成本:高
- 性能成本:低
收益:
- 故障恢复:高
- 数据修复:高
- 日常运维:低
- 业务集成:低
结论:
- 如果只用于故障恢复和数据修复,成本收益比 = ✅ 值得
- 如果用于日常运维和业务集成,成本收益比 = ❌ 不值得
```
## 最终建议
### 保留还是删除?
**建议:保留,但需要改进**
理由:
- ✅ 故障恢复和数据修复场景有实际价值
- ✅ 代码已经实现,删除成本高
- ✅ 可以通过改进来提高价值
- ❌ 当前实现存在问题,需要修复
### 优先级
1. **P0必做**:修复去重机制的时间不对齐问题
2. **P1应做**:明确使用场景和频次限制的业务依据
3. **P2可做**:优化频次限制和性能
4. **P3长期**:重新设计和简化功能
## 详细分析
完整的深入分析报告请参考:[manual-trigger-analysis.md](./manual-trigger-analysis.md)
---
**报告生成时间**2025-04-13
**分析范围**
- 代码行数884 行
- API 接口6 个
- 触发方式3 种
- 权限检查3 个函数