java - 同时交易是否有每个请求的限制？

Question

我在我的应用程序中使用了很多(分片)计数器。根据我目前的设计，单个请求可以导致 100-200 个不同的计数器递增。

因此，对于每个计数器，我都选择了一个我正在递增其值的分片。我正在递增事务中的每个分片，这意味着作为处理单个请求的一部分，我最终将执行 100-200 个事务。自然地，我打算异步执行此操作，这样我基本上可以并行运行所有 100-200 个事务。

由于这个数字感觉相当高，我想知道是否对同时事务(或数据存储区请求)的数量有一些针对每个请求或每个实例的限制。我无法从文档中找到这方面的信息。

顺便说一句，出于某种原因，Google 的文档指出“如果您的应用程序具有频繁更新的计数器，则不应以事务方式增加它们”[1]，但另一方面，他们关于分片计数器的代码示例使用事务增加分片 [2]。我认为只要使用足够的分片就可以使用事务。我更喜欢事务，因为我希望我的计数器不会错过增量。

1. https://cloud.google.com/appengine/docs/java/datastore/transactions
2. https://cloud.google.com/appengine/articles/sharding_counters

Answer 1

这里的三个限制可能会给您带来问题:

• 每个实体组 1 次/秒的写入限制
• 每个 XG 5 个实体组
• 每个实例 10 个并发“线程”

最后一个对于您的用例来说是棘手的。

很难找到关于它的信息(实际上可能是过时的信息 - 所以它值得测试)，但每个实例只允许 10 个并发核心线程(无论大小 - F1/F2/F ... ).

也就是说，忽略后台线程的创建，如果您假设每个请求都需要一个线程，就像每个 RPC(数据存储、内存缓存、文本搜索等)一样，您一次只能使用 10 个。如果调度程序认为传入请求会超过 10，它会将请求路由到新实例。

在您想要并行写入 100 个实体的场景中，我希望它只允许大约 10 个并发写入(其余阻塞)，而且您的实例一次只能服务一个请求。

你的选择:

• 使用专用内存缓存 - 您需要将计数器备份到持久存储中，但您可以在后端分批执行此操作。这可能会导致您因刷新而丢失一些数据，无论是否可以，您都必须决定
• 使用 CloudSQL 序列或表 - 如果您不需要大规模，但确实需要很多计数器，这可能是一个好方法 - 你可以将计数存储为原始计数或时间序列数据，并且精确计数的后处理
• 使用拉取队列在后端批量更新计数器。您可以批量处理多个柜台表中的多个“事件”。缺点是计数在任何给定时间点都不是最新的

最好的方法可能是混合方法。

例如，接受一些最终的计数一致性:

• 当一个请求进来时——内存缓存中计数器的原子增量
• 当请求进来时 - 排队“事件”任务
• 从内存缓存提供所需的计数——如果不存在则从数据存储加载
• 在内存缓存上使用 TTL，以便最终将数据存储视为“真实来源”
• 运行一个 cron，每 5 分钟(或适当时)从队列中拉出 100 个“事件”任务，并更新数据存储中事务中所有事件的计数器

更新:我在文档中找到了这一部分，talking about controlling max number of concurrent requests , 它模糊地引用了

You may experience increased API latency if this setting is too high.

我会说它值得一试。