我查看 CQRS 的原因之一是减少数据库上的锁争用，以便 写道 只需更新规范化结构，然后 阅读 可以查找它需要的数据，不受竞争写入的影响。
假设以下设置:
WriteDb ) ReadDb)ReadDb ) 在第 3 步和第 4 步期间不会仍然存在锁争用吗？读取系统仍然需要更新它的数据副本，这可能与读取同时发生，所以我只是认为这是减少锁争用，由于索引窄/较少......但危险仍然存在，尽管在较小的范围上。
有哪些策略可以帮助缓解这个问题？ ( 是 这是一个问题，还是我想多了？)。事件溯源是唯一的方法吗？
注意:我在 .NET/SQL 上 .. 所以任何特定于该堆栈的答案的奖励积分:)
谢谢
最佳答案
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 在读取端更快的原因。
另一种解决方案是使用仅用作读取模型更新事件源的事件日志(而不是事件存储)。一个不便之处在于，这是您架构的另一个移动部分，它也必须以异步方式(使用线程或其他方式)与来自写入模型的事件保持同步。
关于使用事件日志的文章:
关于.net - 当接收者仍然需要更新他们的读取存储时，CQRS 如何帮助减少锁争用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47643941/