系统稳定性的基石：限流在 AutoMQ 中的最佳实践

前言

限流是系统在应对突发流量时保证自身运行稳定性而采取的典型操作，常见的的限流算法有固定窗口限流、滑动窗口限流、令牌桶限流和漏桶限流等 [1]，具体的算法原理和实现方式当前已有大量文章介绍，本文不再赘述。本文将着重介绍 AutoMQ 中如何通过限流机制应对不同场景的需求。

流量平滑

限流的最典型作用就是用于平滑尖刺，而 AutoMQ 由于其基于 S3 的架构，也存在着一些具有短时量大的请求特征，为避免这类请求影响系统的稳定性，AutoMQ 使用了对应的限流策略进行平滑处理

平滑上传

AutoMQ 的消息处理链路如下图所示：

当消息在内存中攒批完成后会触发上传至 S3，由于攒批的默认大小一般为数百 MB，每次触发上传时意味着一次性向网络中写入数百 MB 的数据，从而产生一次较大的网络尖刺，在机器带宽受限的情况下，可能导致正常消息收发链路延迟毛刺，影响业务稳定性，而理想的流量特征应为上传速率与发送速率相匹配，也即平滑上传流量。

但除正常发送链路攒批上传 S3 外，当发生分区迁移，节点 failover 等事件时，AutoMQ 也会将缓存中的分区数据强制上传至 S3，以保证分区在新节点能够读取完整数据，此时上传时效比流量平滑优先级更高。而由于 AutoMQ 采用了单线程模型实现数据上传，故在这类场景中还需要动态调整正在上传中的任务，使其尽可能快的完成，避免对分区迁移或节点 failover 造成阻塞。为满足上述需求，AutoMQ 基于 Guava 中的 RateLimiter 实现了一个可动态