【算法设计】限流算法

目录

1.现有算法

1.2 维度设计

2.分布式

2.1 redis共享存储

2.1.1 缺点：

2.1.2 优化方案：

2.2 每台机器单独限流 totalth/machineCount

2.2.1 缺点：

2.2.2 优化方案：

---

1.现有算法

	计数器		桶
	计数器	滑动窗口	漏桶	令牌桶
实现	需要一个计数器	需要多个计数器	需要一个桶	需要一个桶
优点	实现简单	允许短时的爆发流量	允许短时的爆发流量， 处理速度恒定	允许短时的爆发流量， 适合处理速度不固定的应用
缺点	无缓冲， 不允许短时的爆发流量	请求处理时间突然拉长后， 处理中的请求会超限	不精确 桶满了就拒绝， 即使新的周期内流量并未超限	不精确 桶空了就拒绝， 即使新的周期内流量并未超限

比较常用的桶类别，比如我们的系统选择漏桶实现，redis的某个key

漏桶	令牌桶

1.2 维度设计

限流的维度的选择大概有以下2种：

key分散	用户、ip等离散值比较多的维度 key多，占用内存大
key聚集	针对产品线、商户等比较集中的维度 热点key问题

2.分布式

2.1 redis共享存储

2.1.1 缺点：

1. 热点key：一个key的流量非常大，会导致对同个key的频繁原子读写，势必成为瓶颈。
2. 依赖redis可用性：对存储数据的服务要求比较高，分key后存储并不是瓶颈，cpu是瓶颈，需要根据限流阈值预先分配存储机器，每加一个限流业务，就得扩容

2.1.2 优化方案：

sharding思想：将1个key的读写，随机分散到多个key上，只要保证分散的足够均匀，就不会出现提前触发限流的情况发生。

2.2 每台机器单独限流 totalth/machineCount

2.2.1 缺点：

问题	描述
易触发	每台机器的阈值低，容易提前触发限流 流量分布不均衡，会导致部分机房提前触发限流
维护困难	扩容/缩容/故障/下线等机器数发生变化，及时修改

2.2.2 优化方案：

1. 小阈值情况从服务注册处感知节点变化实时计算限流
2. 从入口处（nginx等）保障流量均衡