3.2.4令牌桶算法
文章插图
优点：（1）允许一定程度的突发流量 。（2）通过定制令牌添加方法，可定制复杂的流控策略 。（3）无临界问题 。
不足：（1）当桶内无可用令牌时，输入请求会被直接丢弃 。（2）不支持按优先级处理输入请求 。
4、ROMA Connect流控技术实现4.1总体策略
- 对高精度与高吞吐进行分层，区别不同场景的流控，采用不同策略与算法
- 对高精度低吞吐流控进行持久化； 高吞吐高频纯内存计数策略
- 高吞吐高频流控，不进行 HA 保障，故障后数据清零重新计算
- 多维度多优先级，采用Policy 多维度控制，单一请求可触发多Policy
- 解耦复杂控制，采用多条简单策略分别映射；降低用户使用复杂度
- 单一请求可触发所有满足条件的 Policy，进行综合流控
- 通过分发策略、异步、批申报等机制，降低请求时延与降低Controller 工作量
- 尽可能在 Filter/SDK 级别处理，避免流控请求影响业务时延
- 尽可能少上报到 Controller，降低 Controller 负载提升 Controller 效率
- Filter 与算法门限降级放通，避免Ratelimit机制故障对业务造成影响
- 采用KEY/VALUE 模式和多维，提供通用机制，适应不同场景不同应用流控诉求
- 立足API Gateway第一个应用场景
- Controller 不需理解具体业务，由基于SDK封装的Filter适配具体业务与流控Controller
- RateLimit SDK访问根据一致性hash访问sharding后的RateLimit Controller，对于高吞吐高精度的流控集中在Controller内存进行限流计算 。
- RateLimit Controller对于高精度高吞吐只集中在本地内存计算，无需考虑crash后保留历史限流信息 。
- RateLimit Controller对于高精度低吞吐的限流采取异步持久化策略，确保Controller crash后流控的精度 。
- 当Ratelimit Controller服务终止的时候，Ratelimit SDK支持自动降级 。
- 根据API Gateway采集的API Response latency等信息反馈，支持动态调整流控策略 。
- 支持SLA-Based 流控 Policies 。
文章插图
4.3架构设计
- 采用独立的Controller 方案
- 独立集群 Controller 提供全局精确高吞吐流控
- Controller 内部采用 Sharding 机制
- 采用通用的Policy与Key/Value模型
- 采用可扩展的 Domain/Policy机制，适应不同业务场景
- 不同Policy关联不同的算法
- 提供SDK与Tools，开发API G等插件
- 提供可重用的SDK与调试工具等
- 预实现API Gateway等流控插件
- 外置日志、流控数据分析模块
- 通过数据挖掘、预测等反馈到配置/策略管理模块，动态修订流控策略
文章插图
4.4内置算法4.4.1带缓存带颜色的令牌桶算法
- 令牌桶算法的问题：
- 当无可用令牌时，请求会被立即拒绝 。而用户可能会继续不断发送请求，直到有可用的令牌 。这会增加API Gateway的负载和流控服务的负载 。
- 所有的请求以同样的概率获得令牌，不支持优先级 。而在实际应用中，一些请求需要被优先处理，另一些请求可以被延迟处理或者直接拒绝 。例如，应该优先处理电子商务网站的付款请求，而浏览商品的请求可以被延迟处理 。
经验总结扩展阅读
- Go_Goroutine详解
- Go_Channel详解
- Docker | 容器数据卷详解
- MyBatis之ResultMap的association和collection标签详解
- Future详解
- Go的网络编程详解
- gorm中的关联操作详解
- Go中的闭包、递归
- liunx之expect操作详解
- 条件期望：Conditional Expectation 举例详解之入门之入门之草履虫都说听懂了
