使用分布式和可扩展架构时，通常需要最终的一致性。
从图形上看，如何处理这种最终的一致性？
用户习惯于单击保存，并立即查看结果......最终保持一致性是不可能的。
如何处理此类场景的 GUI？
请注意，该问题适用于桌面应用程序和 Web 应用程序。
PS:我正在使用 Microsoft 平台，但我想这个问题适用于任何技术......
有几种方法可以处理最终的一致性。所有这些都是真正占用从用户操作到后端刷新的时间。
用户阅读给定用户只能从他们写入的同一数据库节点读取。其他用户从复制的节点中读取。优点:用户界面足够快，并且应用程序保持同步。缺点:您的服务架构必须跟踪用户并将其路由到特定的数据库节点。 禁用 UI 直到 Action 完成，然后刷新它。 Java Server Faces 有一个典型的例子。可以创建一个带有加载微调器的模式来覆盖 UI，直到刷新完成。优点:UI 与应用程序状态保持同步。缺点:大多数操作都会创建一个被阻止的 UI。用户对受限的 UI 感到非常沮丧，并且会提示应用程序运行缓慢。 确认立即感谢用户提交。然后让他们稍后(电子邮件、短信、应用内通知)知道操作是否完成。优点:前面很快。缺点:用户界面滞后于系统直到刷新。即使有通知，用户也可能会因为看不到更新而感到困惑。它还需要整合各种沟通 channel 。用户不会立即看到他们的更改。如果行动失败，他们可能不知道，直到为时已晚。 假的乐观地假设 Action 会完成。向用户显示生成的 UI(点赞、评论、信用卡确认等)，并让他们像成功一样继续。如果有失败，请立即将它们显示为上下文错误:未完成的赞成票旁边的警报，带有失败评论的帖子的应用内警报，被拒绝信用卡的电子邮件。优点:用户界面感觉更快。缺点:UI 暂时与应用程序状态不同步，您必须解决这个问题。一种情况:您可能会使用临时 ID 伪造内容创建。但是在创建内容之后，在刷新之前临时 ID 将是错误的。第二种情况，您可能需要在操作后将所有状态更改存储在 UI 上，直到刷新。然后，您需要一些解析器来应用自发出操作以来的所有本地状态更改。这是决议是不平凡的。 网络套接字 将 UI 订阅到事件流，以便在后端完成操作时将其推送到前端。是单向流还是双向流？优点:UI 感觉很快，并且与应用程序状态同步。缺点:一致的浏览器支持，需要流事件的后端源，以及套接字服务器的可扩展性。