微服务场景实战 - 限流 - 如何让服务器在亿级流量冲击下“活下去”
在之前的文章里，我们聊过了秒杀系统的整体架构方案，其中也提到了限流——这个让人又爱又恨的技术环节。因为篇幅所限，我们当时只能浅尝辄止，没来得及展开细说。
那么这一章，我们就来把限流这个问题掰开揉碎，讲个明白。放心，内容依然保持专业与深度，并且尽量说得清楚易懂。
老规矩，为了便于理解，我们还是从一个实际的业务场景开始说起。
1 业务场景：如何让服务器在亿级流量冲击下“活下去”
业务场景：如何让服务器在亿级流量冲击下“活下去”
想象这样一个场景：某次秒杀活动，只有100件特价商品，价格低到让人心动。活动时间定在10月10日晚上10点10分0秒——这时间点选得挺有仪式感，但对系统来说，可能就像一场精心策划的“流量海啸”。
当时的服务架构大致如下图所示：所有用户请求首先到达Nginx层，然后被转发到网关层（基于Java的Spring Cloud Zuul），最后才进入后台业务服务（同样是Java）。这条链路听起来清晰，但秒杀开始瞬间，预测将有无序涌入的海量用户请求——多到系统根本处理不完。
怎么办呢？答案就是限流。为了保证服务器不被冲垮，我们只能理智地选择“放行一部分，拒绝大部分”。这听起来有点残酷，但却是高并发场景下的常见生存策略。
说到这里，容易混淆的两个概念——限流和熔断——值得简单区分一下。虽然它们都是保护系统的手段，但发生的位置和目的不同：
- 熔断通常发生在服务调用方。举例来说，如果服务A多次调用服务B都失败，判断服务B已不可用，那么服务A就会主动“熔断”，暂时停止调用，避免资源浪费并给服务B恢复的时间。
- 限流则主要发生在服务被调用方，尤其在网关层实施。例如，一个电商后台每秒只能处理10万请求，如果瞬间涌来100万请求，系统可能直接丢弃其中90万，只处理剩余的10万。这个比例在秒杀场景下并不夸张——有时甚至舍弃99%的流量都是可以接受的，只为确保系统不崩溃、部分用户能顺利完成交易。
回到我们的具体业务需求：这次秒杀只有100件商品，也就是说，最终成功的交易只有100笔。我们希望把这些交易控制在大约一秒内完成，即将交易TPS（每秒事务数）限制在100笔/秒。
那么问题来了：如何在系统的某一层（比如网关）实现这样的精确控制？这就引出了我们接下来要深入探讨的限流常用算法。
2 限流算法
在明确了需要将交易TPS控制在100笔/秒的目标后，我们来看看实现限流有哪些常用的算法。每种算法各有特点，其适用性也需结合具体场景来判断。
2.1 固定时间窗口计数算法
这是一种最直观的思路。例如，若要求每5秒处理不超过500个请求，我们就以5秒为一个固定窗口进行计数。
