问题标签 [eventual-consistency]

当索引表有高并发更新时，hbase如何保证索引与数据的一致性？查询主表时，对索引表的扫描不会看到过时的数据。

例如，有按时间索引的“主题”和“帖子”表，当帖子出现时，主题表会更新，并且时间列上还有二级索引。

如果通过二级索引进行扫描，数据可能会更改并且扫描可能会丢失/获取过时的数据？hbase如何处理索引表与数据表的一致性？

我正在寻求实现一个可以在地理上广泛分布的数据库，并且每个节点都可以读/写，并且最终与所有其他节点保持一致。我应该在哪里寻找？

由于其他原因，我认为 MongoDB 似乎是一个不错的选择，直到我遇到这个问题。显然所有 MongoDB 节点都是可读的，但只有一个主节点是可写的？有没有办法解决这个问题？我不能允许写入数据库的单点故障。

异步写或后写的想法是客户端提交写操作的请求，然后在不等待写操作结束的情况下自行其是。

从我对这个主题的阅读中我不清楚的是，如果发生错误，如何处理它们。一种策略可能是记录并忽略它们。好的，所以我想客户端必须在后续读取操作失败时应对。采用什么策略来处理不可避免的写入失败？它们是否以任何方式暴露给用户？我可以想象一些非常奇怪的应用程序行为。想象一下，如果数据库出现故障，并且执行了几个写操作（从客户端的角度来看），实际上没有任何持久性发生。

我正在开发一个针对亚马逊 S3 的系统。我正在使用 S3 的 .NET SDK 在 C# 中执行此操作。

我想一次将多个文件上传到 S3，但如果任何一个文件失败，我希望所有文件都失败。我可以这样做吗？如何？

SDK 的 TransferUtility.UploadDirectory 是否对目录进行原子上传，如果目录中的任何文件上传失败，那么它们都会失败？

如果它不进行原子上传，那么我需要有代码自己管理它；如何使用 TransferUtility.UploadDirectory 了解哪些文件成功以及哪些文件失败？

感谢您的任何帮助或指导。

如果我在 S3（美国东部）中放置一个对象，然后重复请求该对象的元数据直到我可以 GET 它，那么此时我是否保证所有其他客户端现在都可以获取该对象？或者是否有可能另一个客户端的请求以某种方式路由到尚未注册 PUT 的不同服务器？我试图了解最终一致性的后果，特别是在一个客户端能够获取的情况下。

Read-your-own-writes 一致性是对所谓的最终一致性的巨大改进：如果我更改了我的个人资料图片，我不在乎其他人是否在一分钟后看到更改，但如果在页面重新加载后我仍然看到，这看起来很奇怪旧的。

这可以在 Cassandra 中实现，而无需对多个节点进行完整的读取检查吗？

在读取未指定的数据时使用ConsistencyLevel.QUORUM很好，并且实际上正在读取 n>1 个节点。但是，当客户端在写入时从同一个节点读取（并且实际上使用相同的连接），这可能会很浪费 - 在这种情况下，某些数据库将始终确保返回以前写入的（我的）数据，而不是返回一些旧的数据。使用ConsistencyLevel.ONE并不能确保这一点，并假设它会导致竞争条件。一些测试表明：http ://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/per-connection-quot-read-after-my-write-quot-consistency-td6018377.html

我对这种情况的假设设置是 2 个节点，复制因子 2，读取级别 1，写入级别 1。这会导致最终的一致性，但我希望读取时读取你自己的写入一致性。

如果我只在“我的”数据上保持一致就足够了，我认为使用 3 个节点，RF=3，RL=quorum 和 WL=quorum 会导致浪费的读取请求。

// seo：也称为：会话一致性、read-after-my-write 一致性

根据 CAP 理论，Cassandra 只能具有最终一致性。更糟糕的是，如果我们在一个请求中进行多次读取和写入，而没有得到适当的处理，我们甚至可能会失去逻辑一致性。换句话说，如果我们做事快，我们可能做错了。

同时，为 Cassandra 设计数据模型的最佳实践是考虑我们将要进行的查询，然后向其中添加 CF。这样，添加/更新一个实体在很多情况下意味着更新许多视图/CF。没有原子事务特性，就很难做好。但是有了它，我们又失去了 A 和 P 部分。

我不认为这与很多人有关，因此我想知道为什么。

• 这是因为我们总能找到一种方法来设计我们的数据模型以避免在一个会话中进行多次读取和写入吗？
• 这是因为我们可以忽略“正确”的部分吗？
• 在实际实践中，我们是否总是在中间的某个地方有 ACID 功能？我的意思是可能在应用层实现或添加一个中间件来处理它？

使用分布式和可扩展架构时，通常需要最终的一致性。

从图形上看，如何处理这种最终的一致性？

用户习惯于单击保存，并立即查看结果......最终保持一致性是不可能的。

如何处理此类场景的 GUI？

请注意，该问题适用于桌面应用程序和 Web 应用程序。

PS：我正在使用 Microsoft 平台，但我想这个问题适用于任何技术......

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

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

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

提前致谢，

杰米

考虑一个只有最终一致性的未版本化存储桶。

假设我刚刚上传了一个对象，现在我将其删除。删除请求发送到对象尚未传播到的服务器。

现在，在我看来，只有三件事可能发生：

1. 服务器会记住删除操作，因此一旦对象到达此服务器就会删除该对象。

2. 服务器回复“404 Not found”，对象继续存在。

3. 服务器回复“201 No data”，忘记删除操作，对象继续存在。

答案 1意味着每个 S3 服务器都必须记住它收到的每个删除请求，以防它稍后从另一台服务器收到相应的对象。重置此内存的唯一方法是对整个 S3 集群进行某种全局原子同步（因此服务器可以确定它想要忘记的删除没有未完成的更新），我认为这不太可能。但是，如果对象稍后仍然出现，则记忆删除的定期超时将破坏最终的一致性保证。

另一方面，答案 2暗示如果

1. 我将一个对象上传到服务器 A
2. 我将对象的新版本上传到服务器 B
3. 我删除服务器 B 上的对象
4. 只有现在服务器 B 从服务器 A 那里听到关于上传的信息

..所以我最终会得到一个过时的对象版本，这会破坏最终的一致性保证。

答案 3也意味着最终一致性保证被破坏，因为在发出删除请求后对象仍然存在。

所以基本上所有三个答案似乎都不太可能。我错过了什么吗？