举个例子，我们有两台服务器实例，对应的是同一个应用程序（Application.name相同），程序中设置的QPS为100，将应用程序与同一个控制台程序进行连接，控制台端依据应用的实例数量将QPS进行均分，动态设置每个实例的QPS为50，若是遇到两个服务器的配置并不相同，在负载均衡层的就已经根据服务器的优劣对流量进行分配，例如一台分配70%流量，另一台分配30%的流量 。面对这种情况，控制台也可以对其实行加权分配QPS的策略 。
客观来说，这是一种集群限流的实现方案，但依旧存在不小的问题 。该模式的分配比例是建立在大数据流量下的趋势进行分配，实际情况中可能并不是严格的五五分或三七分，误差不可控，极容易出现用户连续访问某一台服务器遇到请求驳回而另一台服务器此刻空闲流量充足的尴尬情况 。
3.发票服务器
这种方案的思想是建立在Redis令牌桶方案的基础之上的 。如何解决每次取令牌都伴随一次网络开销，该方案的解决方法是建立一层控制端，利用该控制端与Redis令牌桶进行交互，只有当客户端的剩余令牌数不足时，客户端才向该控制层取令牌并且每次取一批 。
这种思想类似于JAVA集合框架的数组扩容，设置一个阈值，只有当超过该临界值时，才会触发异步调用 。其余存取令牌的操作与本地限流无二 。虽然该方案依旧存在误差，但误差最大也就一批次令牌数而已 。
6.开源项目上面说了三种分布式限流方案的实现思路，这里推荐一个基于发票服务器思想实现的分布式限流项目SnowJean（https://github.com/yueshutong/SnowJena） 。
笔者通过该项目源码观察到该限流项目在解决分布式限流上的有很多巧妙的点，比如，SnowJean内部使用观察者模式实现动态规则配置，使用工厂模式实现限流器的构造，使用建造者模式构建限流规则 。
在解决如何对客户端实例的健康状况进行检查时，利用的是Redis的过期时间与客户端发送的心跳包（发送心跳时再进行延期） 。比较不错的一点是，该项目提供基于前端Echarts图表的QPS视图展示，如下图 。
文章插图
作者： 薛勤
出处：https://www.cnblogs.com/yueshutong/p/11110455.html
推荐阅读
- 浪潮TS850服务器，MegaRAID卡，如何做RAID?
- 微信最新封杀违规外链的几点看法
- “秋老虎”虽热，实已入秋，秋季养生，宜收敛养性，饮食微酸
- 微软|一键为Win11还原经典任务栏+开始菜单的工具发新版：更好用了
- 沂源翠微高山茶香起来
- 名茶小镇全情服务亚洲空手道赛前训练
- 山东,沂源翠微高山茶香起来
- 茶香四溢 临安电力服务暖人心
- 如何使用pssh自动化工具批量管理linux服务器
- 步步深入MySQL：架构<查询执行流程>SQL解析顺序