课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
分布式编程架构技术我们在前几期的文章中已经给大家简单分析过很多次了,今天我们就一起来了解一下API网关分布式限流的运行原理都有哪些。
API网关中针对一个API、API分组、接入应用APPID,IP等进行限流。这些限流条件都将会产生一个限流使用的key,在后续的限流中都是对这个key进行限流。
限流算法通常在API网关中可以采用令牌桶算法实现。
必须说明一点的是分布式限流由于有网络的开销,TPS的支持隔本地限流是有差距的,因此在对于TPS要求很高的场景,建议采用本地限流进行处理。
下面讨论我们应该采用redis的哪一种分布式锁的方案:
由于redis事务要得到锁的效果需要在高TPS时会产生大量的无效的访问请求,所以不建议在这种场景下使用。
SETNX/EX的锁方案会产生在过期时间的问题,同时也有异步复制master数据到slave的问题。相比lua方案会产生更多的不稳定性。
我建议采用lua的方案来实施分布式锁,因为都是单进程单线程的执行,因此在TPS上和二种方案没有大的区别,而且由于只是一个lua脚本在执行,甚至是可能纯lua执行可能会有更高的TPS。当然是lua脚本中可能还是会去设置过期时间,但是应用server宕机并不会影响到redis中的锁。当然master异步复制的问题还是有,但是并不会造成问题,因为数据只会有1个lua脚本执行问题,下一个执行就正常了。
在实现方案的时候使用了Jedis库,有一些问题在方案的实现层面我已经去做过验证了,可能也会是读者的疑问。
理论上jedis都应该是连接redis集群中的master节点,因为redis主备是采用的主备(Active-Standby方式)的方式。需要确定在这种情况下应该是配置所有的redis节点还是只配置master。理论上是需要配置所有的节点。
答:配置所有节点,做自动转发。
需要测试在其中一个slot组的master挂掉后,slave成为master后,jediscluster的方式还能正常的访问对应的key。从资料上来看是能自动处理的。
答:能自动处理。
因为是采用rediscluster,所以需要测试key存储在slot1组上时,jediscluster连接的是slot2组上的redis服务器,在这种情况下要能正常的调用lua。如果不能要看怎么样调用,因为redis可能会返回"MOVED"指令,这个要看jedis组件有没有实现自动的迁移。
答:能自动处理。
需要测试连接的是salve节点,但是读请求是转给了master节点,salve节点不处理请求。因为是主备(Active-Standby方式)状态。
答:能自动处理,由Jedisjar进行维护节点的状态,查询新的master节点的信息。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!