Ste*_*e B 14 user-interface distributed eventual-consistency cqrs
使用分布式和可扩展的体系结构时,通常需要最终的一致性.
从图形上看,如何处理这种最终的一致性？
用户习惯于单击保存,并立即查看结果...最终的一致性是不可能的.
如何处理这种场景的GUI？
请注意,该问题适用于桌面应用程序和Web应用程序.
PS:我正在使用微软平台,但我想这个问题适用于任何技术......
一个任务型UI适合这种模式极大.您可以从UI创建和执行任务.您还可以使用任务状态监视器来在任务执行时向用户显示.
另一种选择是使用来自客户端的某种池.您从客户端发送命令和池,直到命令完成并且新数据可用.在某些情况下,从用户按下保存到他将看到新记录时,您会有延迟,但在大多数情况下,它应该几乎是同步的.
另一个(好的？)选项是假设/设计不失败的命令.这不是一件容易的事,但您可以在客户端上拥有缓存,并将命令中的数据添加到该缓存中,并在执行命令之前将其显示给用户.如果命令因某些意外情况而失败,那么只需设计一个好的"我们很抱歉"的消息,误导用户几秒钟.
您还可以组合上述方法.
通常,最终的一致性更多是业务/域问题,您应该让域专家处理它.
我认为其他答案通常将 CQRS 和最终的一致性混合在一起。基于任务的 UI 非常适合 CQRS，但它并没有解决最终一致性读取模型的问题。
首先，我想挑战你的说法：
用户习惯于单击“保存”，并立即查看结果……最终的一致性是不可能的。
你这是怎么了？为什么不能立即看到结果？我认为这里的问题是你对 result的定义。
任何操作的结果都是该操作已执行。有很多方法可以证明这一点！这取决于你想完成什么样的动作。例子：
发送电子邮件：如果用户输入了正确的电子邮件地址，则几乎可以保证该操作将成功完成。为了防止意外故障，可以使用持久队列，因为这种操作不需要同步完成。所以你只需说“电子邮件已发送”。通常，当您要求重置密码时，您会看到此类响应。
更新用户配置文件中的一些信息：在客户端验证新数据后，该命令很可能也会成功，因为唯一可能发生的事情是数据库错误（如果您使用数据库）。同样，即使这种情况也可以通过使用持久队列来缓解。在这种情况下，您只需以相同的形式显示更新的字段。SPA 的最佳实践是在客户端拥有一个全面的数据存储，就像 Redux 那样。在这种情况下，您可以通过发送命令并更新客户端存储来安全地更新服务器，这将导致 UI 显示最新数据。免责声明：有些答案将这种技术称为“欺骗用户”，但我不同意这个定义。
如果您有容易出错的命令，您可以使用其他答案（如 Websockets 或服务器端事件）中已经描述的技术来返回错误信息。这需要相当多的额外工作。您也可以发送命令并等待回复或同步执行命令。有人会说“这不是 CQRS”，但这只是另一个需要挑战的教条。结合上一点（客户端数据存储）确保命令已完成执行将是一个很好的解决方案。
我不确定是否有任何 100% 防弹技术可以让您始终显示读取模型中的非陈旧数据。我认为这违背了 CQRS 的原则。即使使用实时事件，您也只会获得表明您编写的模型已更新的事件。尽管如此，您的预测可能会失败，对此做出反应又是另一回事了。
但是，我不会太专注于这个问题。事实是，经过充分测试的预测和几乎保证的命令将非常有效。对于 90% 情况下的错误处理，有一些手动或半手动过程来从这些错误中恢复就足够了。对于最后 10%，您可以结合从服务器推送的通用“错误”消息，说“抱歉，您的操作 XXX 未能执行”，并且最优先的操作可能在其背后有一些创造性的过程，但实际上这些情况会非常非常稀有的。