Couchbase读/写并发

Question

我有一个关于Couchbase如何在内部处理并发的问题。

我尝试研究他们的文档，我发现它取决于你在应用程序中使用的锁定机制，主要有两个：

1. 乐观锁定
2. 悲观锁定

但是，上述两个方面都与我们希望我们的策略保存数据的方式有关，这意味着我们是否愿意将其锁定。

在我们的例子中，如果我们没有在我们的应用程序中使用任何一种锁定，那么couchbase将如何在下面的场景中提供文档：

1. 如果应用程序A写入文档A
2. 在同一实例中，应用程序B尝试阅读文档A

我的问题是，应用程序B必须排队才能读取文档，或者默认情况下它将获得旧版本的服务（所有这些都不通过同步网关，我们直接使用.Net DLL进行写入和读取）。

Couchbase版本4.5.0

Answer 1

因为，正如Kirk在回复中提到的，Couchbase是一致的，您的场景中的读取和写入请求都将转到同一节点并访问服务器内存中的同一对象。然而，像＆＃34;同时的概念＆＃34;在讨论涉及网络延迟和各种IO队列的分布式系统时会变得模糊。最终，两个同时执行的顺序＆＃34;请求将取决于服务器接收它们的顺序，但没有确定的方法来预测它将是什么。途中有太多变数;如果其中一个客户端的CLR决定立即进行垃圾收集，延迟请求，或者其中一个客户端机器遇到瞬间网络延迟等，该怎么办？这是文档建议对并发写入使用显式锁定的原因之一，在不可预测的请求排序面前强制执行可预测的行为。

在您的场景中，根本无法知道写入和读取将以何种顺序发生，因为＆＃34;同时＆＃34;不是一个确切的概念。在您的情况下，一种可能的解决方案可能是对数据使用显式版本控制。这可以是时间戳或某种修订号，每次更改文档时它们都会递增。当然，使用时间戳会遇到与上述类似的问题，因为它根据机器应用程序A的时钟运行记录，这很可能与应用程序B运行的时钟不同。

Answer 2

如果您使用的是Couchbase SDK并直接连接到数据服务，那么Couchbase非常一致。如果应用程序A写入文档并且在应用程序B读取它之后立即执行，则应用程序B将获得该版本。一致性来自Couchbase如何分发数据以及客户端SDK如何访问数据。 Couchbase将每个对象分配到1024个活动分片之一（Couchbase将其称为vBuckets）。有复制品，但我不会在这里进入。当SDK直接读/写对象时，它会获取您给出的对象ID，并将其传递给一致的CRC32哈希。该哈希的输出是0到1023之间的数字，即vBucket号。然后，SDK会查看集群映射（由集群分发的JSON文档），并查找集群中vBucket所在的位置。然后SDK直接与该节点和vBucket对话。这就是应用程序A可以编写对象的方式，然后应用程序B读取它的微秒。他们都在同一个地方读书和写作。 Couchbase不会缩放从副本中读取的内容。副本仅适用于HA。