refactor(utils): 修复密码哈希比较逻辑错误 feat(user): 新增按状态筛选优惠券接口 docs: 添加虚拟发货与任务中心相关文档 fix(wechat): 修正Code2Session上下文传递问题 test: 补充订单折扣与积分转换测试用例 build: 更新配置文件与构建脚本 style: 清理多余的空行与注释
2.4 KiB
2.4 KiB
任务中心优化方案
1. 现状分析
当前任务中心 (internal/service/task_center/service.go) 在奖励发放和进度更新逻辑上存在以下隐患:
- 错误处理缺失 (Critical):
grantTierRewards方法中,调用userSvc(积分、优惠券等) 的返回值被直接忽略 (_ = ...)。如果发放失败,系统仍会记录“已发放”日志,导致用户无法收到奖励且无法补发。 - 并发安全问题 (High):
OnOrderPaid和OnInviteSuccess中,进度更新(如OrderCount++)是在内存中计算后保存,存在“丢失更新”风险。matchAndGrant中ClaimedTiers的更新也存在并发覆盖风险,可能导致同一个奖励被多次领取或领取状态丢失。
- 事务一致性 (Medium): 奖励发放(User Service)与日志记录(Task Log)不在同一事务中。虽然完全一致性难以在不重构的前提下实现,但目前的“忽略错误”加剧了不一致风险。
2. 优化方案
2.1 强化错误处理
在 grantTierRewards 中,严格检查每一个奖励发放接口的返回值。
- 如果任何一个奖励发放失败,立即返回错误。
- 利用外层事务回滚机制,确保
TaskEventLog不会被写入(状态不会变为 granted)。 - 副作用: 对于包含多个奖励的任务,如果中途失败,可能会导致部分奖励重复发放(下次重试时)。但在当前架构下,这是优于“完全不发”的权衡选择。
2.2 并发控制与原子更新
- 原子计数: 使用 SQL 层面的原子递增 (
order_count = order_count + 1) 替代内存自增。 - 悲观锁: 在读取
UserTaskProgress时使用SELECT ... FOR UPDATE,确保同一用户的并发事件(如并发支付)串行处理,防止状态覆盖。
2.3 代码重构
- 优化
OnOrderPaid和OnInviteSuccess逻辑,确保matchAndGrant在锁的保护范围内执行。
3. 实施步骤
- 修改
internal/service/task_center/service.go:- 重构
OnOrderPaid/OnInviteSuccess使用事务和锁。 - 重构
grantTierRewards增加错误处理。
- 重构
- 验证修改。
4. 验收标准
- 模拟发奖失败场景,确保不会记录
TaskEventLog。 - 代码审查确认所有
userSvc调用均处理了 error。 - 确认进度更新使用了锁机制。