问云点播可靠回调中，EventHandle 能否作为持久化去重键？

正在梳理腾讯云点播可靠回调的消费方案，想确认事件确认句柄与业务幂等键的边界。这是方案设计问题，尚无线上故障或报错原文，也未做故障注入实测。 拟定环境：同一 VOD 子应用，两个后端实例调用 PullEvents，将事件写入 MySQL 收件表，事务提交后调用 ConfirmEvents；转码结果更新等业务逻辑由后台任务异步处理。这里重点讨论 ProcedureStateChanged 事件，同一个视频允许多次发起处理任务。 已做的工作是查阅 PullEvents、ConfirmEvents 的接口说明，并对比两个候选方案：一是直接对 EventHandle 建唯一索引；二是按子应用、事件类型、TaskId 和任务状态组合去重。还没确定句柄在重新投递时是否稳定，因此不想先把它当成业务事件 ID。相关接口文档：https://cloud.tencent.com/document/product/266/33434 需要考虑的时序是：实例 A 已经把事件提交到数据库，但在确认请求返回前断开连接；之后实例 B 又拉到对应通知。希望既不重复执行业务，也不把同一 FileId 的另一项合法处理任务误判为重复。 想请教三点： 1. 同一条通知重新被 PullEvents 拉取时，EventHandle 是否保证不变？它是仅用于本次确认的句柄，还是可以长期保存并作为事件唯一标识？ 2. 对 ProcedureStateChanged 而言，子应用 + 事件类型 + TaskId + 状态是否足以区分应处理的业务变化？是否存在同任务同状态但结果内容不同、仍需处理的通知？ 3. 若数据库已确认收件，但 ConfirmEvents 的结果不确定，再次拉到通知时，是否应跳过业务处理并确认本次返回的句柄？这个设计还需要防范哪些确认语义上的边界？