我有一个关于 Couchbase 如何在内部处理并发的问题。
我尝试在他们的文档中进行研究，我发现这取决于您在应用程序中使用的锁定机制，两个主要是：
但是，以上两者都与我们希望我们的策略如何保存数据有关，这意味着我们是否愿意锁定它。
在我们的例子中，如果我们没有在我们的应用程序中使用其中任何一个锁定，那么 couchbase 将如何在以下场景中为文档提供服务：
我的问题是应用程序 B 是否必须排队才能读取文档，或者默认情况下它将获得旧版本的服务（所有这些都不会通过同步网关，我们直接使用 .Net DLL 进行写入和读取)。
Couchbase 4.5.0 版
【问题讨论】：
标签： concurrency couchbase
如果您使用 Couchbase SDK 并直接连接到数据服务，则 Couchbase 具有很强的一致性。如果应用程序 A 写入该文档，并且在应用程序 B 读取它之后，应用程序 B 将立即获得该版本。一致性来自 Couchbase 如何分发数据以及客户端 SDK 如何访问它。 Couchbase 将每个对象分配到 1024 个活动分片之一（Couchbase 称它们为 vBucket）。有复制品，但我不会在这里讨论。当 SDK 直接读取/写入对象时，它会获取您提供的对象 ID，并将其传递到一致的 CRC32 哈希中。该哈希的输出是一个介于 0-1023 之间的数字，即 vBucket 编号。然后，SDK 会查看集群映射（集群分发的 JSON 文档）并找到 vBucket 在集群中的位置。然后 SDK 直接与该节点和 vBucket 对话。这就是应用程序 A 可以写入一个对象，然后在几微秒后应用程序 B 读取它的方式。他们都在同一个地方阅读和写作。 Couchbase 不会扩展从副本的读取。副本仅用于 HA。
【讨论】：
因为，正如 Kirk 在回复中提到的，Couchbase 是一致的，所以你的场景中的读取和写入请求都会到同一个节点，访问服务器内存中的同一个对象。然而，在谈论涉及网络延迟和各种 IO 队列的分布式系统时，诸如“同时”之类的概念变得模糊。最终，两个“同时”请求的执行顺序将取决于服务器接收它们的顺序，但没有确定性的方法来预测它将是什么。路上变数太多；如果其中一个客户端的 CLR 决定在那时进行垃圾收集，延迟请求，或者其中一个客户端机器遇到瞬时网络延迟等，该怎么办？这是文档建议对并发写入使用显式锁定的原因之一，以在不可预测的请求排序面前强制执行可预测的行为。
但是，在您的场景中，根本无法知道写入和读取的顺序，因为“同时”不是一个确切的概念。在您的情况下，一种可能的解决方案可能是对数据使用显式版本控制。这可以是时间戳或某种修订号，每次更改文档时都会增加。当然，使用时间戳会遇到和上面类似的问题，因为它是根据运行应用程序 A 的机器的时钟记录的，这很可能与应用程序 B 运行的时钟不同。
【讨论】：