MySQL 8.4 发行说明
组复制确保事务仅在组中的大多数成员收到该事务并就所有并发发送的事务之间的相对顺序达成一致后才提交。这种方法在写入组的总数不超过组中任何成员的写入能力时效果很好。如果超过了这个限度，并且某些成员的写入吞吐量低于其他成员，特别是低于写入成员，那么这些成员可能会开始落后于写入成员。
有一些成员落后于组会导致一些问题，特别是，这些成员上的读取可能会外部化非常旧的数据。根据成员落后的原因，组中的其他成员可能需要保存更多或更少的复制上下文才能满足来自慢速成员的潜在数据传输请求。
但是，复制协议中有一个机制可以避免在应用事务方面，快速成员和慢速成员之间存在过大的距离。这被称为流量控制机制。它试图实现以下几个目标
使成员之间的距离足够近，以使成员之间的缓冲和不同步成为一个很小的问题；
快速适应不断变化的条件，例如不同的工作负载或组中更多的写入者；
让每个成员获得可用写入能力的公平份额；
不要比严格必要时更多地降低吞吐量，以避免浪费资源。
鉴于组复制的设计，是否进行节流的决策可能是根据两个工作队列做出的：(i) 认证队列；(ii) 二进制日志应用程序队列。当这些队列之一的大小超过用户定义的阈值时，就会触发节流机制。只配置：(i) 是否在认证器级别或应用程序级别进行流量控制，或者同时进行；(ii) 每个队列的阈值是什么。
流量控制依赖于两种基本机制
监控成员以收集有关所有组成员的吞吐量和队列大小的一些统计数据，以便对每个成员应该承受的最大写入压力做出明智的猜测；
限制尝试超出其在每个时刻的可用能力的公平份额的写入成员。