.net - 当接收者仍然需要更新他们的读取存储时，CQRS 如何帮助减少锁争用？

Question

我查看 CQRS 的原因之一是减少数据库上的锁争用，以便 写道 只需更新规范化结构，然后 阅读 可以查找它需要的数据，不受竞争写入的影响。

假设以下设置:

将系统写入它自己的规范化数据库 ( WriteDb )

将系统发布消息写入总线以引发事件

读取系统拾取消息，更新它的物化 View (单独 ReadDb)

从物化 View 读取系统读数 ( ReadDb )

在第 3 步和第 4 步期间不会仍然存在锁争用吗？读取系统仍然需要更新它的数据副本，这可能与读取同时发生，所以我只是认为这是减少锁争用，由于索引窄/较少......但危险仍然存在，尽管在较小的范围上。

有哪些策略可以帮助缓解这个问题？ ( 是 这是一个问题，还是我想多了？)。事件溯源是唯一的方法吗？

注意:我在 .NET/SQL 上 .. 所以任何特定于该堆栈的答案的奖励积分:)

谢谢

Answer 1

Won't there still be lock contention during step 3 & 4

涉及锁，即使仅在行/文档级别，但其想法是写入发生的频率远低于读取，因此写入和读取之间的锁(足够)很少见。

but the danger is still there, albeit to a lesser extent

什么危险？如果您的意思是这会影响读取速度，那么是的，但是它比多表/多连接锁的痛苦要小得多。

使用 CQRS，您可以(并且应该)创建自给自足查询的读取模型(如果您使用 SQL，则为表)，即您不需要任何连接；这样查询会更快，锁定读取的概率会更低。

Is Event Sourcing the only way?

事件溯源不需要使用事务，因此锁比普通的 CQRS 更小(更快)——这就是 ES 在读取端更快的原因。

另一种解决方案是使用仅用作读取模型更新事件源的事件日志(而不是事件存储)。一个不便之处在于，这是您架构的另一个移动部分，它也必须以异步方式(使用线程或其他方式)与来自写入模型的事件保持同步。

关于使用事件日志的文章:

Event log vs event streams

Event Sourcing - Projections (go to Rebuilding)