我正在寻找在通过 HTTP 和 SFTP 传输时避免传输重复文件的方法。每次执行传输到外部缓存时，我的系统都会存储传输状态。
在每次传输之前，我都会查找外部缓存，如果当前文件有一个状态为 SUCCESS 的条目，则该文件将被跳过。只要我的系统能够在每次传输发生时将状态存储在缓存中，这就会很好地工作。但是如果传输完成并且在写入传输状态之前，服务就死了，服务对传输没有任何线索，下次同样的文件来的时候，我会重新传输文件。
改善这种情况的一种方法是在传输完成之前和之后更新缓存，以便我对文件有一些线索。但是有没有其他方法可以避免这种情况？因为一旦文件传输到外部系统，当状态写入失败时，就没有办法撤消了。有什么想法吗？
【问题讨论】：
标签： etl apache-nifi data-transfer fault-tolerance system-design
我经常同步外部数据，并编写了足够多的母带处理流程来谈论这个主题。您正在寻求物流解决方案，甚至没有提及数据的上下文及其交付到另一个位置的目的。
您是否尝试将文件的主副本镜像到另一个位置？如果是这样，那么您只需交付带有唯一交付编号的文件，允许收件人独立同步两个数据集并处理文件中检测到的任何差异。如果您强制代表接收者执行此工作，您可能会破坏数据。我一直建议让接收者根据需要自己提取数据并自己同步/掌握它，而不是推送它。这样，这些业务规则就被组织在它们应该在的地方。推送过程很糟糕。
您是否试图让用户用他们自己的副本覆盖主文件，询问如何协调他们的上传以使文件不被覆盖？如果是这样，您需要取消他们的直接控制权以覆盖该文件。您需要根据用户定义的流程分别同步每个文件，因为每个文件都可以有自己的业务规则。
当您说“查找外部缓存并且如果当前文件有一个状态为成功的条目，则该文件将被跳过”时，您对交付者承担了太多责任。我这么说，但你怎么知道？在制造业中，除了搬运货物之外，没有人会期望送货员能做更多的事情。消费者负责分配该空间。如果消费者确实需要该文件，让其决定订购它并处理接收它，而不是让交付者处理此类决定。
【讨论】：