问题标签 [eventual-consistency]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
java - IMDG (Hazelcast) 如何强制数据一致性
我读过 CAP 定理和 NoSQL 数据最终一致性问题。据我了解,您可以实现完全一致性或完全可用性,但不能同时实现两者。因此,如果您获得更高的性能,您可能会获得陈旧的数据/部分事务。据我了解,目前还没有集群数据存储的解决方案。
另一方面,Hazelcast 声称它对IMap
.
问题: Hazelcast 如何强制执行完整的数据一致性?这是否可能,因为它基于 RAM 并且可能不关心可用性(意味着无论如何都提供可用性)?
database - 使用消息队列将事务更新解耦到两个系统?
在一篇关于 BASE 作为 ACID 替代方案的文章中,Dan Pritchett 提出了一个用于解耦跨越两个表的事务的选项,事务表(例如购买/出售事务)和用户表:
来源: http://queue.acm.org/detail.cfm?id= 1394128
Dan 还认为这种方法存在问题:
消息持久化在事务主机上,以避免排队期间的 2PC。如果消息在涉及用户主机的事务中出列,我们仍然有 2PC 的情况。
来源: http://queue.acm.org/detail.cfm?id= 1394128
我假设消息传递是持久消息传递,因此可以保证传递。在这种情况下,我希望 Dequeue 操作对 Queue 操作没有影响,从而完全解耦Transaction和User表的更新,从而避免这两个表之间的 2PC?将有 2PC,但这将是:
2PC边界1:
- 插入事务表 AND
- 插入消息队列消息持久化表
2PC边界2:
- 更新用户表 AND
- 从消息队列持久表中删除消息
有谁能够澄清我在哪里思考这个错误?
amazon-web-services - 有没有办法等待/阻止,直到 S3 复制更新?
所以在 S3 中的某个位置有一个对象。
我的代码更新了 S3 对象。但我需要确保在继续之前正确复制它。
有没有办法等待/阻止,直到此更改复制到任何地方?
web - 在使用最终一致的数据存储时,是否应该将用户定向到特定的数据节点?
在使用最终一致的分布式数据存储(在我的情况下为 CouchDB)的场中运行 Web 应用程序时,我是否应该确保给定用户始终被定向到相同的数据存储实例?
在我看来,任何 Web 请求都可以使用任何数据存储的替代方法增加了处理一致性问题(重试、检查等)的复杂性。另一方面,如果给定会话中的用户总是被定向到同一个沙发节点,我的一致性问题会不会主要围绕“共享”用户数据而被大大简化?
我也对指导用户的策略感到好奇,但也许我会保留另一个问题(欢迎评论)。
google-app-engine - Google App Engine / NDB - 放置后对实体列表的强一致性读取
使用 Google App Engine 的 NDB 数据存储,如何确保在创建新实体后对实体列表进行高度一致的读取?
示例用例是我有 Employee 类型的实体。
- 创建一个新的员工实体
- 立即加载员工列表(包括添加的员工)
我了解以下方法将最终一致地读取可能包含或不包含新员工的员工列表。在后者的情况下,这会导致糟糕的体验。
现在这里有几个我想过的选择:
重要的限定词
我只关心为添加新员工的用户读取的一致列表。我不在乎其他用户是否有最终一致的阅读。
假设我不想将所有员工都放在 Ancestor 下以启用强一致的祖先查询。在成千上万的员工实体的情况下,5 次写入/秒的限制是不值得的。
我们还假设我希望写入和读取列表是两个单独的 HTTP 请求的结果。从理论上讲,我可以将写入和读取都放在一个事务中(?),但那将是一个非常非 RESTful API 端点。
选项1
- 在数据存储中创建一个新的员工实体
- 此外,将新员工对象写入内存缓存、本地浏览器 cookie、本地移动存储。
- 查询数据存储以获取员工列表(最终一致)
- 如果新员工实体不在此列表中,请将其从 memcache / 本地内存添加到列表(在我的应用程序代码中)
- 将结果呈现给用户。如果用户选择新的员工实体,则使用 key.get() 检索实体(强一致)。
选项 2
- 使用事务创建新员工实体
- 查询数据存储以获取事务中的员工列表
我不确定选项 #2 是否真的有效。
- 从技术上讲,之前的写事务是否在该实体的读事务发生之前被写入所有服务器?或者这不是正确的行为?
- 事务(包括 XG)对实体组的数量有限制,并且员工列表(每个都是其自己的实体组)可能会超过此限制。
- 只读事务与普通读取相比有什么缺点?
想法?选项#1 似乎可行,但要确保后续阅读的一致性似乎需要做很多工作。
c# - 聚合根具有复合主键的存储库
存储库应该作为聚合根的边界,即IRepository<TAggreagte>
提供以事务方式将数据保存到数据库的 CRUD 功能。到目前为止,一切都很好。
但是如果聚合有一个复合主键呢?在我的问题中,它是一个 Identity INT列加上一个SMALLINT序列号。(这是数据库设计,不是我的想法!)
我见过的存储库示例有 egvoid Add(TAggregate aggregate)
或bool Add(TAggregate aggregate)
.
使用“最终一致性”的示例:
我想添加一个聚合 A并且我需要调用存储库 A然后使用存储库 B插入一个依赖 聚合 B,我必须知道聚合 A插入后的 ID。
那是我迷路的地方。如果您插入 A,您将如何获得它的 ID,特别是如果它是一个复合键?我看到的唯一解决方案是再次返回整个对象,所以:
有什么建议吗?
replication - 具有顺序和因果一致性的复制
有两个进程访问共享变量 x、y 和 z。每个进程访问用于保存这些变量的存储的不同副本。x、y 和 z 的值最初为 0。
过程1:
和过程2:
在完成这两个陈述之后,a) 顺序一致性模型和 b) 偶然一致性模型中 z 的可能值是多少?
我知道在顺序一致性中,进程按照程序指定的顺序执行。我相信在上面的示例中,z 的结果在顺序一致性模型中将为零,因为两个进程按照进程中指定的顺序同时执行。因此,没有执行任何 if 条件。但我不确定。
对于偶然的,相关的写入应该在所有进程中以相同的顺序进行。并发写入可以是不同的顺序。我无法弄清楚这个规则在我们的示例中是如何工作的。
mongodb - MongoDB - 跨数据中心初选 DRP / Geographically Distributed Replica Sets
使用分布在 3 个数据中心的 mongo
对于此示例,数据中心名称为 A、B、C
当一切顺利时,所有用户流量都指向 A
所以mongo主要在A上,mongo设置是:
- A 中的 3 台服务器(具有高优先级)
- B 中的 1 台服务器(低优先级)
- C 中的 1 个服务器(优先级 0 )
当发生 2 种情况时,问题是支持 mongo-writes:
- ABC 之间没有网络(网络隧道已关闭)
- 数据中心 A 着火了 :),假设数据中心不工作,此时所有用户流量都指向 B,并且预计 B 中的主要选举。
方案 1 不是问题,当没有数据中心网络隧道时,A 仍然有大部分副本和高优先级,所以一切都还在工作。
场景 2 将不起作用,因为当 A 停止工作时,所有 3 个副本(在 A 上)都无法访问,这样在 B 或 C 中将不会重新生成新的主副本,因为大多数副本都已关闭。
如何设置我的副本集以支持 2 个场景?
hazelcast - Hazelcast:关于多节点一致性的问题
(我找不到一个很好的来源来解释这一点,所以如果它在其他地方可用,你可以指给我看)
Hazelcast 在集群中的所有节点上复制数据。那么,如果其中一个节点中的数据发生了变化,该节点是否会更新自己的副本,然后将其传播到其他节点?
我在某处读到每个数据都归一个节点所有,Hazelcast 如何确定所有者?所有者是按数据结构还是按数据结构中的键确定的?
Hazelcast 是否遵循“最终一致”的原则?(当数据在节点之间传播时,可能会有一个小窗口,在此期间节点之间的数据可能不一致)
冲突如何处理?(两个节点同时更新相同的键值)
c# - 确保事件最终发布到消息队列系统的最佳方法
请假设您有如下方法:
订单保存到数据库后,将一个事件发布到消息队列系统,以便同一台或另一台机器上的其他子系统处理它。
但是,如果this.bus.Publish(new OrderPlaced(Order))
调用失败怎么办?或者机器在将订单保存到数据库后就崩溃了?该事件未发布,其他子系统无法处理它。这是无法接受的。如果发生这种情况,我需要确保最终发布该事件。
我可以使用哪些可接受的策略?哪个是最好的?
注意:我不想使用分布式事务。
编辑:
Paul Sasik 非常接近,我认为我可以达到 100%。这就是我的想法:
首先在数据库中创建一个表事件,如下所示:
您可能想要使用 guid 而不是 int,或者您可以使用序列或标识。
然后执行以下伪代码:
所有事件都必须包含 EventId。当事件订阅者收到事件时,他们首先检查数据库中是否存在 EventId。
这样您就可以获得 100% 的可靠性,而不仅仅是 99.999%