17.9.7.3 流量控制

组复制可确保仅在组中的大多数成员都收到事务并就并发发送的所有事务之间的相对 Sequences 达成一致后，才提交事务。

如果对组的写总数不超过组中任何成员的写容量，则此方法效果很好。如果这样做，并且某些成员的写入吞吐量比其他成员少，尤其是小于写入器成员，则这些成员可能开始落后于写入器。

使某些成员落后于该组会带来一些问题，特别是对此类成员的读取可能会使非常旧的数据外部化。根据成员落后的原因，组中的其他成员可能必须保存或多或少的复制上下文，才能满足慢成员的潜在数据传输请求。

但是，复制协议中有一种机制可以避免快成员和慢成员之间的距离过长。这称为流量控制机制。它试图解决几个目标：

• 使成员保持足够近的距离，以使成员之间的缓冲和不同步成为一个小问题；

• 快速适应不断变化的条件，例如不同的工作量或团队中更多的 Writer；

• 给每个成员公平的可用写容量份额；

• 不会比避免浪费资源所绝对需要的减少吞吐量更多。

给定组复制的设计，可以考虑两个工作队列来决定是否进行限制：(i)“认证”队列； *(ii)和二进制日志 applier 队列上。只要这些队列之一的大小超过用户定义的阈值，就会触发限制机制。仅配置：(i)*是在验证者级别还是在申请者级别或两者同时进行流量控制； *(ii)*每个队列的阈值是多少。

流量控制取决于两个基本机制：

• 监视成员以收集有关所有组成员的吞吐量和队列大小的一些统计信息，以便对每个成员应承受的最大写入压力进行有根据的猜测；

• 试图在每个时间超出其可用容量公平份额的成员的节流。

17.9.7.3.1 探测和统计

监视机制通过让每个成员部署一组探针来收集有关其工作队列和吞吐量的信息而起作用。然后，它将这些信息定期传播到该组，以与其他成员共享该数据。

这些探针分散在整个插件堆栈中，并允许它们构建 Metrics，例如：

• 验证者队列大小；

• 复制申请人队列大小；

• 经认证的 Transaction 总数；

• 成员中应用的远程事务总数；

• 本地 Transaction 总数。

成员收到另一成员的带有统计信息的消息后，它将计算有关上一个监视期内已认证，应用和本地执行的 Transaction 数量的其他度量。

监视数据会定期与组中的其他人共享。监视周期必须足够长，以允许其他成员决定当前的写请求，但又必须足够短，以使其对组带宽的影响最小。信息每秒共享一次，此时间段足以解决这两个问题。

17.9.7.3.2 组复制限制

根据跨组中所有服务器收集的度量标准，将启动限制机制，并决定是否限制成员能够执行/提交新事务的速率。

因此，从所有成员获取的度量标准是计算每个成员的能力的基础：如果一个成员的队列很大(用于认证或申请者线程)，则执行新 Transaction 的能力应接近于已认证或应用的 Transaction 能力。最后一个时期。

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

这意味着每个成员都有一个基于可用容量的已构建写配额，换句话说，它可以在下一个时期安全地发出许多事务。如果验证者或二进制日志应用程序的队列大小超过用户定义的阈值，则将通过限制机制强制执行 writer-quota。

配额减少了上一个期间中延迟的事务数量，然后又进一步减少了 10％，以允许触发问题的队列减小其大小。为了避免队列大小超过阈值后吞吐量大幅度增加，在此之后，每个周期仅允许吞吐量增长相同的 10％。

当前的限制机制不会惩罚低于配额的 Transaction，但是会延迟完成超过配额的 Transaction，直到监视期结束。结果，如果发出的写请求的配额非常小，则某些事务可能具有接近监视周期的 await 时间。