azure - 在 Azure Cosmos DB 中维护分布式增量计数器

Question

我对 Cosmos DB 相当陌生，并试图理解 increment operation azure cosmos DB SDK 为 Java 提供了用于修补文档的功能。我需要在容器中的文档之一中维护增量计数器。该文档看起来像这样 -

{"counter": 1}

现在，在我的应用程序中，每次发生操作时，我希望将此计数器的值增加 1。为此，我使用 CosmosPatchOperations 。我在这里添加了一个增量，如下所示 cosmosPatch.increment("/counter", 1) 效果很好。

现在这个应用程序可以运行多个实例，所有实例都与 cosmos 容器中的同一个文档进行通信。所以App1和App2都可以同时触发增量。 SDK 方法返回更新后的文档，我需要使用该更新后的值。

我的问题是，这里的cosmos DB是否采用某种锁定机制来确保两个补丁相继发生，并且在这种情况下，我在App1和App2中获得的更新值是什么(SDK方法)返回更新后的文档)。其中一个是 2 个，另一个是 3 个吗？

Couchbase 在集群级别支持此类计数器，如所述 here它对我来说工作得很好，没有任何并发​​问题。我现在正在迁移到 cosmos Db，并一直在努力寻找如何实现这一目标。

更新1:

我决定对此进行测试。我在本地 Mac 中设置了 Cosmos 模拟器，并创建了一个 DB 和容器，并且 RU 会自动从 1 增加到 10K。然后在这个容器中我添加了一个像这样的文档 -

{
"id": "randomId",
"counter": 0
}

在这篇文章中，我创建了一个简单的 API，其职责是在每次调用时将计数器加 1。然后我用了 locust多次调用此 API 来模拟小型负载场景。最初，测试运行良好，每次调用都像预期的那样接收计数器(以增量方式)。在增加负载时，我看到一些错误，即 RequestTimeOutException状态代码 408。其他请求仍然可以正常工作，并获得正确的计数器值。我不明白是什么导致了这里的 RequestTimeOut 异常。堆栈跟踪暗示与并发有关，但我无法理解它。这是堆栈跟踪-

更新 2:Update 1 中的测试运行是在我的本地计算机上完成的，我意识到本地计算机上可能存在资源问题，导致这些错误。决定在预生产环境中使用实际的 cosmos DB 而不是模拟器进行测试。

测试配置-

1. 具有 RU 的 Cosmos DB 容器可自动从 400 个扩展到 4000 个
2. 2 个应用程序实例共享负载。
3. 用于摄取应用程序负载的 Locust 脚本

调查结果-

直到约 170 TPS，一切都运行顺利。除此之外，我注意到属于 2 个不同桶的错误 -

1. "exception": "["请求率较大。可能需要更多请求单元，因此未进行任何更改。请稍后重试此请求。了解更多信息:http://aka.ms/cosmosdb-error-429"]"。

我不确定 170 个奇怪的补丁操作如何会耗尽 4000 个 RU，但这完全是一个不同的讨论。

"exception": "["已尝试对资源进行冲突请求。重试以避免冲突。“]”，状态代码 449。

此错误清楚地表明 Cosmos DB 不处理并发请求。我想了解他们是否在内部维护一个队列来处理某些请求，或者他们根本不处理任何并发写入。

Answer 1

PATCH 与其他操作没有什么不同，从根本上来说 CosmosDB 实现了 Optimistic Concurrency Control与具有这些机制的关系数据库不同。乐观并发控制 (OCC) 允许您防止更新丢失并保持数据正确。 OCC可以通过文档的etag来实现。 Azure Cosmos DB 中的每个文档都有一个 E_TAG属性。

在你的场景中，是的，它会在其中一个返回 2，在另一个返回 3，因为两者都得到 succeeded ，因为SDK有重试机制，这里解释一下。另请看看这个sample .

If your Azure Cosmos DB account is configured with multiple writeregions, conflicts and conflict resolution policies are applicable atthe document level, with Last Write Wins (LWW) being the defaultconflict resolution policy