rest - 返回 HTTP 503 以响应数据库死锁是否合适？

Question

503 ("Service Unavailable")当请求的操作导致数据库死锁时，服务器是否适合返回？

这是我的推理：

• 最初我尝试避免数据库死锁，但我遇到了https://stackoverflow.com/a/112256/14731
• 接下来，我尝试在服务器端重复请求，但遇到了Java Servlet：如何重复 HTTP 请求？. 从技术上讲，我可以缓冲请求实体，但可伸缩性会受到影响，而且客户更有可能看到503 Service Unavailable。

视为：

• 要求客户重复操作更容易。
• 503 Service Unavailable无论如何，他们需要能够处理。
• 数据库死锁相当罕见。

我倾向于这个解决方案。你怎么看？

更新：如果您愿意，我认为返回503 ("Service Unavailable")仍然是可以接受的，但我不再认为这在技术上是必需的。请参阅https://stackoverflow.com/a/17960047/14731。

Answer 1

我认为语义上 409 Conflict 是一个更好的选择 - 基本上，如果您遇到死锁，则会争用某些资源，因此无法完成操作。

现在根据死锁的原因，如果第二次提交请求可能不会成功，但对于任何事情都是如此。

对于 503，作为客户端，我会实施某种退避/断路器操作，因为系统受速率限制，而 409 与特定请求相关。

Answer 2

刚到这里有同样的问题，没有明确的答案。

• 503 是可以接受的，但可能无法正确解释
• 409 也可以，但在我的情况下不行（因为多个资源最终可能会为同一 URL 返回此错误）

就我而言，我最终在同一个 URL 上返回了 307 重定向。

客户端将自动“重试”并且第二次调用有效，因为资源仅在其初始创建期间引发死锁。

被警告可能会陷入无限循环

Answer 3

我认为只要整个事务回滚或者请求是幂等的就可以了。