This commit is contained in:
175
docs/polling-system/manual-trigger-summary.md
Normal file
175
docs/polling-system/manual-trigger-summary.md
Normal file
@@ -0,0 +1,175 @@
|
||||
# 轮询系统手动触发功能 - 执行摘要
|
||||
|
||||
## 快速评估
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|------|------|------|
|
||||
| **功能完整性** | ⭐⭐⭐⭐ | 支持单卡、批量、条件筛选三种方式，权限控制完善 |
|
||||
| **使用价值** | ⭐⭐ | 缺乏明确业务需求，频次限制不合理 |
|
||||
| **代码质量** | ⭐⭐⭐ | 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 个函数
|
||||
Reference in New Issue
Block a user