区块链底层平台的流控分析及实践

流量控制是为了解决在面对不确定的和不稳定的流量冲击下，依旧能够保障系统的稳定运行。如果不对系统实施过载保护，大量流量冲击可能影响系统稳定性，甚至引起“雪崩效应”，导致系统崩溃，停止服务。

当无法预测和控制入口流量时，则系统需要进行流量控制。要想达到系统流控的效果，系统流控策略需要从系统整体架构出发，站在系统流量来源、系统总体架构、系统模块资源分配等角度进行分析，从而制定出符合系统的流控策略。

流控纬度分析

▲ 流量来源角度

区块链节点的入口流量大体分为两种，一种为客户端发送过来的请求，请求可能为区块链数据查询、发送新交易、合约操作等（下文将简称为“客户端请求”）。节点接收到客户端请求后，首先需要从网络IO流中读取到请求的字节内容，然后反序列化字节内容为结构化内容，最后根据结构化请求体调用对应的API逻辑；另一种为其他区块链节点发过来的网络消息，区块链系统底层是由多个共识节点组成的共识网络，节点间通过计算机网络进行信息传输（下文将简称为“节点间网络消息”）。节点接收到对端节点发送过来的网络消息后，根据消息类型，抛给对应的模块去处理。

因此，不仅需要对客户端请求进行流量控制，防止大量突发外部请求都往同一个节点发送，耗尽目标节点资源导致目标节点服务瘫痪。还要对节点接收到的网络消息进行限流，防止节点在高负载下，前面的消息涉及的系统逻辑还未处理完，还源源不断地接收和缓存后面到来的消息，甚至导致节点内存溢出。总结起来，即区块链节点入口流量有两种，一种为客户端请求，另一种为节点间网络消息，需要分别对这两类流量进行限流。

▲ 总体架构角度

同一个节点或分区内的不同模块，存在资源竞争问题。以趣链区块链底层平台为例，存在网络资源竞争的模块主要包括：

共识模块

区块数据同步模块

NVP模块

文件上传下载模块

其中，共识模块是决定系统服务质量的关键模块。因此，为了保证系统的高可用，需要保证关键模块的流量得到优先处理，限制非关键模块可使用的流量，避免非关键模块抢占了所有系统资源。

▲ 多分区架构角度

如下图所示，多分区的区块链系统架构下，每个分区都有一条单独的链，虽然同一个节点不同分区间共识、执行和存储完全解耦，但是不同分区共享同一个计算机资源，因此，多分区本质上也存在资源竞争问题。

当多分区架构被应用于业务分区而治场景时，不同分区上运行着不同的业务，如果不对分区流量进行控制，可能存在分区1业务负载极大情况下，分区2虽然空闲，但由于此刻没有空闲计算机资源可用，发往分区2的请求可能需要很久才有响应，甚至出现拒绝服务。因此，多分区架构下，不同分区存在资源竞争，需要对各分区流量进行限流。

▲ 有限带宽角度

有时候，我们不希望节点的运行抢占了所有的网络带宽，导致其他程序无法提供服务，这时就希望机房里分配给节点服务器或者分给某个进程有限的带宽。由于带宽有限，这就要求提高节点带宽利用率，并且保证关键流量被优先传输，优先保证系统稳定性和可用性。

常见流量控制算法

在分析完不同角度的流控后，我们需要选择出适用的限流算法。目前常见的限流算法，主要有以下两种：

漏桶算法

令牌桶算法

▲ 漏桶算法

漏桶算法的原理可以类比为往一个固定大小的桶里盛水，同时，水从桶底漏洞以固定速度流出，如果加水过快，则直接溢出，如下图所示。它可以应用于网络传输限流，计算机每发送一个数据包，如果桶内未满，则把数据包放入桶里，如果桶内已满，则丢弃数据包，与此同时，以固定速度从桶内取出数据包，发送到网络，从而达到强行限制数据平均传输速率的目的。

图片来源于网络

漏桶算法常用于将突发或不稳定流量整形为以固定速度在网络中传输的流量。

▲ 令牌桶算法

对于要求允许某种程度的突发传输，漏桶算法显然无法满足需求，而令牌桶可以做到这一点。令牌桶算法同样定义了一个固定大小的桶，桶里最多可容纳b个令牌，每当有数据包需要发送时，要从桶里取出对应数量的令牌才能发送，如果桶里没有足够令牌，则无法发送。与此同时，以固定速度r往桶里添加新令牌，当桶里令牌数已经达到b个时，丢弃新令牌。

图片来源于网络

令牌桶算法非常适合于针对系统外部请求的限流，当桶内有足够多令牌时，系统在某一时刻可以同时接收并处理多个请求，充分利用到系统资源。

总结来说，令牌桶限流允许突发流量，对于请求的限流、网络带宽限流，更能充分利用系统资源和网络资源，是适用于区块链底层平台系统流控的一种限流方法。

流控实践

最终，我们采用交易拦截器限流 + 消息分发器限流 + 网络带宽限流 组成三道限流阀门，来应对不同业务场景的压力，保证系统具备较高处理能力的同时又能稳定运行，持续可用。

▲ 交易拦截器限流

主要用来限制客户端到节点的流量。具体指在系统达到交易最大处理能力时，接口服务层及早对新交易进行拦截并拒绝，阻止新交易渗透到主流程花费不必要的系统开销，一定程度上让出更多的系统资源去处理未完成的交易。

交易拦截器通过定义拦截规则，来达到限流的目的，最终效果包括：

限制请求速率：通过令牌桶限流算法控制请求速率，并限制节点最多可同时接收并处理的HTTP请求数。

节点高负载下拒绝新交易：当节点交易池已满或者处于异常、异常恢复状态无法进行正常三阶段共识时，拒绝来自HTTP客户端发送过来的新交易，避免交易解析、交易验签带来的CPU消耗。

▲ 带权消息分发器限流

主要用来限制非关键模块的流量，防止带宽、CPU和内存都被非关键模块给占用。具体做法是为各个需要进行网络通信的模块分配带缓存空间的读（R）、写（W）管道，根据模块在系统中所占权重为其管道分配不同的缓存大小。

消息分发器收到一条来自底层P2P网络的网络消息，根据消息类型将消息分发给对应模块进行处理。这条消息首先分发给模块对应的R管道，模块再从R管道按照FIFO原则取出消息，执行相关逻辑，如果R管道消费速度慢于生产速度，导致分发消息时R管道已满，则说明模块内部已处于高负载，丢弃这条消息。为了保证达到系统限流目的，模块从R管道取出消息并处理消息的过程必须是串行的，而模块间的消息并行处理，互不干扰。

举个例子，当非关键模块处于高负载处理能力变慢时，其R管道虽然占满，但是不会影响共识模块消息的处理速度，同时又由于不同模块根据权重R管道大小不同，一定程度上防止节点一直处理非关键模块消息占用过多系统资源而导致共识模块消息无法得到及时处理。

带权消息分发一定程度上降低了各模块由于处理能力差异而相互干扰，提高系统网络消息并行处理能力，保证核心网络消息不被非核心网络消息占去全部系统资源，同时，系统高负载下自动丢弃新接收到的网络消息，防止系统负载过高而崩溃。

▲ 网络带宽限流

本文所提的网络带宽限流特指限制节点间通信的最大出口带宽流量，该实现基于 Guava RateLimiter 限流。开启出口带宽的限制一定程度上会比关闭带宽限制带来一定TPS的损失，前期经过测试，我们发现，TPS大幅下降主要原因在于开启带宽限制后，我们没有对节点处理能力进行“降级”，导致节点有限的带宽都被用于交易转发而无法在规定时间内发送或处理相关共识消息而极易进入异常状态，而异常状态下节点拒绝新交易，最终导致系统整体交易吞吐量大幅下降。

因此，经过适当修改后，当开启节点出口带宽限流时，根据设置的带宽上限值自动计算交易转发速率，通过控制交易转发速率，使得出口带宽可以被共识关键网络消息充分利用。这种网络带宽限流方法，相比直接使用TC限流，一定程度上，可以提高有限带宽下节点运行的稳定性，并且使得TPS下降在预期可接受范围内。

▲ 分区间限流

每个分区通过交易拦截器 + 带权消息分发来达到限流的目的，从而均衡分配各个分区使用的系统资源。这里不再阐述。

总结

本文通过从多个角度对区块链系统流控进行分析，并得出适用于系统的流控策略，有效解决了节点在各压力测试场景下系统不稳定、容易崩溃的问题，同时保证节点高性能和高稳定性。除了上文的实践以外，后续我们还将进行多种优化，包括但不限于读/写请求并发的限流、限流权重动态调整等等。

参考文献

[1] Leaky bucket - Wikipedia

[2] bucket Token - Wikipedia

[3] 超详细的Guava RateLimiter限流原理解析