我正在考虑在我工作的系统中应用延迟持久性,并希望确保我有正确的心理模型以避免数据丢失。我的理解是它基本上意味着在andCOMMIT
之间变成一种“薛定谔的猫” ,对吧?换句话说,某些已提交的事务实际上可能最终会回滚(“提交是谎言”)。COMMIT
ROLLBACK
因此,我们实际上不应该期望在以下情况下看到任何数据丢失:
- 一个服务代理激活过程,它
RECEIVE
发送消息,在事务中处理它们,并且COMMIT
s。如果“提交是谎言”并且事务实际上没有提交,那么它将是一个回滚,并且服务代理将自动重新运行它。 - 将文件批量导入临时表的定期 ETL 类型作业(这部分将完全持久)。之后,在事务中,它处理暂存数据并将暂存数据标记为已处理。如果“提交是谎言”并且事务实际上并没有提交,那么它将是一个回滚,并且暂存的数据不会被标记为已处理,所以我们下次再做一次。
在这些情况下,我们不会期望实际的数据丢失,因为事务会自动重新运行。在这种情况下,它不会比任何其他可能中断事务的风险更大(例如,死锁或中断进程的计划外关闭)。
相比之下,类似以下的场景不适合延迟持久性,并且可能会丢失数据:
- 对于目录中的每个文件,外部进程(例如 SSIS)开始一个事务,从文件中批量导入数据,并提交事务。提交事务后,它会删除文件。现在,如果“提交是谎言”并且事务实际上没有提交,我们将永远丢失文件数据,因为我们删除了文件但导入被回滚。
因此,总而言之,延迟持久性只有在某些外部方依赖COMMIT
. 例如,在线结账进入销售,并合理地假设数据已经提交,销售完成等,并通知用户。但是,如果某些处理已经可以自动容忍并从中断/回滚中恢复,则应该不会增加风险。
听起来对吗?