大众对象即将到期的战略架构

Question

假设我的数据库中有几百万个对象。每个对象都有属性dateCreated。 默认情况下，所有对象应在创建后48小时后到期。

检查对象何时到期的最佳策略是什么。

首选精度为秒，但为了性能，分钟也是一种选择。

Answer 1

我有一些总是在运行的组件（比如后台服务）。

定期在给定的时间范围内过期引用对象 - 请记住，虽然对象到期可能是以秒/分钟为单位，但您可以不那么频繁地拉取数据（比如说每5分钟） ，20分钟，小时）。这取决于对象可以存活的最短时间（创建和到期之间的时间）。

目前它听起来像是48小时，所以你可以说每48小时可以提取数据，但是更频繁地处理更少量的数据听起来更好IMO。在内部，它会不断地到期对象 - 我猜可能是每一秒，如果过期命令是异步执行的，那么在下一个批次完成之前你不必担心（尽可能多）完成。

该组件除了提取数据和协调到期外什么都不做。 我假设实际的到期行为将在其他地方完成;所以这个组件要么发出命令（过于繁琐？），要么发出批处理命令（不是“批处理作业”只是现在要过期的对象列表？）。

另一种方法是说服务在逻辑上是主应用程序的一部分，即使它在物理上是分开的（在一个独立的服务中），这将允许它执行实际的到期。

在内部，到期服务可以在内存中保留一份工作清单;当它“过期”时，确保在事务中执行该操作，这将更新某个排序审计/日志。如果服务死亡，您就会知道已处理的内容。

当服务恢复生效时，它会接收下一个范围的对象 - 包括上次未正确处理的对象 - 如果需要，您可以标记为特殊处理。

如果您无法构建服务，则需要找到可以根据需要频繁删除对象的内容。

Answer 2

在您决定的时间窗口中保留下一个要过期的对象列表（分钟/秒），更新列表，下一个对象在空时到期，并在每个对象到期时到期。

Answer 3

每小时或更小（比方说10分钟）分区怎么样？删除数据时可能会丢弃整个分区。