Group Replication 确保事务仅在组中的大多数成员收到它并就并发发送的所有事务之间的相对顺序达成一致后才提交。
如果对组的写入总数不超过组中任何成员的写入容量，则此方法效果很好。如果确实如此，并且某些成员的写入吞吐量低于其他成员，尤其是写入者成员，则这些成员可能会开始落后于写入者。
让一些成员落后于组会带来一些问题的后果，特别是，对这些成员的读取可能会外部化非常旧的数据。根据成员落后的原因，组中的其他成员可能必须保存或多或少的复制上下文才能满足来自慢速成员的潜在数据传输请求。
然而，复制协议中有一种机制可以避免快成员和慢成员之间在应用的事务方面有太大的距离。这称为流控制机制。它试图解决几个目标：
让成员保持足够接近，使成员之间的缓冲和去同步化成为一个小问题；
快速适应不断变化的条件，例如不同的工作量或组中更多的作者；
为每个成员提供公平份额的可用写入容量；
不要减少吞吐量超过避免浪费资源的严格必要性。
考虑到 Group Replication 的设计，是否节流的 决定可能会考虑两个工作队列：（i）认证队列； (ii)和二进制日志应用 程序队列。只要其中一个队列的大小超过用户定义的阈值，就会触发节流机制。仅配置：（i） 是否在验证者或应用程序级别或两者进行流量控制；( ii)每个队列的阈值是多少。
流量控制取决于两个基本机制：
监控成员以收集所有组成员的吞吐量和队列大小的一些统计数据，以对每个成员应承受的最大写入压力进行有根据的猜测；
试图在每个时刻及时写入超出可用容量的公平份额的成员的节流。
监控机制的工作原理是让每个成员部署一组探测器来收集有关其工作队列和吞吐量的信息。然后它会定期将该信息传播到该组，以便与其他成员共享该数据。
这样的探测器分散在整个插件堆栈中，并允许人们建立指标，例如：
验证者队列大小；
复制应用程序队列大小；
已认证的交易总数；
会员申请的远程交易总数；
本地交易的总数。
一旦一个成员收到来自另一个成员的带有统计信息的消息，它就会计算有关在上一个监视期间有多少交易被认证、应用和本地执行的额外指标。
监控数据定期与组内其他人共享。监视周期必须足够长以允许其他成员决定当前的写入请求，但又必须足够短以使其对组带宽的影响最小。信息每秒共享一次，这段时间足以解决这两个问题。
基于在组中所有服务器上收集的指标，节流机制启动并决定是否限制成员能够执行/提交新事务的速率。
因此，从所有成员获取的指标是计算每个成员容量的基础：如果一个成员有一个大队列（用于认证或应用程序线程），那么执行新事务的能力应该接近于认证或应用的容量最后一期。
组中所有成员的最低容量决定了组的实际容量，而本地事务的数量决定了有多少成员正在写入它，因此，可用容量应该与多少成员共享。
这意味着每个成员都有一个基于可用容量的既定写入配额，换句话说，它可以在下一个时期安全地发布一些事务。如果验证者或二进制日志应用程序的队列大小超过用户定义的阈值，则限制机制会强制执行写入器配额。
配额减少了上一周期延迟的事务数，然后还进一步减少了 10%，以允许触发问题的队列减小其大小。一旦队列大小超过阈值，为了避免吞吐量大幅跃升，在此之后的每个周期，吞吐量只允许增长相同的 10%。
当前的节流机制不会对低于配额的交易进行处罚，而是延迟完成那些超过配额的交易，直到监控期结束。因此，如果发出的写入请求的配额非常小，则某些事务的延迟可能接近监控周期。