cqrs - 快照制作和还原策略

标签 cqrs snapshot event-sourcing

我一直在阅读有关CQRS+EventSoucing模式(希望在不久的将来应用)的知识,我发现所有平台和演示文稿的共同点是对模型状态进行快照以恢复模型状态,但是这些共享模式都没有/这样做的策略。

我想知道您是否可以就此事分享您的想法和经验,特别是在以下方面:

  • 何时拍摄
  • 如何为快照存储建模
  • 应用程序/缓存冷启动

  • TL; DR:您如何在Snapshotting应用程序中实现CQRS+EventSourcing?优点和缺点?

    最佳答案

    确保需要快照的实例很少。但是有几个-常见的例子是分类帐中的帐户。您将拥有成千上万个可能会产生帐户最终BALANCE状态的贷方/借方事件-不能如此频繁地进行快照会很疯狂。

    设计Aggregates.NET时,我的快照方法默认情况下处于关闭状态,并且要使您的聚合或实体必须从AggregateWithMementoEntityWithMemento继承,这又会导致您的实体必须定义RestoreSnapshotTakeSnapshotShouldTakeSnapshot
    是否拍摄快照的决定权由实体本身决定。一个常见的模式是

    Boolean ShouldTakeSnapshot() {
        return this.Version % 50 == 0;
    }
    

    当然,每50个事件哪个快照一次。

    读取实体流时,我们要做的第一件事是检查快照,然后从创建快照的那一刻开始读取实体流的其余部分。 IE:不要只要求我们没有快照的整个流。

    至于商店-您几乎可以使用任何东西。 VOU是正确的,尽管键值存储是最佳的,因为您只需要1.检查一个值是否存在2.加载整个对象-这对于kv是理想的

    对于系统重启-我并没有真正关注您所描述的问题。域服务器没有状态的理由,因为它在不同的时间点做不同的事情。它应该只做一件事-处理下一条命令。在处理命令的过程中,它从事件存储中加载数据(包括快照),并对产生业务异常或域事件的实体运行该命令,并记录到该存储中。

    我认为您可能会在谈论缓存和冷启动时尝试进行过多优化。

    关于cqrs - 快照制作和还原策略,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38021748/

    相关文章:

    domain-driven-design - CQRS-如何为场景执行系统建模

    domain-driven-design - CQRS/DDD : The dummy blog/post/category/tags example

    ios - FaSTLane快照可以在真实的ios设备上运行吗?

    java - 事件溯源中的乐观锁机制 "UNDO"流程

    cqrs - 如何在 CQRS/事件溯源中以确定性方式重放?

    java - 为什么事件源模式中使用事件流?

    java - Axon 错误 : java. lang.IllegalArgumentException:工作单元已具有具有相同标识符的聚合

    domain-driven-design - 在域中读取模型

    testing - 如何使用带有 Jest 的 Mongoose 测试 GraphQL 服务器

    java - 从快照位置下载发布 jar 文件