按请求顺序优雅地处理故障

Question

我正在为像pastebin.com这样的服务设计架构。我计划用自己的服务器将用户数据存储在S3存储和元数据上。因此，每当用户请求创建粘贴时，有两个步骤：

1. 在S3中存储内容
2. 用本地元数据数据库存储元数据。

我在想，如果第一步成功，第二步失败，会发生什么。当这种情况发生时，我在S3中有数据粘贴，我没有办法访问它，用户将得到一个失败响应，他/她可以重试，然后可能会成功。但是最初的失败在我的存储中创建了一些数据，而且我没有任何元数据和任何方法来访问它。

我的问题

当我们不得不在一个又一个发生的2-3个活动中执行，而其中一些活动失败时，我们如何回滚呢？

Answer 1

有三个方面的故障处理适用于您的情况：

• 通知服务用户(重要)。给出失败的反应是正确的方法。通常，您的用户对调用失败的原因不感兴趣，只关心它失败的事实。这个方面很重要，你已经做到了。
• 使服务处于一致状态(重要)。重要的是让您的服务处于可以接受新请求的状态(尽可能地接受新请求，这取决于失败的类型)。在某些存储中拥有额外的、不可访问的数据通常不会影响未来的请求。这个方面很重要，我敢打赌您的代码在这方面表现良好。
• 清理未使用的资源(可选)。用不可访问的数据填充存储是不可取的。您可以尝试删除错误处理程序中的数据，也可以创建类似于夜间垃圾收集作业的东西，扫描存储中无法访问的数据。但是，如果资源成本不是特别高，你也可以简单地生活在一小部分垃圾。这取决于你的决定，如果你想花时间在这方面。