本身没有吞吐量限制，但为了保证事务的原子性，更新必须进行序列化并按顺序逐个应用。因此，如果您进行足够的更新，事情就会开始失败/超时。这称为数据存储争用：
单个实体或实体组更新过快时将发生数据存储争用。数据存储器将排队并发请求以等待它们的轮到。在超时期限内等待在队列中的请求将抛出并发异常。如果您希望每秒更新单个实体或写入实体组多次，则最好在部署应用程序之前重新设计，以避免可能的争用。
简单回答您的问题，它具体指的是每个实体组的写入次数（约5次/秒），这只是一个经验法则，您可能会有不同的结果。
有些人报告根本没有争用，而其他人则难以获得每秒更新超过1次的问题。可以想象，这取决于操作的复杂性以及执行期间涉及的所有计算机的负载。
每个实体组每秒最多只能进行一次写操作（每秒钟向实体组写入次数限制为 1）。这是一个记录在文档中的限制，实际上似乎是一个“软”限制，也就是说可能会超过该限制，但不保证允许。如果在过去的一秒钟内已经对实体进行了写入，则事务将“阻塞”，但 API 也允许短暂性的异常情况发生。显然，您还可能会受到超时的影响。
这并不影响应用程序的总事务数，只与特定的实体组相关。如果需要，您可以设计数据模型的某些部分以避免此限制。
每个 XG 事务最多可以涉及 25 个实体组，这意味着一个事务的上下文中不能包含超过 25 个实体组（读取、写入等操作）。这曾经是 5 的限制，但最近已经增加。
因此，回答你的直接问题：
在一个非严格的第二时间窗口内，为整个实体组（由根键定义）编写
人为强制执行每秒一次的软规则
