是否可以在数据存储中创建/存储具有最终一致性的用户帐户？

在没有大量架构复杂性的情况下管理帐户创建似乎是不可能的,以避免出现两个具有相同UID(例如电子邮件地址)的帐户的情况？

最终一致性存储的用户是否使用单独的一致数据库作为身份存储,或者是否存在我应该探索的解决方案/模式？

提前致谢,

杰米

我正在深入研究 CQRS，并且正在寻找有关如何在最终一致的系统中解决客户端读取问题的文章。例如，考虑一个网上商店，用户可以将商品添加到购物车中。如果命令“AddItemToCart”的实际处理是异步完成的，如何确保客户端显示购物车中的商品？我了解异步调度命令和基于域事件异步更新读取模型的原理，但我无法从客户端的角度了解这是如何处理的。

嗨,我有以下senario,我不明白如何获得最终的一致性:

1. 用户1使用基于任务的ui来更改客户名称
2. App Service调用聚合操作
3. 客户名上的聚合火灾事件已更改
4. 总线使用nservicebus发送消息
5. NServicebus服务终止
6. 用户2获取聚合并调用更改地址
7. 聚合操作调用
8. 域事件被触发
9. 消息放在公交车上
10. 总线重启
11. 消息2首先被捕获
12. 处理消息2并使用新地址更新其他有界上下文
13. 消息1现在拾起,这是错误的顺序
14. 现在发生了什么

如果我们在事件中传递聚合的版本,那么在13中会出现乐观的并发错误吗？

如果是,则将消息1新应用于其他上下文中的对象.我们如何保持一致性？

这是阻止我在我的域中应用事件的问题.欢迎所有帮助.

基本思想是在另一个上下文中更新另一个聚合.我只是坚持这个并发技术.

我们不是在命令处理程序和命令推送总线的意义上使用事件源或CQRS.只有事件处理我们想要异步发生,因为我们有一个我们不希望改变的现有设计.

布莱尔

我开始研究 nosql 和面向文档的数据库来存储我们将在网站上提供的 HTML5 应用程序的资源。这旨在替代仅在文件系统上存储文件的情况。它们将是针对 Web 优化的小型文件，包括 html、js、css 和 xml 等文本文件，以及图像、声音和字体等二进制文件。

由于我对容错感兴趣，我正在寻找的解决方案（riak、Cassandra）使用最终一致性。虽然我在抽象层面上理解这个概念，但当我与管理者和决策者交谈时，我无法用实际的术语解释最终一致性需要多长时间才能变得一致。毫秒？秒？分钟？由于我在这个领域没有任何经验，因此我正在寻找现实世界的经验来了解这意味着什么。

我知道不同的变量将准确决定任何配置需要多长时间，但我需要能够开始了解我们需要构建哪些类型的基础设施来支持我们的需求。所以我正在寻找的是我们是否需要优化网络延迟、节点数量等来支持我们的特定需求。

我们希望能够选择要测试的平台，在我们投入时间研究任何特定解决方案之前，我们希望能够说“不，这对我们不起作用。”

我们现在拥有使用严格一致性的系统（例如我们的网络服务器和 mysql 数据库上的文件系统），因此我们的管理习惯于负载和超时等概念，以及“宕机”的情况。但我无法与他们沟通“是的，数据现在不可用，但它并没有关闭；最终会可用”。他们想知道“好吧，‘最终’是多长时间”？

我如何判断最终一致的系统是否适用于我们的网站？

(我找不到一个好的消息来源解释这个,所以如果它在其他地方可用,你可以指出我)

1. Hazelcast在群集中的所有节点上复制数据.因此,如果在其中一个节点中更改了数据,节点是否会更新自己的副本,然后将其传播到其他节点？

2. 我在某处读到每个数据都归节点所有,Hazelcast如何确定所有者？业主是根据数据结构中的每个数据结构还是按键确定的？

3. Hazelcast遵循"最终一致"的原则吗？(当数据在节点之间传播时,可能会有一个小窗口,在此期间数据可能在节点之间不一致)

4. 如何处理冲突？(两个节点同时更新相同的键值)

我正在尝试使用 DDD 和洋葱/六边形/干净架构（使用 Java 和 Spring）构建应用程序。我发现找到有关概念本身的指导比实际如何实施它们更容易。特别是 DDD 似乎很难找到有指导意义的例子，因为每个问题都是独一无二的。我在 SO 上看到了很多有用的例子，但我仍然有疑问。我想知道通过我的例子是否会帮助我和其他任何人。

我希望你能原谅我在这里问了不止一个问题。这个例子似乎太大了，我在多个问题中重复它没有意义。

语境：

我们有一个应用程序，它应该显示有关足球统计数据的信息，并具有以下概念（为简单起见，我没有包括所有属性）：

• 拥有众多球员的团队。
• 球员。
• 夹具，有 2 个团队和 2 个半场。
• Half，其中有 2 个 FormationsPlayed 和许多组合。
• FormationPlayed，其中有很多 PositionsPlayed。
• PositionPlayed，它有 1 个玩家和一个位置值对象。
• 组合，可以是2种类型，并且有很多Move。
• Move 可以有 2 种类型，有 1 个 Player 和一个事件值对象。

可以想象，试图找出哪些事物是聚合根是很棘手的。

• 团队可以独立存在，AR 也是如此。
• Player 可以独立存在，AR 也是如此。
• Fixture 在删除时也必须删除它的 Halves，AR 也是如此。
• Half 必须是 Fixture 中的实体。
• 删除一半时必须删除FormationPlayed，所以也许这应该是Half中的一个实体。
• 当一个 Formation 被删除时，PositionPlayed 必须被删除，所以相信这应该是 FormationPlayed 中的一个实体。
• 某种意义上的组合可以独立存在，尽管与特定的游戏半场相关。也许这可能是一个受最终一致性约束的 AR。
• 当一个组合被删除时，移动必须被删除，所以相信这应该是组合中的一个实体。

问题：

1. 你看到上面的设计有什么错误吗？如果是这样你会改变什么？
2. Fixture - Half - FormationPlayed - PositionPlayed 聚合似乎太大，所以我想知道您是否同意可以使用最终一致性将其拆分为 Fixture - Half 和 FormationPlayed - PositionPlayed。我找不到一个例子是这是如何在 …

在微服务架构中，我们通常有两种微服务通信的方式。假设服务 A 需要从服务 B 获取信息。第一个选项是远程调用，通常通过 HTTPS 同步，因此服务 A 查询服务 B 托管的 API。

第二种选择是采用事件驱动架构，其中服务 B 的状态可以以异步方式由服务 A 发布和消费。使用此模型，服务 A 可以使用来自服务 B 的事件的信息更新其自己的数据库，并且所有查询都在此数据库中本地进行。这种方法的优点是可以更好地分离微服务，从开发到运营。但它有一些与数据复制相关的缺点。

第一个是磁盘空间的高消耗，因为相同的数据可以驻留在需要它的微服务的数据库中。但在我看来，第二个最糟糕：如果服务 B 不能按需要快速处理其订阅，或者在服务 B 上创建它的同时它不能用于服务 A，则数据可能会变得陈旧，因为模型的最终一致性。

假设我们使用 Kafka 作为事件中心，其主题配置为使用 7 天的数据保留期。当服务 B 发布其状态时，服务 A 保持同步。两周后，新服务 C 部署完毕，其数据库需要使用服务 B 拥有的所有信息进行充实。由于最旧的事件已经消失，我们只能从 Kafka 主题中获取部分信息。我的问题是我们可以使用哪些模式来实现此微服务的数据库丰富（除了要求服务 B 将其所有当前状态重新发布到事件中心）。

我有以下RabbitMq消费者：

Consumer consumer = new DefaultConsumer(channel) {
    @Override
     public void handleDelivery(String consumerTag, Envelope envelope, MQP.BasicProperties properties, byte[] body) throws IOException {
            String message = new String(body, "UTF-8");
            sendNotificationIntoTopic(message);
            saveIntoDatabase(message);
     }
};

可能会发生以下情况：

1. 消息已成功发送到主题
2. 与数据库的连接丢失，因此数据库插入失败。

结果，我们有数据不一致。

预期结果要么两个操作都成功执行，要么都没有执行。

有什么解决方案可以实现吗？

聚苯乙烯

目前我有以下想法（请评论）

我们可以假设经纪人不会丢失任何消息。

我们必须订阅要发送的主题。

1. 将条目保存到数据库中并设置status值为“ pending”的 字段
2. 尝试将数据发送到主题。如果发送成功-更新status值为'success'的字段

3. 我们必须有一份工作，必须检查具有待处理状态的行。目前有两种情况：
   3.1根本没有发送
   通知3.2通知已经发送但是保存到数据库失败（概率很低，但是有可能）

   因此，我们必须以某种方式区分这两种情况：我们可以将主题中的消息存储在集合中，作业可以检查消息是否被接受。因此，如果作业找到一条与数据库行相对应的消息，我们必须将状态更新为“成功”。否则，我们必须从数据库中删除条目。

我认为我的想法有一些弱点（例如，如果我们有多节点应用程序，则必须将消息存储在hazelcast（或类似物）中，但这是假设失败的另一点）

我明白 clickhouse 最终是一致的。因此，一旦插入调用返回，并不意味着数据将出现在选择查询中。

1. 这是否适用于独立的 clickhouse（无分发，无复制）？
2. 我了解数据复制的最终一致性概念，但它是否适用于分发但不适用于复制？
3. 使用分布式+复制的clickhouse，推荐的方法是什么来知道可以安全地查找某些插入？

基本上我没有找到关于这个主题的太多信息，所以也许我没有提出最好的问题。请随时启发我。

我一直在阅读一些有关最终一致性和编排微服务的文章和问题，但我还没有看到这个问题的明确答案。我会用通用术语来表达它。

简而言之：如果客户端历史上对您的系统进行了后续同步 REST 调用，那么一旦调用不同的微服务（由于最终一致性），后续调用可能会返回意外结果，您该怎么办？

问题

假设您有一个提供 REST API 的整体应用程序。假设您想要将两个模块 A 和 B 转换为微服务。B维护的实体可以引用A维护的实体（例如A维护学生，B维护班级）。在单体情况下，模块仅引用相同的数据库，但在微服务情况下，它们各自拥有自己的数据库并通过异步消息进行通信。所以他们的数据库最终是相互一致的。

我们 API 的一些现有第三方客户端应用程序习惯于首先（同步）调用属于模块 A 的端点，并在第一个调用返回后，立即（即几毫秒后）调用模块 B 中的端点作为其调用的一部分。工作流程（例如创建一个学生并将其放入班级）。在新的情况下，这会导致一个问题：当第二次调用发生时，模块 B 可能还没有意识到模块 A 中的更改。因此客户端应用程序的现有工作流程可能会中断。（例如，模块 B 可能会回应：您尝试放入班级的学生不存在，或者年级错误。）

当人类用户通过某些前端应用程序单独完成调用时，这不是一个大问题，因为无论如何，模块通常在一秒钟后就会保持一致。当客户端应用程序（不受我们控制）只是调用 A，然后立即调用 B 作为自动化工作流程的一部分时，就会出现问题。在这种情况下，最终一致性根本不够快。

描述情况的简单图表

问题

是否有最佳实践或普遍商定的一组选项来缓解此问题？（我编了学生/班级的例子，不要纠结于具体细节。:)）

我们能想到什么

• 简单地告诉这些客户端的开发人员：从现在开始，你必须为你调用的每个端点实现重试机制。缺点似乎很明显。
• 实现一个等待 B 准备就绪的API 网关。缺点：有许多可以想象的工作流程（涉及更多模块 AZ）需要这样做，因此网关可能会变得相当复杂。
• 以某种方式为客户端创建一个“会话”来跟踪它连续发出的请求。然后 B 可以确定是否应该等待来自 A 的消息，或者甚至可以通过查看客户端向 A 发出的精确请求来更新其状态。

有更好的方法吗？哪个最合适？

编辑：澄清该问题主要涉及以自动方式调用端点的第三方客户端的行为，这意味着即使最终一致性中的几毫秒“滞后”也可能是致命的。