面试官：听说你是公司技术一号位，那我就考考你吧
面试官：不用慌尽管说，错了也没关系😊。。。
以【面试官面试】的形式来分享技术，本期是《业务设计系列》，感兴趣就关注我吧❤️
面试官：知道有什么限流算法吗
知道的，我了解的主要有计数器算法、令牌桶算法、漏桶算法。
面试官思考中…
面试官：你讲一讲它们的原理
Ok好的。
- 计数器算法比较简单，主要是通过一个计数器判断单位时间访问量是否到达了阈值，从而进行限流。
- 令牌桶算法的话，例如一个令牌桶里容量最多是10个令牌，程序会按0.1秒的固定速率向桶里放入一个令牌，用户请求只有获得令牌后才能执行，这样就实现了1秒限流10次的功能。
- 漏桶算法的原理主要是有一个固定容量、有洞的桶，把用户请求当成是水滴，如果水滴从洞口流出的速率超过了阈值，其他再进来的用户请求就会被拒绝。
另外漏桶算法的流出速率是相同的，不能像令牌桶算法一样可以处理瞬时流量。
面试官思考中…
面试官：你们公司用的限流方案，可以讲讲吗
限流的话，我们一般是在接入层进行限流，主要对两方面进行限流。
-
对于ip的限流，我们是直接使用了Nginx的限流，Nginx的
limit_req_zone可以设置每个IP地址在单位时间内所允许发起的请求数。 -
而对于URL的限流，我们使用的是Nginx + Redis + Lua脚本的方案。
一个Nginx节点都会对应着一个独立的Redis节点，当请求来临时，Nginx会向Redis发起Evalsha命令执行Lua限流脚本验证请求次数是否已达限流阈值。
面试官思考中…
面试官：应该有在应用层进行限流吧
噢噢有的，对于某些业务接口我们也会进行限流，例如一个抢购场景。
我们会限制好目标SKU在单位时间内允许的最大抢购次数，超出所设定阈值的话就会会拒绝后续用户的抢购请求。
面试官思考中…
面试官：这种不是硬编码吗，可以怎么升级吗
确实这种硬编码的方式，给系统带来了限流代码侵入性的问题，也增加了复杂度。
可以引入一个流控平台，使用注解方式就可以实现对业务接口的限流，同时有一个总的平台来监控应用层的限流状态。
例如使用类似Sentinel这种轻量级的流控中间件。
面试官思考中…
面试官：还知道其他也可以限流的方案吗
emmmm，其实还可以从业务角度出发，这种方式也能实现限流，不过更准确应该是叫流量削峰。
我知道的有两种方法，主要是利用了时间分片。
- 例如一个抢购活动有3万件库存，我们可以在一天分为早、中、晚，每个时间段抢购1万件商品。保证了活动正常进行，也为我们系统减少了流量压力。
- 也可以在抢购按钮上，增加一个答题验证进行流量削峰，同样能实现相同的效果。
面试官抓抓脑袋，继续看你的简历…
得想想考点你不懂的😰
未完待续。。。。。。
好了，今天的分享就先到这，我们下期继续。
创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️
