这种方法可以有效降低系统逻辑中的轮空，但是查询记录的时候需要把前一种状态的记录也查找到。因为本来我们需要命中的合同是已经生效的，使用懒惰策略就需要把待生效的合同也一起找到，然后从已经生效的合同中剔除已经过期的合同，从待生效的合同中找到已生效的合同；这时候，就需要把已过期和已生效的合同状态都改掉。当然我们可以使用异步逻辑去处理状态变更，因为即使处理失败依然不影响下一次的查询结果。
事件驱动的好处从上面的例子中我们可以感受到使用事件触发机制代替定时任务实际上有利有弊。正向点是事件机制是按需的，有需求就来，没需要就别来。弊端是为了维护事件机制的正常运行一般需要一套辅助逻辑：但是又有哪种逻辑不需要补偿机制呢？只不过有些是成熟的、现成的，有些是需要我们重新开发的。
从本质上讲，定时任务是一种无状态的行为，也就不符合面向对象的思想。而事件触发是模拟了人去处理一件事的流程。
比如记录的汇总，在有管信之前运维人员是怎么处理的呢？如果等到第二天把前一天挤压的单子一起处理，这就是定时任务。如果单子量很大，人工一下子处理不完，就需要多个人一起处理，这就是分布式任务。如果多个人一时半会也处理不好，需要比较长的时间（人工的压力上来了），他们可能会变通为来一单处理一单，不然一天中大部分的时间也是闲着，这样压力就降下来了。对于系统也一样，实时处理可以有效降低系统压力骤升。
实际上人工处理积压单据依然不是定时任务的原型，这样处理仅仅是因为人工能够处理得过来，是人性的表现而非模型的转换。定时任务难以在人身上找到原型，虽然人类现在也在使用闹钟，但闹钟的任务是提醒而重复任务
再模拟一下合同的处理。
假设没有管信，合同查找员估计会有几个格子，一个放待生效的，一个放生效中的，一个放已过期的。当需要找合同的时候，他就去前两个格子中寻找并把已生效的从第一个格子放到第二个，把已过期的从第二个挪到第三个。
那他可不可能提前挪这些合同呢？可能的，但完全没必要：这依然是人性 —— 他太懒了。而且他今天挪过以后，可能今天一整天都没有出现过需要使用合同的时候，那他为什么不在明天挪呢？所以没有一个合适的时间去挪，干脆用的时候挪。
所以结论是什么？
对于流式数据，我推荐使用实时处理，需要解决的问题是并发安全
对于批数据，我推荐懒惰策略，需要解决的问题是幂等
写在最后如果你喜欢这个思想，但是自己遇到了难以摒弃定时任务的场景，欢迎你留言，我们一起来讨论。