整体思路
调用接口，服务返回任务id，然后写一个回调接口，根据回调的结果去落库
如果回调成功，直接落库，回调失败，再次调用这个接口，得到新的任务id，然后去数据库更新这个记录为新的任务id，如果重试三次失败，切换到另一个服务。同时调用邮件服务向公司发一封报警邮件
还有一种情况，是服务没有回调，所以当时是结合集合set写了一个定时任务，在发出请求后，将这个任务id放到set集合中，然后这个定时任务定时查一下这个是否成功，成功就从集合中移除，失败就发送报警邮件
当时是想用Reids配合队列的，但是觉得失败毕竟是少数就没有引入队列，过度的引入反而增加系统复杂度
因为我们任务量较少，主要是验证产品的MVP的，也没有使用redis，使用redis可以使用他的持久化机制
定时任务崩溃，可以会重复处理数据，增加没有必要的开销，所有做了任务处理的幂等性，就是一个操作无论执行多少次，结果都一致。
使用UPDATE ... WHERE语句，只有在音乐的url生成后或者有变化才去更新
考虑使用 OpenTelemetry 等工具，增强系统的可观测性，方便进行分布式链路追踪和性能分析
核心设计与实现（解决方案）
1. 异步回调处理机制
- 双通道状态同步：主通道采用服务回调接口，备用通道通过定时任务轮询
- 回调失败处理策略：
-
- 三级阶梯重试：失败后生成新任务ID并更新数据库记录（
UPDATE tasks SET task_id=? WHERE id=? AND status='pending'） - 服务熔断机制：连续3次失败自动切换备用转码服务
- 报警联动：通过邮件服务发送服务降级告警（SMTP+异步队列）
- 三级阶梯重试：失败后生成新任务ID并更新数据库记录（
2. 兜底轮询方案
- 轻量级任务追踪：采用内存Set暂存未完成任务ID（替代Redis方案）
- 定时扫描策略：
-
- 分片扫描：按时间窗口分批处理，避免全表扫描
- 补偿机制：失败任务触发邮件报警+人工干预入口
- 幂等保障：通过version字段实现乐观锁控制（
UPDATE ... WHERE version=?）
3. 可观测性增强
- 全链路追踪：集成OpenTelemetry实现
-
- 自定义Span记录关键操作（任务创建、回调处理、重试触发）
- 通过Baggage传递业务标识（用户ID+任务批次）
- 指标埋点：统计成功率（
success_rate{service="transcode"} 0.95）
- 可视化看板：Grafana展示关键指标（P99延迟、服务切换次数）
