使用CQRS和事件存储,微服务之间的编排提供了最终的一致性,其中一个微服务中的更改需要一点时间传播到其他相关的下游系统(本质上是其他微服务)。如果数据非常关键,以至于两个微服务都应该具有很强的数据一致性,那么有什么选择呢?我能想到的一个选择是像数据网格那样的直写缓存,但这非常脆弱,特别是在分布式系统中。
在这种情况下,每当帐户上的任何活动开始时,它都可以从利息微服务中获取当前状态,这样,您将始终保持同步,但您将使服务相互依赖,这样,当利息服务关闭时,帐户服务将实际关闭。
顺着你的问题往下看,我认为你需要考虑的是一致性是否如此重要(我提出这个问题是因为当我们来自一个整体或交易背景时,我们倾向于认为一致性是存在的)。
比方说,如果你在亚马逊上下订单,你需要发送一个客户id,在这种情况下,你应该检查客户id是否有效。
这将使订单服务依赖于客户服务。
另一个解决方案是在下单时不要检查客户id,而是在OrderPlace事件中检查它并采取必要的措施。
因此,尽量确保系统更好地响应状态的不确定性,而不是关注微服务中的事务。但是,如果确实有对业务非常非常重要的需求,那么就让他们依赖
在这种情况下,想想C. A. P.定理。根据维基百科,“CAP定理指出,在存在网络分区的情况下,必须在一致性和可用性之间做出选择。请注意,CAP定理中定义的一致性与ACID数据库事务中保证的一致性大相径庭。”
因为你有2个微服务,所以你的系统肯定需要分区容忍,你只能选择A(可用性)或C(一致性)。如果你想使用C,那么你的系统将在可用性方面受到影响。当请求进入微服务A时,在A从微服务B返回数据已成功存储的响应之前,你不应该向客户端发送成功消息。这样你就可以通过牺牲可用性来实现一致性。
在分布式服务中很难实现强的一致性,在微服务中更难实现,因为它们拥有自己的数据。这意味着你只能在微服务中有很强的同感。
但是,您可以使用 Saga/流程管理器将关键操作建模为复杂流程。这意味着您可以使用 Saga 以您的业务可接受的方式协调操作的完成。例如,您可以使用类似预留模式的内容
这种模式可以通过实施两遍协议(有点类似于两阶段提交)有序地管理资源分配过程。在第一遍中,发起者要求每个参与者保留自己。如果发起者在超时内从所有相关服务中获得许可,它将开始第二遍,确认所有参与者的预订。
虽然每个微服务通常都有自己的数据,但某些实体需要在多个服务之间保持一致。 对于高度分布式环境(如微服务体系结构)中的这种数据一致性要求,设计的选择是什么?当然,我不想要共享数据库体系结构,即单个数据库管理所有服务的状态。这违反了孤立和不共享的原则。 我明白,微服务可以在创建、更新或删除实体时发布事件。对该事件感兴趣的所有其他微服务可以相应地更新各自数据库中的链接实体。 这是可行的,但是它会导致跨服
我在网上找到两个定义: 顺序一致性——任何执行的结果都是相同的,就像所有处理器的操作都是按某种顺序执行的一样,每个处理器的操作按程序指定的顺序出现在这个顺序中。 最终一致性——如果没有对给定的数据项进行新的更新,最终对该项的所有访问都将返回最后更新的值。 定义对我来说很清楚。但是,当最终一致性不是顺序时,我没有得到。例如:mem 中的初始值为 0。水平轴是时间。 因此,有一些顺序,如果我们在 (x
我正在努力实现强烈的一致性。让我们调用我的模型PVPPlayer: 模型的每个关键点都是这样创建的: 其中,配置文件是父模型: 我有2个REST api url: 在1)我做: 在2)我做: 我的流程如下所示: 问题: 使用保证了很强的一致性,所以我不明白的是为什么有时由于,我得到了一些陈旧的数据,比如点根本没有更新。 示例:
我正在尝试使用python与ndb实现强一致性。看起来我错过了一些东西,因为我的读取表现得好像它们不太一致。 查询是: 关键结构是: 我有许多使用TaskQueue同时执行的任务,并且此查询在每个任务结束时执行。有时我在更新字段时会遇到“过多争用”异常,但我会使用重试来处理它。它会破坏强一致性吗? 预期的行为是,当没有剩余的链接的最后一个\u状态等于无时,调用了。实际行为是不一致的:有时调用两次,
我经常在关于NoSQL,数据网格等的不同演讲中听到最终一致性。似乎最终一致性的定义在许多来源中有所不同(甚至可能取决于具体的数据存储)。 谁能简单解释一下最终一致性是什么,与任何具体的数据存储无关?
MongoDB遵循主从架构。数据写入主节点,然后复制到从节点。据说Mongo提供了可用性的一致性,考虑到这一点,差异可以解释为: 当master关闭时,从节点必须决定选择哪个作为master,这需要时间,因此系统在该时间窗口不可用。 另一个原因可能是:在复制期间,节点被锁定,以便将数据复制到所有从机以获得高一致性,如果我们使用从机进行读取,那么锁定意味着不可用。 但是这可能会根据Mongo允许配置