这是《百图解码支付系统设计与实现》专栏系列文章中的第（10）篇。点击上方关注，深入了解支付系统的方方面面。
本篇主要讲清楚常用的并发流量控制方案，包括固定窗口、滑动窗口、漏桶、令牌桶、分布式消息中间件等，以及各种方案在支付系统不同场景下的应用。
在非支付场景，也常常需要用到这些并发流量控制方案。
1. 前言
在互联网应用里面，并发流量控制无所不在。在支付系统中，流量控制同样是一个关键的技术方面，主要用于确保系统的稳定性和可靠性，尤其在高流量的情况下。以下是一些主要使用流量控制的场景：
- 对外API限流：对外提供的API（如支付接口）需要限流来保护后端服务不会过载。
- 保护外部渠道：大促时，对下流渠道的支付流量要做削峰填谷，避免突发流量把渠道打挂。
- 保护内部应用：大促时，内部各应用要根据流量模型配置限流值，避免形成雪崩。
- 满足外部退款限流要求：电商批量提交退款时，支付系统内部要在分布式集群环境下对某个渠道实现低至1TPS的退款并发，避免超过渠道退款并发导致大批量失败。
特别说明的是，流量控制通常包括限流和限速。
我们通常说的限流，就是流量达到一定程度，超过的流量会全部立即拒绝掉，也就是快速失败。比如上面的API限流。
限速一般是指接收流量后，先保存到队列中，然后按指定的速度发出去，如果超过队列最大值，才会拒绝。比如上面的支付流量和退款流量打到外部渠道。
另外，支付和退款流量控制虽然都是流量控制，但有一些细小的区别：
- 支付的限流TPS通常比较高，从十几TPS到几百TPS都有，排队时效性要求很高，秒级内就要付出去。
- 退款的限流TPS通常比较低，在国外的基础设施建设很差，甚至部分渠道要求退款1TPS。但是排队时效性要求很低，几天内退出去就行。
2. 几种方案对比
固定窗口：算法简单，对突然流量响应不够灵活。超过流量的会直接拒绝，通常用于限流。
滑动窗口： 算法简单，对突然流量响应比固定窗口灵活。超过流量的会直接拒绝，通常用于限流。
漏桶算法：在固定窗口的基础之上，使用队列缓冲流量。提供了稳定的流量输出，适用于对流量平滑性有严格要求的场景。后面会介绍如何应用到外部渠道退款场景。
令牌桶算法：在滑动窗口的基础之上，使用队列缓冲流量。能够允许一定程度的突发性流量，但实现较为复杂。
分布式消息中间件：如Kafka和RabbitMQ等，能够有效地对消息进行缓冲和管理，增加系统复杂性，且如果需要精确控制流量还需要引入额外的机制。后面会介绍如何应用到外部渠道支付场景。
3. 固定窗口
固定窗口算法，也称为时间窗口算法，是一种流量控制和速率限制策略。此算法将时间轴分割成等长、不重叠的时间段，称为"窗口"。每个窗口都有一个独立的计数器，用于跟踪窗口期间的事件数量（如API调用、数据包传输等）。
固定窗口算法的好处是简单，缺点也很明显，就是无法应对突发流量，比如每秒30并发，如果前100ms来了30个请求，那么在10ms内就会把30个请求打出去，后面的900ms的请求全部拒绝。
工作流程：
- 窗口定义：首先确定窗口大小，比如1秒钟。
- 计数：每当发生一个事件（比如一个请求到达），就在当前窗口的计数器上加一。
- 限制检查：如果当前窗口的计数器达到预设阀值，则拒绝新的请求。直到下一个窗口开始。
- 窗口重置：当前窗口结束时，计算数器重置为零，开始下一个窗口计数。
可以使用redis实现，比如以时间戳为key，value代表请求数，过期时间为窗口期+5秒（主要是兼容各服务器的时间差）。
需要注意的：下面的设置和加1操作，需要使用lua脚本，保证原子性。
<未完待续>