支付网关的限流原理

我们去公园或者饭店都有限流的情况，比如特殊时期某公园限流50%，饭店不能超过30%等政策；这些场景限流就是限制的人的数量，限流的原因除了特殊因素以外也是受场所里的空间以及设施的承载量所决定；这些场景的限流，通过控制门票数量或者进出的人流速度得到控制，或者座位的可用数量也可以得到控制。本质原理就是有一个池子（门票）资源控制有多少人可以进出

支付也会限流 跟处理性能 并发承载  网关需要做限流控制 保证内部稳定  工行查询 每5分钟一次 每次 多少条

对于支付同样也是，小的支付机构因为本身技术能力，系统健壮性，服务处理能力，物理存储能力等各方面因素决定了一个能够承载并发的上限，超过这个上限系统就会崩溃，支付被延迟，成功率急速下降等不良后果

曾经接过一个通道，其查询限制在频次上不能低于2分钟1次，在单次查询的数据条数上不能超过1000条；同样各种云也会有下载的数据条数限制；这些都是为了保证良好的业务性能。你可以想想支付宝在双11的支付请求切到某一个普通的三方支付公司会怎么样，必然会瞬间瘫痪，大量用户支付超时、失败；这就是支付为何需要做限流的原因

当然限流是一个技术范畴的问题，产品经理也无法去评估和设计应该限流多少；除了那些基于商业模式需要做流量特殊限制的场景之外，产品可以去做方案设定，比如某些网盘非会员的下载速度是多少，充了会员又是多少，这些更多就是商业模式使然，其技术能力肯定是足够的

我们先树立对要限制的对象的限制维度的认识，就像我们认识物理上的速度、重量、长度一样，可以限制速度、限制重量、限制高度；支付上我们要限制的维度也可以很丰富，比如可以限制请求频次、请求文件的大小、请求的条数等等

对于支付网关来说，承载着内部网络和体系的安全和稳定，所以需要控制请求网关的频次以及数量，那如何实现支付的限流呢，这里我们介绍一个“令牌桶”的模型；了解其基本原理和模型，也有助于理解日常工作中各类场景的并发设定

令牌桶大家可以想象存在一个有固定容量的桶，并且往里面以稳定的速度或者可以被控制的速度存放“令牌”，而当数据来请求时需要先为请求分发令牌，这个跟门票很类似，有足够的令牌时请求才会被接受，没有足够令牌时，请求的数据要不被拒绝丢弃，要不放入缓存或者排队队列当中；这就是令牌桶限流的基本原理

基于更复杂的工作场景以及限流诉求，我们可以基于以上的基础限流桶，做更复杂的限流控制，比如可以控制速度、控制频次、控制数量、控制大小等等，实现一个复杂的更智能策略的“令牌桶矩阵”  

掌握基本原理的意义就是可以去应对复杂多变的场景和需求，支付限流也是，这个需求可能是性能瓶颈本身产生的，也可能是业务的商业模式产生的，或者是政策要求产生的；但无论多么复杂的场景，都离不开基础原理；这也是为什么基础学科非常重要了