归档

docs/polling-system/manual-trigger-vs-alternatives.md

@@ -0,0 +1,309 @@
+# 手动触发 vs 替代方案对比
+
+## 方案对比矩阵
+
+### 方案1：保留手动触发（当前方案）
+
+```
+优点：
+✅ 灵活，支持多种触发方式
+✅ 不影响自动轮询配置
+✅ 可以精确控制触发范围
+✅ 支持权限控制和审计
+
+缺点：
+❌ 代码复杂度高（884行）
+❌ 维护成本高
+❌ 频次限制设置不合理
+❌ 权限检查逻辑复杂
+
+适用场景：
+- 故障恢复（快速重试失败的卡）
+- 数据修复（重新检查修复的卡）
+- 性能测试（控制测试场景）
+
+成本：884行代码 + 中等维护成本
+收益：高（故障恢复/数据修复）
+综合评分：⭐⭐⭐
+```
+
+### 方案2：调整轮询配置
+
+```
+原理：
+- 不需要手动触发
+- 直接调整轮询配置的间隔
+- 原配置：实名检查间隔 3600秒
+- 新配置：实名检查间隔 60秒（故障期间）
+- 恢复：实名检查间隔 3600秒（故障解决后）
+
+优点：
+✅ 简单，不需要额外代码
+✅ 自动应用到所有卡
+✅ 易于理解和维护
+✅ 无需权限控制
+
+缺点：
+❌ 需要手动修改配置
+❌ 可能影响其他卡的轮询频率
+❌ 无法精确控制触发范围
+❌ 无法快速恢复
+
+适用场景：
+- 系统级故障（需要调整所有卡的轮询频率）
+- 长期优化（调整轮询策略）
+
+成本：0行代码 + 低维护成本
+收益：中（需要手动操作）
+综合评分：⭐⭐
+```
+
+### 方案3：优先级队列
+
+```
+原理：
+- 不需要手动触发队列
+- 使用优先级队列替代
+- 自动轮询队列：Sorted Set（按时间戳排序）
+- 优先级队列：Sorted Set（按优先级排序）
+- 调度器优先消费优先级队列
+
+优点：
+✅ 灵活，可以动态调整优先级
+✅ 不需要额外的队列机制
+✅ 支持多级优先级
+✅ 易于扩展
+
+缺点：
+❌ 需要修改调度器逻辑
+❌ 需要定义优先级规则
+❌ 需要权限控制
+❌ 需要审计日志
+
+适用场景：
+- 需要多级优先级的场景
+- 需要动态调整优先级的场景
+
+成本：200-300行代码 + 中等维护成本
+收益：中（灵活性高）
+综合评分：⭐⭐⭐
+```
+
+### 方案4：事件驱动系统
+
+```
+原理：
+- 使用事件系统替代 API 调用
+- 当卡状态变化时，发送事件
+- 事件处理器根据事件类型触发轮询
+- 支持多个事件处理器
+
+优点：
+✅ 解耦，易于扩展
+✅ 支持多个事件处理器
+✅ 易于测试
+✅ 易于维护
+
+缺点：
+❌ 需要重新设计架构
+❌ 需要事件系统基础设施
+❌ 学习成本高
+❌ 调试困难
+
+适用场景：
+- 需要多个系统协作的场景
+- 需要高度解耦的场景
+
+成本：500+行代码 + 高维护成本
+收益：高（长期收益）
+综合评分：⭐⭐⭐⭐
+```
+
+## 详细对比
+
+### 功能对比
+
+| 功能 | 手动触发 | 配置调整 | 优先级队列 | 事件驱动 |
+|------|----------|----------|-----------|---------|
+| 快速重试 | ✅ | ⚠️ | ✅ | ✅ |
+| 精确控制 | ✅ | ❌ | ✅ | ✅ |
+| 权限控制 | ✅ | ❌ | ✅ | ✅ |
+| 审计日志 | ✅ | ❌ | ✅ | ✅ |
+| 自动化 | ❌ | ✅ | ✅ | ✅ |
+| 灵活性 | ✅ | ❌ | ✅ | ✅ |
+
+### 性能对比
+
+| 指标 | 手动触发 | 配置调整 | 优先级队列 | 事件驱动 |
+|------|----------|----------|-----------|---------|
+| 响应时间 | <100ms | <100ms | <100ms | <100ms |
+| 内存占用 | 中 | 低 | 中 | 中 |
+| CPU 占用 | 低 | 低 | 低 | 低 |
+| 数据库查询 | 中 | 低 | 中 | 中 |
+| Redis 操作 | 中 | 低 | 中 | 中 |
+
+### 成本对比
+
+| 成本项 | 手动触发 | 配置调整 | 优先级队列 | 事件驱动 |
+|--------|----------|----------|-----------|---------|
+| 开发成本 | 已完成 | 0 | 200-300行 | 500+行 |
+| 维护成本 | 中 | 低 | 中 | 高 |
+| 测试成本 | 高 | 低 | 中 | 高 |
+| 学习成本 | 中 | 低 | 中 | 高 |
+| 总成本 | 中 | 低 | 中 | 高 |
+
+### 收益对比
+
+| 收益项 | 手动触发 | 配置调整 | 优先级队列 | 事件驱动 |
+|--------|----------|----------|-----------|---------|
+| 故障恢复 | 高 | 中 | 高 | 高 |
+| 数据修复 | 高 | 中 | 高 | 高 |
+| 性能测试 | 中 | 低 | 中 | 中 |
+| 日常运维 | 低 | 中 | 中 | 中 |
+| 业务集成 | 低 | 低 | 中 | 高 |
+| 长期价值 | 中 | 低 | 中 | 高 |
+
+## 推荐方案
+
+### 短期（1-3个月）
+
+**推荐：保留手动触发 + 改进**
+
+理由：
+- 代码已经实现，删除成本高
+- 故障恢复和数据修复场景有实际价值
+- 可以通过改进来提高价值
+
+改进清单：
+1. 修复去重机制的时间不对齐问题
+2. 明确使用场景和频次限制的业务依据
+3. 优化频次限制（提高或移除）
+4. 添加 Redis 缓存优化性能
+5. 改进异步处理的错误处理
+
+### 中期（3-6个月）
+
+**推荐：优先级队列 + 简化手动触发**
+
+理由：
+- 优先级队列提供更灵活的控制
+- 可以逐步迁移手动触发的功能
+- 减少代码复杂度
+
+迁移步骤：
+1. 实现优先级队列
+2. 将手动触发迁移到优先级队列
+3. 简化手动触发的功能（只保留单卡和批量）
+4. 移除条件筛选、进度追踪、任务取消
+
+### 长期（6-12个月）
+
+**推荐：事件驱动系统**
+
+理由：
+- 高度解耦，易于扩展
+- 支持多个系统协作
+- 长期收益高
+
+实现步骤：
+1. 设计事件系统
+2. 实现事件处理器
+3. 迁移手动触发到事件系统
+4. 移除手动触发 API
+
+## 成本收益分析
+
+### 方案1：保留手动触发（当前方案）
+
+```
+成本：
+- 开发成本：0（已完成）
+- 维护成本：中等
+- 测试成本：高
+- 总成本：中等
+
+收益：
+- 故障恢复：高
+- 数据修复：高
+- 日常运维：低
+- 业务集成：低
+- 总收益：中等
+
+成本收益比：中等 / 中等 = 1:1
+评价：⭐⭐⭐ 保留，但需要改进
+```
+
+### 方案2：调整轮询配置
+
+```
+成本：
+- 开发成本：0
+- 维护成本：低
+- 测试成本：低
+- 总成本：低
+
+收益：
+- 故障恢复：中
+- 数据修复：中
+- 日常运维：中
+- 业务集成：低
+- 总收益：中
+
+成本收益比：低 / 中 = 1:2
+评价：⭐⭐ 简单但功能有限
+```
+
+### 方案3：优先级队列
+
+```
+成本：
+- 开发成本：200-300行
+- 维护成本：中等
+- 测试成本：中等
+- 总成本：中等
+
+收益：
+- 故障恢复：高
+- 数据修复：高
+- 日常运维：中
+- 业务集成：中
+- 总收益：高
+
+成本收益比：中等 / 高 = 1:1.5
+评价：⭐⭐⭐⭐ 推荐中期方案
+```
+
+### 方案4：事件驱动系统
+
+```
+成本：
+- 开发成本：500+行
+- 维护成本：高
+- 测试成本：高
+- 总成本：高
+
+收益：
+- 故障恢复：高
+- 数据修复：高
+- 日常运维：高
+- 业务集成：高
+- 总收益：高
+
+成本收益比：高 / 高 = 1:1
+评价：⭐⭐⭐⭐ 推荐长期方案
+```
+
+## 总结
+
+| 方案 | 短期 | 中期 | 长期 | 综合评分 |
+|------|------|------|------|---------|
+| 保留手动触发 | ✅ | ⚠️ | ❌ | ⭐⭐⭐ |
+| 调整轮询配置 | ⚠️ | ❌ | ❌ | ⭐⭐ |
+| 优先级队列 | ⚠️ | ✅ | ⚠️ | ⭐⭐⭐⭐ |
+| 事件驱动系统 | ❌ | ⚠️ | ✅ | ⭐⭐⭐⭐ |
+
+**最终建议**：
+1. **短期**：保留手动触发，进行改进
+2. **中期**：实现优先级队列，逐步迁移
+3. **长期**：构建事件驱动系统，完全重构
+