高可扩展微服务架构下：基于clientId的非丢弃式对外HTTP限流设计

针对penguin多实例调用单实例raven的场景，需要实现同一ClientId请求间隔至少5秒、不丢弃请求、支持动态ClientId扩展的限流逻辑，以下是具体设计方案：

核心设计原则 #

1. 全局状态共享：所有penguin实例必须共享每个ClientId的最后请求时间，避免多实例并发发送违反限流规则。
2. 请求串行化处理：同一ClientId的请求必须按顺序排队，保证间隔时间严格符合要求。
3. 无请求丢失：未满足限流条件的请求必须暂存，等待条件满足后再发送。
4. 高扩展性：支持penguin实例水平扩容，同时兼容ClientId数量动态增长。

方案一：分布式锁+Redis状态存储+本地延迟队列 #

组件选型 #

• Redis：存储每个ClientId的最后请求时间戳，支持过期自动清理闲置ClientId数据。
• Redis分布式锁：针对单个ClientId加锁，保证同一时间只有一个penguin实例处理该ClientId的限流逻辑。
• 本地延迟队列：暂存未满足限流条件的请求，结合定时任务实现延迟发送。

具体实现流程 #

1. 请求接收与ClientId提取：penguin收到falcon的请求后，从请求体中提取clientId。
2. 获取分布式锁：尝试获取lock:client_rate_limit:{clientId}的锁（锁过期时间设为10秒，避免实例宕机导致锁永久持有）。
   • 若获取锁成功：
     1. 查询Redis中client_rate_limit:{clientId}的最后请求时间戳lastSendTime。
     2. 计算当前时间now：
        • 若now - lastSendTime >= 5000ms：直接发送请求到raven，更新Redis中该ClientId的时间戳为now，释放锁。
        • 若now - lastSendTime < 5000ms：计算需要等待的时间waitTime = 5000 - (now - lastSendTime)，将请求放入本地延迟队列，设置延迟waitTime后执行发送任务；发送完成后更新Redis时间戳，释放锁。
   • 若获取锁失败：直接将请求放入本地延迟队列，等待后续重试处理。
3. 延迟队列处理：后台线程监听本地延迟队列，到达延迟时间后重复步骤2的锁获取与发送逻辑。

关键细节 #

• Redis数据清理：为client_rate_limit:{clientId}设置1小时过期时间，闲置ClientId的数据自动回收，节省内存。
• 时间同步：所有penguin实例通过NTP同步系统时间，避免时间差导致限流逻辑错误。
• 请求持久化：若需防止实例宕机丢失队列请求，可将本地队列替换为Redis List或RabbitMQ等分布式持久化队列。

方案二：一致性哈希路由+本地限流（性能优化版） #

如果penguin的请求量较大，分布式锁的竞争会带来性能损耗，可采用以下优化方案：

核心思路 #

通过一致性哈希路由，将同一clientId的请求固定路由到同一个penguin实例，这样每个实例只需维护自身负责的ClientId的限流状态，无需分布式锁和全局状态存储。

具体实现 #

1. 路由层配置：在penguin服务前端添加网关/负载均衡器（如Nginx、Spring Cloud Gateway），配置基于clientId的一致性哈希路由规则。
2. 本地限流逻辑：每个penguin实例维护本地的clientId -> lastSendTime映射（用Guava Cache或本地HashMap，配合过期清理），以及本地延迟队列。
3. 请求处理流程：实例收到请求后，直接查询本地状态计算等待时间，无需分布式锁，处理逻辑同方案一的单实例逻辑。

优势 #

• 避免分布式锁竞争，性能更高。
• 本地状态存储延迟更低，响应更快。
• 实例扩容时，一致性哈希只会重新分配部分ClientId的路由，不会影响全局。

示例场景验证 #

场景：penguin在12:05:00发送clientId=xyz的请求R1到raven，12:08:00收到同一ClientId的请求R2。

1. R2到达后，penguin获取xyz的锁（或路由到对应实例），查询到lastSendTime=12:05:00。
2. 计算waitTime=5000ms - (12:08:00 - 12:05:00) = 2000ms，将R2放入延迟队列。
3. 12:10:00到达后，发送R2到raven，更新lastSendTime为12:10:00，完成流程。

扩展性考量 #

• penguin实例扩容：方案一直接添加实例即可，共享Redis状态；方案二通过一致性哈希自动分配新的ClientId分片。
• ClientId增长：Redis的键值对或本地Cache均支持动态创建，配合过期清理不会产生内存压力。
• raven扩容：若后续raven扩容，可调整限流规则（如缩短间隔时间），只需修改waitTime的计算逻辑即可。

内容的提问来源于stack exchange，提问作者pankaj