避免重复

Question

想象一下，我们有一个文件，以及一些处理它并发送数据的工作：

1. 进入数据库
2. 到外部服务

我们能保证只处理一次文件或者至少确定出现问题并通知用户他是否手动解决了这个问题？

Answer 1

是的，你可以。

您可以做的是在数据库中创建一个表来存储文件的名称和标志/状态（如果读，是，否）。当进程在该位置提供文件时，请确保相同的进程更新名称（如果每次名称不同）以及数据库中该文件的标志/状态。您的文件读取过程可以从数据库中获取文件的名称，并将该文件转储到您的任何地方以及何时完成，它应该将标志更新为read或其他任何内容。这样，您可以避免多次读取文件。

Answer 2

我会在您的数据库中存储两个信息表。

1. 处理过的文件行与您一样。
2. 文件本身的记录。包括：
   • 文件名
   • 处理是否成功，失败，部分成功
   • SHA1哈希校验和，可用于稍后检查文件的唯一性

当您去处理文件时，首先检查校验和是否已存在。如果是，则可以停止处理并记录问题。或者你可以把这些信息扔到文件表上。

还要确保处理的行与文件之间存在外键关联。这样，如果出现问题，进行人工干预的人可以追踪受影响的线路。

Answer 3

Usmana或Tracy的答案实际上都没有保证文件不会被处理多次，而且您的工作也不会向数据库和外部服务发送重复请求（问题中的＃1和＃2）。两种解决方案都建议在完成所有处理后保留日志并更新它，但如果在最后一次尝试更新日志时发生错误，则您的作业将在下次运行时再次尝试处理该文件，并将重复请求发送到数据库和外部服务。使用Usmana和Tracy建议的解决方案来处理它的唯一方法是在交易中运行所有内容，但在像您这样的分发环境中这是一项非常具有挑战性的任务。

您的问题的常见解决方案是优雅地处理对数据库和外部服务的重复请求。实际的实现可能会有所不同，但是例如，您可以向数据库添加唯一约束，并且当作业尝试插入重复记录时，将抛出异常，您可以在作业中忽略该异常，因为这意味着所需的数据已经在分贝。

我的回答并不意味着你不需要Usmana和Tracy建议的日志表。您确实需要它来跟踪处理状态，但它并不能确保不会对您的数据库和外部服务发出重复请求，除非您使用分布式事务。

希望它有所帮助！