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

因此，从所有成员获取的指标是计算每个成员容量的基础：如果成员具有大型队列（用于认证或应用线程），则执行新事务的容量应该接近在上次期间内认证或应用的事务。

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

这意味着每个成员都根据可用容量建立了写入配额，换句话说，它在下一个期间内可以安全地发出一定数量的事务。如果认证器或二进制日志应用程序的队列大小超过用户定义的阈值，则节流机制会强制执行写入配额。

配额会因上次期间内延迟的事务数量而减少，然后还会进一步减少 10% 以允许触发问题的队列减小其大小。为了避免队列大小超过阈值后吞吐量出现大幅跳跃，此后吞吐量只允许每期间增长相同的 10%。

当前的节流机制不会惩罚低于配额的事务，但会将超出配额的事务延迟到监控期间结束时才完成。因此，如果对已发出的写入请求来说配额非常小，则某些事务的延迟可能接近监控期间。