发布接口超时后如何避免重复文章？后端幂等设计面试题

无敌码农编辑部 · 发布于 2026-10-29

面试问题：内容发布接口超时，应该直接重试吗？

不能把“客户端超时”理解为“服务端没有执行”。服务端可能已经保存文章，只是响应在网络上丢失。如果立即重新创建，可能出现重复内容。

先为业务文章建立稳定身份，保存本地文章与远端文章 ID 的绑定。第一次创建尽量先保存为草稿；取得远端 ID 后，后续发布和修改都更新同一个 ID。遇到创建请求超时，应查询并核对远端结果，不能确认归属就停止自动创建，交给人工处理。

if remotePostID != 0 {
    return updatePost(remotePostID, reviewedContent)
}
return createDraft(reviewedContent)

这段代码只展示分支结构，并不是完整可运行的客户端。真实实现还需要持久化绑定、身份验证、超时处理和并发控制。

同一个 slug 可能已经被人工创建的文章占用。查询命中不代表它属于当前业务文章。需要核对受控的来源标记，或让编辑确认关联关系，避免错误覆盖。

创建请求成功但返回响应丢失时，任务进入待核对状态。系统根据稳定 slug 查询远端草稿并检查归属标记；核对成功后保存 ID，再继续发布。查不到或归属不明确时保留现状，不继续创建第二篇文章。

同一站点采用已有的发布锁，同一篇文章在队列中只保留一个执行中的任务。数据库为文章绑定建立唯一约束。

外部 API 和本地数据库没有共同事务，因此不能简单承诺。工程目标是使用稳定身份、查询核对和人工恢复，把不确定结果转成可恢复状态。

先说明真实失败场景，再解释稳定身份、远端 ID、重复请求和人工核对之间的关系。不要只说“加一个重试机制”，因为盲目重试本身可能扩大问题。

公开更新同样绑定已审核版本；更新使用相同远端 ID，避免重新创建文章。

复核说明：SEO 元数据检查不应让已审核且未修改的正文失去发布资格。

复核：公开更新继续使用已保存的远端文章 ID。

内容用于技术学习与求职准备，实际方案请结合版本和业务环境验证。如发现错误，欢迎通过关于页面反馈。