【问题标题】:How to handle concurrency by eventual consistency?如何通过最终一致性来处理并发?
【发布时间】:2014-05-24 08:06:26
【问题描述】:

如何通过最终一致性来处理并发?或者我可以问如何通过最终一致性来确保数据完整性?

通过 CQRS 和事件溯源,最终一致性意味着您将域事件放入队列中,并设置作为投影的事件处理程序。这些预测以异步方式更新读取缓存。现在,如果您使用该读取缓存进行验证,则无法确定您验证所依据的信息是否仍然有效。当您发送命令时,队列中可能存在未处理(或未投影?)的域事件,这可能会改变验证的结果。所以这只是另一种并发......你怎么看,如何处理这些罕见的并发问题?域事件已经保存在存储中,所以你不能对它们做任何事情,你不能只是从事件存储中删除它们(因为它应该只写一次),并在电子邮件中告诉用户,对不起,我们做了我们决定并取消您的请求。或者你可以吗?

更新:

通过事件存储处理并发的可能解决方案:

按写模型

if
    last-known-aggregate-version < stored-aggregate-version
then
    throw error
else
    execute command on aggregate
    raise domain-event
    store domain-event
    ++stored-aggregate-version (by aggregate-id)

按读取模型

process query
if
    result contains aggregate-id
then
    attach read-cached-aggregate-version

通过投影

process domain-event
read-cached-aggregate-version = domain-event-related-aggregate-version (by aggregate-id)

【问题讨论】:

标签: concurrency domain-driven-design cqrs event-sourcing eventual-consistency


【解决方案1】:

只要状态发生变化,您就不能假设任何事情都会 100% 一致。从技术上讲,您可以确保各种位 与您所知道的 100% 一致。

您的排队域事件场景与用户办公桌上仍然需要输入系统的工作队列没有什么不同。

任何其他执行依赖于系统状态的操作的用户都无法知道其他用户仍需要执行某些可能会干扰其操作的操作。

我想很多都是基于假设数据是一致的,并开发可以在出现这些情况时处理这些情况的替代流程和流程。

【讨论】:

  • 你有什么建议,我们应该完全忽略这类问题,让数据完整性破坏吗?
  • 一点也不。在您处理命令的每一点,您的聚合都必须是一致的。如果不是,那么您可能需要启动一个流程来处理该场景,除非您能够立即解决问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-09-26
  • 2018-08-01
  • 1970-01-01
  • 1970-01-01
  • 2015-06-05
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多