问题标签 [eventual-consistency]

官方文档是否在某处谈论 CloudKit 一致性？根据我的测试，它似乎最终是一致的——在写入后立即读取记录可能有效，也可能无效（返回空结果）：

有没有办法强制进行反映所有先前更新的强一致读取？

有没有人有任何关于如何在最终一致的环境中进行独特价值保留的链接/资源？

示例：用户在注册时可以选择他们的用户名。即使两个用户同时尝试获取相同的名称，也只有一个用户应该成功。

我有几个潜在的解决方案在我脑海中浮现，但我想知道是否有人已经为这个设计做了跑腿工作。

想象一个电子商务应用程序：

假设我有三个Node cluster N1, N2, N3.并且我的一致性级别 (CL) 很弱：那就是

Read CL = N/2+1 = 2 (in this case), Write CL = Any (alteast 1)

我有一个产品表，例如

这是跨三个节点同步的初始数据

1. 现在客户端 A 从 N1 读取信息，客户端 B 从 N2 读取信息

   客户端 1 看到 1 台计算机可用

   客户端 2 看到 1 台计算机可用

2. 现在他们俩都去买了，客户A先下订单。所以 N1，表格将如下所示：

   product_info : {'computer':0}

3. 现在客户 2 在 N2 下订单，表格如下所示：

   product_info : {'computer':0}

   但实际上客户 2 的订单不应该被处理。

4. 客户端 C 通过 N3 访问。现在在 N1 完成读取，返回 0。（因为 quorum 至少有 2 个节点应该响应）N3 的值为 1，但其时间戳已过时。因此它将更新其值并向客户端显示没有可用的计算机。这很好

   在这个例子中，无论是弱一致性级别还是强一致性级别都会导致错误的结果，仅仅是因为客户端 A 和 B 加载第一个 product_info 时，数据是同步的。这在 Cassandra 中如何处理？

我正在阅读这篇关于 Cassandra 中读取操作和一致性级别的文章。根据这篇文章：

例如，在复制因子为 3 且读取一致性级别为 QUORUM 的集群中，联系给定行的 3 个副本中的 2 个以完成读取请求。假设联系的副本具有不同版本的行，具有最新版本的副本将返回请求的数据。在后台，检查第三个副本与前两个副本的一致性，如果需要，最新的副本会向过期的副本发出写入。

因此，即使具有 Quorum 的一致性级别，也不能保证您不会获得过时的读取。根据上面的段落，如果第三个副本有最新的时间戳，则co-coordinator已经返回了它查询的两个副本的最新时间戳。但这不是最新的，因为第三个副本具有最新的时间戳。

我偶然发现了 App Engine 的数据存储区的这个功能，即您实际上不必拥有持久的根实体即可与 GAE 具有高度一致的行为。您可以使用计算键来存储和加载子实体。我的问题是：这是一种好的做法，还是过于依赖数据存储区的实现怪癖？

这是一个使用 Python 的示例。我敢肯定，这个习语也适用于 Java。

假设您有一个子实体：

CustomerReports 是根据真实的实体类型 Customer 生成的。但是您可以通过计算不存在的父实体的祖先键来以高度一致性保存此报表实体，如下所示：

像这样：

只需计算密钥即可再次检索：

谢谢你。

在使用 RavenDB 的应用程序启动时，我需要加载特定类型的完整文档集合并循环遍历它们。文档的数量应始终很小（< 1000）。

我可以通过以下方式做到这一点：

但我想确保我得到的结果是立即一致的。

似乎这种情况介于 aLoad()和 a之间Query()，因为（我认为）查询旨在最终保持一致，而负载旨在立即保持一致？

但是在这种情况下，应该不涉及索引（没有过滤或排序），那么 usingQuery()会立即一致吗？

I am considering a noSQL solution for a current project, but I'm hesitant about the 'eventual consistency' clause in many of these databases. Is eventual consistency different than dealing with a mySQL database where replication lags? One solution I have used in the past with lagging replication is to read from the master when immediate data consistency is needed.

However, I am confused then as to why relational database claim to have strong data consistency. I guess I should use transactions and that will give me strong consistency. Is it a good practice then to write applications assuming mySQL replication may lag?

我需要想出一个策略来处理数据存储条目创建时的客户端重试：

• 客户端发送请求以在数据库中创建新条目
• 服务器执行条目创建并准备成功回复
• 发生一些错误，使客户端认为请求未处理（数据包丢失，...）
• 客户端发送相同的请求以再次在数据库中创建新条目
• 服务器检测到重试并重新创建并发送原始回复而不创建另一个数据存储条目
• 客户收到回复
• 每个人都很高兴，数据库中只创建了一个条目

我有一个限制：服务器是无状态的！它没有关于客户端的会话信息。

我目前的想法如下：

• 用保证的全局唯一 ID 标记每个创建请求（这是我创建它们的方式，尽管它们与问题不太相关）：
  • 使用数据存储（和内存缓存），我为每个服务器实例在加载后分配一个唯一的、单调递增的 ID（我们称之为SI）
  • 当客户端请求起始页面时，为请求提供服务的实例会生成一个唯一的单调递增页面加载 ID ( PL )，并将SI.PL与页面内容一起发送给客户端
  • 对于每个创建请求，客户端都会生成一个唯一的单调递增请求 ID ( RI )，并将SI.PL.RI与创建请求一起发送
• 对于每个创建请求，服务器首先检查它是否知道创建标签
• 如果没有，它会创建新条目并以某种方式将 create-tag 与它一起存储
• 如果它确实知道该标签，它会使用它来查找最初创建的条目并重新创建相应的回复

以下是我现在正在考虑的实施选项及其问题：

1. 将 create-tag 存储为条目内的索引属性：
   • 当服务器收到请求时，它必须使用查询来查找任何现有条目
   • 问题：由于 AppEngine 中的查询只有最终一致，它可能会丢失一个条目
2. 使用 create-tag 作为条目的键：
   • 应该没问题，因为如果数字不换行，它保证是唯一的（不太可能是多头）
   • 小不便：它会在将来的任何使用中增加条目密钥的长度（不必要的开销）
   • 主要问题：这将在数据存储中生成顺序条目键，应不惜一切代价避免这种情况，因为它会在存储的数据中创建热点，从而显着影响性能

对于选项 2，我正在考虑的一种解决方案是使用某种公式，该公式采用序列号并将它们重新映射到一个唯一的、确定的但看起来随机的序列上，而不是消除热点。关于这样的公式可能是什么样子的任何想法？

或者也许有更好的方法？

我正在尝试加速一些具有以下特征的mysql（innodb）。

我想要一些关于如何删除锁定以提高性能的建议。我完全不关心不可重复读取或写入顺序。

如果用户 A 然后 B 尝试插入……我不在乎谁先写。如果用户 C 查询最近的记录……我不在乎 C 的查询是否遗漏了 A 或 B 或两者……（只要最终后续查询都会得到两者）如果用户 D 查询最近的记录，而用户 E,F&G 正在尝试递增计数...我不在乎计数列对于“用户 D”是否“准确”...（只要它最终在后续查询中准确）

有人可以描述如何以及在哪里使用 nolock 来实现我想要的行为吗？我不希望 INSERT/UPDATE 减慢 SELECT 的速度，我也不关心彼此之间的读/写顺序。

我不在任何交易中使用此表。

我的使用资料：

95% 的并发用户正在对我的“忙碌”表中的最近 2500 条记录进行过滤查询 这些用户每分钟向“忙碌”表添加（插入）约 200 条记录 将单列增量（更新）增加到 1一次记录……每分钟约 1000 次（每分钟增加约 300 条记录）

“忙碌”表未在任何事务中使用……没有插入/更新被“还原”在后续请求中，可能会删除记录或减少列。

谢谢！

我目前正在研究这个用例：

1. 将预算分配给组织单位
2. 迈克使用预算订购了一件商品
3. Jane 同意此订单，验证它。此操作会触发这些后果：
   1. 检查预算余额，看看我们是否可以接受这个订单：如果失败，通知简。
   2. 预算减少到订单金额
   3. 订单状态从 WAITING_VALIDATION 更改为 VALIDATED
   4. 向 Jane 显示一条成功消息

其他用例信息：

• 对于我们的用户来说，从 3.1 到 3.4 的步骤必须是实时的。Jane 单击按钮并等待答案：OK 或 NOT OK AND订单状态已验证

我在想：

• 预算是一个有界的上下文。
• 排序是另一个有界上下文。
• 验证步骤将更改 2 个聚合根，这似乎是错误的。并添加耦合。如果我们需要同时更新另一个聚合根（第 3 步，例如为商品创建会计折旧分录）。
• 为了实时，我们可以使用 XA 事务（例如 SQL + 消息传递），但我想避免它（此外，我当前的技术堆栈不允许我使用 XA 事务）。

似乎我们可以使用最终一致性来实现这种用例： - 订购服务要求预算服务处理 processOrder 命令（通过消息传递或 REST）：此时订购服务正在等待预算服务。- 预算服务处理命令（在本地事务中）并将 OK / NOK 发送给调用者 - 预算服务还发送 OrderInBudgetProcessed 事件。- Ordering Service 实时接收 OK/NOK 并通知 Jane（但此时订单状态没有改变） - Ordering Service 处理 OrderInBudgetProcessed 并在本地事务中更新订单状态。

我认为这可以工作。但是我有一些问题：

• 在订单状态未更新期间，Jane 无法打印订单以将其发送给供应商。
• 在订单状态未更新期间，我们可以想象 Mike 想要取消订单。状态仍为 WAITING，因此允许“取消”操作。我们必须向 BudgetService 询问订单已经处理吗？如果是，那么我们必须使用命令询问所有服务的状态。我们可以使用 saga 或 coordinator 之类的东西吗？
• 采取补偿行动似乎需要做很多工作......

一些问题 ：

• “订单验证” - 由 2 个步骤组成 - 主要由预算上下文或订单上下文处理？（在我看来，主要事件是预算减少，所以我在考虑预算背景）。对你来说似乎有逻辑？
• 您如何看待这种用例？太复杂了？
• 你怎么处理这个？
• 我想同时拥有一个干净的代码（避免更新/同步同一事务中的所有对象的服务）和一个域用户（迈克/简）满意。

请纠正我哪里错了:)

期待您的回音。

弗朗索瓦