关于java:项目如何实现限流

我是3y，一年CRUD教训用十年的markdown程序员长年被誉为职业八股文选手

明天持续来更新austin我的项目的内容，次要讲讲限流这块

01、为什么AUSTIN我的项目须要限流

家喻户晓，服务器能解决的申请数是无限的，如果申请量特地大，咱们就可能须要做限流。

限流解决的姿态：要么就让申请期待，要么就把申请给扔了

从零碎架构来看，咱们的对立解决入口在austin-api接入层上，austin-api接入层做完简略的参数校验以及参数拼接后，就将申请转发到音讯队列上了

按失常来说，因为接了音讯队列且接入层没有什么耗时的操作，那对外的接口压力不大的。

没错的，austin要接入限流也并不是在austin-api接入层上做，是在austin-handler音讯解决下发层。austin-handler音讯解决下发层咱们是用线程池去隔离不同的音讯渠道不同的音讯类型。

在零碎自身上其实没有性能相干的问题，但咱们下发的渠道可能就须要咱们去管制调用的速率。

腾讯云短信默认限度3000次/秒调用下发接口

钉钉渠道对利用音讯和群机器人音讯都有接口调用的限度

....

在保障下发速度的前提下，为了让业务方所下发的音讯其用户能失常接管到和上游渠道的稳定性，咱们须要给某些渠道进行限流

于是在这个背景下，我目前定义了两种限流策略：

1、依照申请数限流

2、依照下发用户数限流

想要实现限流，摆在咱们背后有两个抉择：

1、单机限流

2、分布式限流

咋一看，线上不可能只部署一台机器去发送整个公司的音讯推送的，咱们的零碎利用在线上环境相对是集群部署的，那必定就须要上分布式限流了，对吧？

但实际上分布式限流实现并不简略，目前分布式限流的计划个别借助两个中间件

1、Redis

2、Sentinel

咱们可能会用Redis的setnx/incrby+expire命令(从而实现计数器、令牌桶限流)/zset数据结构(从而实现滑动窗口限流)

Redis实现的限流想要比拟精确，无论是哪种形式，都要依附lua脚本

而Sentinel反对单机限流和分布式限流，Sentinel分布式限流须要部署Token服务器

对于分布式限流而言，不论用哪一种计划，应用的老本和技术挑战都是比拟大的。

如果用单机限流的话，那就简略得多了，省事间接用Guava包下的RateLimiter就完了。毛病就在于：它只能管制单机的限流，如果产生了服务器扩容和缩容，它是感知不到的。

有的人就给出了计划：那我用Zookeeper监听服务器的数量不就好了吗。实践上的确是这样的：每台机器限流值=限流总值/服务器数量

不过这又要去依赖Zookeeper，Zookeeper集群自身也有一堆状态相干的问题。

我是怎么实现的？单机限流一把梭

从下面的形容能够看到，austin的限流我是要做在具体渠道上的，依据现有的代码设计我要的就是在各个的Handler上写下限流的代码。

我自身就设计了BaseHandler抽象类作为模板办法设计模式，此次限流的设计我的是：

1、将flowControl定义为abstract形象办法，子类渠道去实现限流的代码

2、子类在初始化的时候定义限流参数，BaseHandler父类依据限流参数对立实现限流的逻辑

我抉择了第二种形式，次要是我认为对于各个渠道而言，只是限流值是不同的，限流的逻辑应该都是一样的，没必要在每个子类上实现相似的逻辑。

而限流的逻辑就比较简单了，次要就应用RateLimit提供的易用API实现

没错，限流值的大小我是配置在apollo分布式配置核心的。假如当前真的要扩缩容了，那到时候提前把分布式配置核心的值给改掉，也能解决一部分的问题。

扯了半天，原来就用了Guava包的RateLimit实现了单机限流，就这么简略，只是把限流值配置在分布式配置核心上而已。

很多时候，设计简略的代码可能实现并不完满，并不智能，并不优雅，但它付出的代价往往是最小的。

虽说如此，如果大家想要理解Redis+lua实现的同学能够fetch下austin最新的代码，就我写文章这段时间里，曾经有老哥提了pull request用Redis+lua实现了滑动窗口去重的性能了，实质上是一样的。我曾经merge到master分支了。

austin音讯推送平台我的项目源码Gitee链接：gitee.com/austin

austin音讯推送平台我的项目源码GitHub链接：github.com/austin