cqrs - CQRS 写入数据库

Question

在我们公司，我们正在开发一个基于微服务的系统，我们应用 CQRS 模式。在 CQRS 中，我们将命令和查询分开，因此我们必须开发 2 个微服务。目前，我被指派增强 CQRS 模式以将事件保存在单独的数据库中（事件源）。我知道拥有一个单独的事件数据库非常重要，但我们真的需要一个单独的写入数据库吗？Write数据库的实际用途是什么？

Answer 1

如果你有一个事件数据库，它就是你的写数据库。它是记录系统，包含应用程序的事务一致状态。

如果您有一个单独的读取数据库，则可以以高度一致或最终一致的方式从事件日志构建它。

Answer 2

不，您不一定需要单独的写入数据库。CQRS 隔离的核心是模型（代码）级别。一直到数据库可能对您的项目有益或有害，具体取决于上下文。

与围绕使用 CQRS（事件溯源、命令总线等）的许多正交架构决策一样，在采用之前应仔细考虑利弊。在一定数量的并发访问之下，分离读取和写入数据库可能不值得付出努力。

Answer 3

我知道拥有一个单独的事件数据库非常重要，但我们真的需要一个单独的写入数据库吗？Write数据库的实际用途是什么？

写入数据库的目的是作为您的记录簿。写入数据库是用于在重新启动时恢复的持久表示。它是所有写入的同步点。

正如你的系统所理解的那样，它是“当前的真相”。

从某种意义上说，它是“真实”数据，其中读取模型只是真实数据过去样子的旧/缓存表示。

从 RDBMS 的角度考虑可能会有所帮助。当流量较小时，我们可以为来自单个数据库的所有传入请求提供服务。随着流量的增加，我们希望开始卸载一些流量。由于我们希望持久化数据处于一致状态，因此我们无法卸载写入——如果我们想在写入时解决冲突，则不能。但是我们可以将读取转移到其他实例上，前提是我们愿意承认在写入发生和写入的数据在所有系统上都可用之间存在有限的时间间隔。

所以我们将所有的写入发送给领导者，领导者负责将所有内容组织到预写日志中；然后可以将日志的更改复制到其他实例，从而构建用于支持低延迟查询的数据结构的本地副本。

如果您仔细观察，您可能会注意到您的“事件数据库”与“预写日志”有很多共同之处。