基于组中所有服务器收集的指标，限制机制启动并决定是否限制成员执行/提交新事务的速率。

因此，从所有成员收集的指标是计算每个成员容量的基础：如果成员具有大队列（用于认证或应用程序线程），那么执行新事务的容量应该接近于上一期认证或应用的数量。

组中所有成员的最低容量确定了组的实际容量，而本地事务的数量决定了有多少成员正在写入它，从而决定了可用的容量应该与多少成员共享。

这意味着每个成员都基于可用的容量设定了写入配额，即可以安全地发出的事务数量。写入配额由限制机制强制执行，如果认证器或二进制日志应用程序的队列大小超过用户定义的阈值。

配额减少了上一期延迟的事务数量，然后再减少10%，以允许触发问题的队列减少大小。为了避免队列大小超过阈值时的吞吐量大幅跳跃，吞吐量只允许每期增长10%。

当前的限制机制不惩罚配额以下的事务，而是延迟完成超出配额的事务，直到监控期结束。因此，如果配额非常小，对于写入请求，某些事务可能具有接近监控期的延迟。