【问题标题】：How CQRS with EventSourcing optimizes read/write带有 EventSourcing 的 CQRS 如何优化读/写
【发布时间】：2021-03-28 22:04:58
【问题描述】：
据我了解，CQRS 和 ES 可以帮助我们独立优化读写操作。当使用分离的数据库进行读/写时，我们可以在读取数据库中设置适当的索引，这样读取就可以高效，而且我们可以以最终一致性为代价快速将数据保存到事件存储中。
这是我的问题：如果两个数据库中的数据需要同步，那么写入读取数据库会导致索引重建，因此会阻塞我们的读取。
我的印象是它与独立读/写的想法相冲突。将数据快速保存到事件存储有什么好处，最终保存到读取数据库的时间更长，所以我们并没有真正独立地扩展 r/w 操作。也许我遗漏了什么，我仍在学习这些模式。
PS。英语是我的第二语言，如有错误请见谅。
【问题讨论】：
标签：
scaling
cqrs
event-sourcing
【解决方案1】：
根据我在 CQRS 方面的经验，它可以让您灵活地使用多种技术和技术来提高性能 - 根据您的要求。
例子：
- 对于 CQRS 的命令部分，您可以使用高级 ORM，如 EF Core，
- 对于查询部分，您可以使用微型 ORM，例如 Dapper（更快）或 ADO.NET（甚至更快）。
另一个关于如何设计数据库的例子：
- 您为命令事务（规范化）设计了一个数据库
- 另一个用于查询的同步数据库（非规范化）在查询方面提供了更好的性能。
您还可以通过多种方式在数据库之间进行同步
所以您可以灵活地提高性能。
【解决方案2】：
我不确定你的问题到底是什么，但我会尝试在这里阐述我的看法。
如果读/写数据库完全分离，它们将不会相互影响。以这种方式使用 CQRS 意味着我们可以独立扩展读/写操作。
但是，更新传播到读取模型并可供客户端查询可能需要一些时间。这就是您为设计最终一致的分布式系统所付出的成本。
写入模型和读取模型之间的同步机制可能因实现而异。然而，在分布式 CQRS 系统中，读模型最终在设计上与写模型一致，因此它们并非始终同步。读取模型总是在追赶，有时它会包含所有信息。
我希望这能回答你的问题。