前言：
涉及到mgr集群flow control的参数如下，默认值如下所示：
group_replication_flow_control_applier_threshold 25000
group_replication_flow_control_certifier_threshold 25000
group_replication_flow_control_hold_percent 10
group_replication_flow_control_max_quota 0
group_replication_flow_control_member_quota_percent 0 group_replication_flow_control_min_quota 0
group_replication_flow_control_min_recovery_quota 0
group_replication_flow_control_mode QUOTA
group_replication_flow_control_period 1
group_replication_flow_control_release_percent 50
流控理解：
我们假设3节点的Group中各个节点的性能是不一样的，A节点性能最好，每秒能处理100个事务，B性能次之，能处理80个事务，C性能最次，仅能处理50个事务。如果A节点作为Primary节点，那么每秒就可能有100个事务通过Paxos发送到B和C，由于B、C没有足够的能力处理这些事务，就会导致未处理的事务数据在B、C的认证队列（内存中的队列）和回放队列（Relaylog文件）中堆积，这就出现了数据延迟。
数据延迟有多种危害，比如在正常情况下，用户从B、C节点无法读到较新（uptodate）的数据，在故障场景下，如A节点crash后，B节点成为新的Primary节点，那么其无法马上提供（正常）的读写服务。所以，一个可用的MGR实例，应该是数据延迟可控的集群，
MGR的flow-control（流控）机制就是发挥这样的作用，他确保MGR各个节点的数据延迟尽可能小
MGR基于配额（Quota）进行流控，也就是说，一个Group在一个周期内，只能执行固定数量的事务，这个固定数量就是配额。下面我们通过几个问题来说明流控原理。
1、流控的配额怎么确定呢？通过上面的分析，我们应该采用C节点的事务处理能力作为MGR的流控总配额，再根据该Group中有写操作的节点个数来均分这个配额。比如在单主模式下，Primary节点可分配到50的配额。在多主模式下，如果B和C存在写操作，则他们俩分别可以分配到25的配额。这就是MGR流控的基本原理。
2、流控的对象是谁？MGR的流控机制是控制本节点的负载，而不是其他节点的负载，也就是作用对象是自己当前的节点，这是跟Galera的流控不一样的地方。具体的对象是在本节点上执行的写事务（write transactions），只读事务（readonly transaction）并不在流控的范围内。但由于系统的资源是有限的，一个节点上只读事务多了，势必也会影响本节点的写事务处理能力，进而也就会降低流控的总配额，因此，只读事务能够间接影响流控。
3、流控的数据来源及更新？MGR作为一个整体，各个节点会每秒发送自己的状态信息给其他节点，这些信息中就包含了流控所需的信息。节点会缓存接收到的各节点状态信息，并使用最新的状态信息覆盖历史状态信息。通过计算某个节点前后2次状态信息的差值就可以知道节点的事务执行能力。
4、如何让流控起作用？我们知道MGR是以plugin的方式动态加载到mysql server上的，所以，流控起作用的地方不可能在mysql server，只能可能在plugin内部，但应该尽可能靠近mysql server。现实中，MGR在一个事务进入plugin但还未进行全局原子广播时判断是否需要对该事务采取进行流控。
流控相关参数：
一、group_replication_flow_control_applier_threshold
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_applier_threshold指定 在（applier queue）应用队列中等待的事务数超过这个阈值，就会触发flow control。
待认证的事务数如果超过 group_replication_flow_control_certifier_threshold 的设置，则会触发流控，该参数默认是 25000
二、group_replication_flow_control_certifier_threshold
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_certifier_threshold 指定 触发flow control的阈值，当在认证队列中等待的事务个数超过这个阈值，就会触发flow control；
待应用的事务数如果超过 group_replication_flow_control_applier_threshold 的设置，则会触发流控，该参数默认是 25000
三、group_replication_flow_control_hold_percent
首先基于配额的流控机制，这个配额是针对写入节点而言的，例如通过压测获取到某个节点的配额为500，然后你配置的配额为500（group_replication_flow_control_applier_threshold=500，group_replication_flow_control_certifier_threshold=500）那么当group_replication_flow_control_hold_percent=10的时候，就是说当应用队列中有500*90%=450的时候，就会触发flow control，不让节点提供满负荷的负载，留下的10%的配额，让从库追上主库（前提主库和从库处理能力一样）
若Group中某个节点crash重新加入，其加入后必然会跟存活的节点产生较大的数据延迟，若此时外部负载仍然是实例所能承受的最大值，则新加入的节点就无法通过Catch Up追上其他节点。基于这些的考虑，实际对外提供的配额并不是Group最大能力，而是做了部分保留，具体的保留百分比就是通过该参数确定的。默认预留了10%的处理能力，用于有数据延迟的节点追上其他节点
此系统变量的值可以在组复制运行时更改，更改将立即生效。
预留配额的比例。有效值 0 - 100，默认是 10。预留的配额可用来处理落后节点积压的事务
group_replication_flow_control_hold_percent定义了组配额中未使用的百分比，以允许处于流控制下的集群赶上积压工作。值为0意味着配额中没有保留任何部分用于处理积压工作。
四、group_replication_flow_control_max_quota
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_max_quota定义组的最大流量控制配额，或启用流量控制时任何时段的最大可用配额。值为0表示没有设置最大配额。此系统变量的值不能小于group_replication_flow_control_min_quota和group_replification_flow_contronl_min_recovery_quota。
当前节点下个周期的最大配额。默认是 0，即不限制。
五、group_replication_flow_control_min_quota
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_min_quota控制可分配给成员的最低流量控制配额，与上次期间执行的计算出的最小配额无关。值为0表示没有最低配额。此系统变量的值不能大于group_replication_flow_control_max_quota。
group_replication_flow_control_min_recovery_quota
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_min_recovery_quota控制由于组中的另一个正在恢复的成员而可以分配给该成员的最低配额，而与在上一时段中执行的计算出的最小配额无关。值为0表示没有最低配额。此系统变量的值不能大于group_replication_flow_control_max_quota。
两个参数都会决定当前节点下个周期的最小配额，只不过 group_replication_flow_control_min_recovery_quota 适用于新节点加入时的分布式恢复阶段。group_replication_flow_control_min_quota 则适用于所有场景。如果两者同时设置了， group_replication_flow_control_min_quota 的优先级更高。两者默认都为 0，即不限制；
六、group_replication_flow_control_member_quota_percent
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_member_quota_percent 定义了成员在计算配额时应该认为对自己可用的配额的百分比。值为0意味着配额应在上一个期间的写入者成员之间平均分配。
分配给当前成员的配额比例。有效值 0 - 100。默认为 0，此时，节点配额 = 集群配额 / 上个周期写节点的数量。
建议默认值即可！
注意，这里的写节点指的是有实际写操作的节点，不要理解为 PRIMARY 节点，例如：在多主模式下，配额是50，有三个PRIMARY节点，如果只有B和C存在写操作，则他们俩分别可以分配到25的配额
七、group_replication_flow_control_mode
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_mode指定用于流控制的模式。
是否开启流控。默认是 QUOTA，基于配额进行流控。如果设置为 DISABLED ，则关闭流控。
八、group_replication_flow_control_period
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_period 定义在流控制迭代之间等待的秒数，在这些迭代中发送流控制消息并运行流控制管理任务。
流控周期。有效值 1 - 60，单位秒。默认是 1。
注意，各个节点的流控周期应保持一致，否则的话，就会将周期较短的节点配额作为集群配额。
九、group_replication_flow_control_release_percent
当流控结束后，会逐渐增加吞吐量以避免出现突刺。
下一周期的 quota_size = 上一周期的 quota_size * （1 + group_replication_flow_control_release_percent / 100）。有效值 0 - 1000，默认是 50
此系统变量的值可以在组复制运行时更改，更改将立即生效。
group_replication_flow_control_release_percent 定义了当流控制不再需要限制写入程序成员时，应如何释放组配额，该百分比是每个流控制周期的配额增加。值0意味着一旦流量控制阈值在限制范围内，就在单个流量控制迭代中释放配额。该范围允许配额最多以当前配额的10倍发布，因为这允许更大程度的适应，主要是在流量控制期大而配额很小时。
总结：
1、流控不建议关闭，并且需要合理设置流控阈值，最好根据压测结果得出合理的阈值。
2、流控限制的是当前节点的流量，不是其它节点的。
3、流控参数在各节点应保持一致，尤其是 group_replication_flow_control_period；
4、当一个正常运行的mgr集群的写入成为瓶颈的时候，可以关注下group_replication_flow_control_hold_percent参数，可以把他设置成0，来提高集群的读写能力；
5、查询mgr目前处于 applier queue (应用队列)的事务个数，以及处于待认证队列的事务个数，可以通过如下sql查询：
SELECT MEMBER_ID , COUNT_TRANSACTIONS_IN_QUEUE COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE , COUNT_TRANSACTIONS_CHECKED FROM performance_schema.replication_group_member_stats;
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE： 表示等待被apply的事务队列大小，COUNT_TRANSACTIONS_IN_QUEUE： 表示等待被全局认证的事务队列大小；