问题标签 [eventual-consistency]

我们有一个使用 Google App Engine 作为后端的身份验证系统。底层语言和框架包括 Java、JDO、Google Authentication 和 Google App Engine。

我们有一个用户实体。用户实体是从 Google App Engine 身份验证响应中保存的用户元数据（例如：名字、姓氏、电子邮件地址）。

当用户尝试注册或登录（均为登录事件）时，我们会扫描数据存储以查看是否已存在具有相同电子邮件地址的用户。如果用户不存在，我们创建一个新用户。如果用户确实存在，我们会更新并检索他们的用户信息，然后检索他们的应用程序数据。

我们需要运行单独的多个事务，因为登录页面与应用程序页面完全分离。

在某些情况下，当用户尝试在短时间内注册两次时，会创建重复用户。虽然我们总是可以获取最后注册的用户，但我们确实希望查询是唯一的 JDO 查询。使用唯一的 JDO 查询，JDO 查询（在事务中运行）有时会由于找到两个相同的值（对于用户的电子邮件地址）而失败。

我们考虑了以下实施约束的方法：

1. 将新注册的用户信息存储在缓存中。我们似乎没有找到任何信息表明缓存是防止重复的合适解决方案。缓存是否可以跨机器立即使用？即使是这样，缓存也可能出于各种原因弹出实体。
2. 将用户的电子邮件存储在会话中。这似乎使代码膨胀，并且似乎是一种执行约束的奇怪方式。

Google App Engine 是否有最佳实践方法来防止身份验证工作流程中的重复值和单独的事务？

ThoughtWorks 技术雷达 2014 年 7 月在“技术/试验”下提到了一种名为REST without PUT. 他们将其解释为：

在上一个雷达中，我们讨论了捕获显式域事件，重点是记录触发状态转换的具有业务意义的事件，而不仅仅是 CRUD 实体。REST 接口通常使用 PUT 来更新资源状态，但通常最好使用 POST 来记录捕获意图的新事件资源。没有 PUT 的 REST 具有分离命令和查询接口的附带好处，并迫使消费者允许最终的一致性。

是否有任何其他资源可供人们阅读？这个术语REST without PUT是由 ThoughtWorks 提出的一个想法，还是学术性的，或者……？

对此有任何提示吗？

对于一个独特的商品销售数据库，如果我们使用顺序一致性，我们可以保证，例如，独特的商品永远不会被重复销售给不同的人。因果一致性能保证我们做到这一点吗？

如果有一些销售同时开始/结束，是否会破坏系统？

由于这些物品是独一无二的，我们只能出售每件物品之一。

谢谢你

每当我读到有关 NoSQL 分布式数据库的内容时，他们都会提到 CAP 定理，这意味着在分区系统中，您可以具有完全一致性、完全可用性，或者两者兼而有之，但永远不能完全两者兼而有之。

我不太清楚的是他们在谈论什么类型的一致性：

1. 是否是数据新鲜度的一致性，某些客户端可能会获得比其他客户端更旧的数据？
2. 还是在事务可能仅部分完成的意义上的一致性，这可能会使数据处于不一致的状态？

第二种解释对我来说听起来很危险，而且不是真的可以接受。第一种解释听起来可以接受，但是您如何防止请求一组数据的客户端没有提供部分过时的数据和部分新鲜的数据？

只提供部分一致性有多危险，可能的负面影响是什么？

我在一家大公司工作，该公司在处理后端系统的负载方面存在问题。他们正在考虑替换旧的遗留系统/数据库，并将其替换为水平可扩展的 NoSQL 数据库。查看 NoSQL 数据库的原因是通过使用水平可扩展的解决方案为未来做好准备。

分布式 NoSQL 数据库通常只提供最终一致性。这是一个多大的问题还有待调查。在这种情况下，我们正在处理一个写入操作相对较少且读取较多且可用性很重要的系统。

有相当多的 NoSQL 数据库系统（cassandra、mongoDB、hbase 等）。是否有任何指南或有文献说明哪些数据库系统适用于哪些情况？我还希望了解发生不一致问题的可能性有多大，以及如何减少这种机会以及成本是多少。

欢迎任何信息/提示/参考文献。

我有一个带有一些集合和大约 30 个索引的 RavenDB。

我正在尝试通过 DatabaseCommands.UpdateByIndex 和 PatchRequest 在特定集合（配置文件）中执行一些大规模更新，实际上我的代码是这样的：

其中“Profiles/ByFinder”是适用于该特定集合的索引。

奇怪的是，当我执行此命令时，数据库中的所有索引都处于陈旧状态，即使是那些无法以任何方式与 Profiles 集合一起使用的索引。

这是默认行为吗？如果是这样，有办法避免吗？

I don't understand these. Let's say I have a value 10 at memory address x.

If we have

and then:

I don't get what is valid sequential or strict consistency.

Like, here, is this a valid strictly consistent operations result?

That seems so useless. x has the wrong value... it wasn't additive. That said, the accesses executed by each processor were kept in-order and the same order was seen by everyone. Those are the criterion for strict consistency, right? It doesn't matter that the result got crushed.

And for a sequential consistency... I don't get the distinction between it and strict.

我正在考虑将 Amazon MySQL RDS 与只读副本一起使用。唯一让我感到不安的是副本滞后和最终的不一致。例如，想象用户修改他的个人资料（更新将在主数据库实例上执行）然后刷新页面以查看更改的信息（可能从由于副本滞后而尚未收到更改的副本执行选择）的情况。

偶然，我发现亚马逊文章提到它可以执行有针对性的查询。对我来说，听起来我们可以添加一些参数或其他参数来告诉亚马逊在主数据库实例而不是副本上执行选择。用户配置文件的示例非常简单，但在更实际的情况下也会出现同样的问题，例如结帐，当用户执行几个步骤并且他需要在接下来的屏幕上查看更新的信息时。是的，应用程序可以自己缓存整个数据集，但是如果有人知道如何在主数据库实例上执行目标查询，那就太好了。

考虑用户购物车和结帐：客户可以执行 addItemToCart 操作，该操作将由主数据库实例处理。但是，可能会在只读副本上执行 getUserCartItems 操作，并且由于副本滞后，它可能不包含第一个操作的结果。即使我们尝试尽量减少这种滞后，仍然有可能遇到这种情况，所以我想知道您在生产中尝试了哪些解决方案？

根据@Henrik 的回答，我们有 3 个选项：

这意味着我们需要在客户端上执行轮询（定期或长轮询）并等待 Replica 收到更新。但是，我认为副本延迟不应超过 1-5 秒。此外，副本滞后越少，我们的性能下降越多。

如果我理解正确，我们需要将 addItemToCart insert 和 getUserCartItems select 结合到后端的一个聚合操作中，并将 getUserCartItems 作为 addItemToCart 响应返回。但是，由于延迟，下一个请求可能仍未获得更新信息……是的，它会立即返回有关成功操作的确认，并且应用程序可以继续，但是继续结帐需要用户购物车物品才能正确显示价格，因此我们没有修复反正问题。

应用程序存储/缓存所有成功发送的数据并用于显示。是的，这是一个解决方案，但它肯定需要实现额外的业务逻辑：

你如何处理最终的不一致？

我目前正在学习 Google-App-Engine ( https://www.udacity.com/course/ud859 ) 上的 udacity 课程。有简介和会议。每个配置文件都可以注册会议，然后将其添加到配置文件对象中的列表中。

当我现在查看“getProfile”请求的 API Explorer 时（检索当前活动用户的用户数据，由 oAuth2.0 验证），每次单击“执行”时都会得到不同的结果。

当我第一次单击执行时，我得到了正确的响应：

正确响应（我通过开发人员控制台数据存储查询验证了这一点）：

但是，如果我再次单击执行，我会得到以下响应：

错误的反应

如果我再次单击执行，我确实会再次得到正确的响应，依此类推。它总是在错误和正确之间交替，但数据存储查询中的数据保持不变。这对我来说根本没有意义。

getProfile 方法：

更新 1：即使现在，12 小时后，问题仍然存在。我在开发人员控制台中看到了正确的数据，但我的前端和 API Explorer 总是在正确和错误的结果之间切换。几乎感觉下面有两个不同的数据存储，并且 API 调用在它们之间交替..？

更新 2：我将应用程序重新部署到 GAE 上的一个新项目中，但错误仍然存​​在。我改变了上面的帖子，因为我现在有一个更简单的例子，当问题发生时。