AxonFramework,快照(Snapshotting)
当聚合存活很长一段时间,它们的状态不断变化,它们会生成大量的事件。不得不加载所有这些事件去复原一个聚合的状态,可能会有很大的性能影响。快照事件是一个有着特殊用途的领域事件:它将任意数量的事件归纳为单个事件。通过定期创建和存储快照事件,事件存储不必返回长的事件列表。只返回最后一个快照事件和在快照之后发生的所有事件 例如,库存物品往往会经常变化。每销售一件物品,事件就减少一件库存。每次一批新物品进来,库存就增加一些。如果你每天销售一百件,你每天会产生至少100个事件。几天之后,你的系统将会花太多的时间读取所有这些事件,只是为了弄清楚它是否应该raise一个“ItemOutOfStockEvent”。单个快照事件仅仅通过存储当前的库存数量就可以取代很多这些事件。 Creating a snapshot创建一个快照快照的创建可由多种因素触发,例如,从上次快照创建以来的事件的数量,初始化一个聚合的时候超过了某个阈值,基于时间的,等等。目前,Axon提供了一种机制,允许你基于事件计数阈值触发快照。 当要创建快照时的定义,由SnapshotTriggerDefinition接口提供。 当加载聚合所需的事件数量超过一定的阈值时,EventCountSnapshotTriggerDefinition提供触发快照创建的机制。如果加载一个聚合需要的事件的数量超过某个可配置的阈值,触发器告诉Snapshotter为聚合创建一个快照。 快照触发器在一个事件溯源存储库上配置,并有很多属性允许你调整触发:
Snapshotter负责快照的实际创建。通常,快照是一个应该尽可能少的扰乱操作进程的进程。因此,建议在不同的线程运行Snapshotter。Snapshotter接口声明了单独的方法:scheduleSnapshot(),以聚合的类型和标识符作为参数。 Axon提供了AggregateSnapshotter,它创建并存储AggregateSnapshot实例。这是一种特殊类型的快照,因为它包含了在它内部的实际的聚合实例。Axon提供的存储库知道这种类型的快照,并从它提取聚合,而不是实例化一个新的。快照事件之后加载的所有事件传输到取出的聚合实例。
AbstractSnapshotter提供了一组基本的属性,允许你调整创建快照的方式:
AggregateSnapshotter提供另一个属性:
存储快照事件当快照存储在事件存储中时,它会自动使用快照归纳所有之前的事件并将其返回到它们的位置。所有事件存储实现允许并发创建快照。这意味着它们允许快照被存储的同时,另一个进程为同一个聚合添加事件。这允许快照进程作为一个完全独立进程。
Axon提供了一种特殊类型的快照事件:AggregateSnapshot,它将整个聚合存储为一个快照。动机很简单:你的聚合应该只包含与业务决策相关的的状态。这正是你想要在一个快照中捕获的信息。所有事件溯源存储库由Axon承认的AggregateSnapshot提供,并将从它提取的聚合。注意,使用这个快照事件要求事件序列化机制需要能够对聚合进行序列化。 根据快照事件初始化聚合快照事件是一个和其他事件一样的事件。这意味着一个快照事件就像任何其他领域事件一样被处理。当使用注解来划分事件处理程序(@EventHandler)时,你可以注解一个方法,基于快照事件初始化全部的聚合状态。下面的代码示例演示了,如何像对待任何其他聚合中的领域事件一样对待快照事件。 public class MyAggregate extends AbstractAnnotatedAggregateRoot { // ... code omitted for brevity @EventHandler protected void handleSomeStateChangeEvent(MyDomainEvent event) { // ... } @EventHandler protected void applySnapshot(MySnapshotEvent event) { // the snapshot event should contain all relevant state this.someState = event.someState; this.otherState = event.otherState; } } 有一种类型的快照事件处理方式不同:AggregateSnapshot。这种类型的快照事件包含实际的聚合。聚合工厂识别这种类型的事件并从快照中提取聚合。然后,将所有其他事件重新应用到提取的快照。这意味着聚合从不需要能够处理AggregateSnapshot实例自身。 先进的冲突检测和解决方案明确改变的含义作为一个主要的优势,就是你可以更精确地检测冲突的变化。通常,这些冲突的变化,发生在两个用户同时处理相同的数据(几乎)时。想象一下两个用户都查看一个特定版本的数据。他们都决定对这些数据进行修改。他们都将发送一个命令就像“在这个聚合的X版本上,那样做”,其中X是聚合的预期版本。其中一个会将修改实际应用于预期的版本。另一个用户不会。 当聚合已经被另一个进程修改时,你可以检查用户的意图与任何看不见的修改是否冲突,而不是简单地拒绝所有传入命令。
如果找到事件匹配的断言(predicate),抛出异常(detectConflicts可选的第二个参数允许你定义抛出的异常)。如果没有找到,处理将继续正常进行。 如果没有调用detectConflicts,并有潜在冲突的事件,@CommandHandler将失败。这可能是提供一个预期的版本的情况下,在@CommandHandler方法的参数中没有可用的ConflictResolver 。 作者:勇赴 链接:http://www.jianshu.com/p/0cf9c4c0e037 來源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |