Redis限流实现

令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量。令牌桶内令牌生成借鉴Guava-RateLimiter类的设计 ，每次getToken根据时间戳生成token，不超过最大值。核心参数：last_mill_second 最后时间毫秒curr_permits 当前可用的令牌max_burst 令牌桶最大值rate 每秒生成几个令牌app 应用名称 local ratelimit_info=r

OpenResty实现限流的几种方式

本文转载自：http://www.itzh.org/2018/01/14/openresty_rate_limiter_methods/在开发 api 网关的时，做过一些简单的限流，比如说静态拦截和动态拦截；静态拦截说白了就是限流某一个接口在一定时间窗口的请求数。用户可以在系统上给他们的接口配置一个每秒最大调用量，如果超过这个限制，则拒绝服务此接口，而动态拦截其实也是基于静态拦截进行改进，我们可以依据当前系统的响应时间来动态调整限流的阈值，如果响应较快则可以把阈值调的大一些，放过更多请求，反之则自动降低限流阈值，只使少量请求通过。其实这就是一个很简单的限流方式。但是因为这些场景在我们开发的时候经常遇到，所以在这里用 OpenResty 大概实现一些常见的限流方式。（此处使用OpenResty1.13.6.1版本自带lua-resty-limit-traffic模块 ，实现起来更为方便）限制接口总并发数场景：按照 ip 限制其并发连接数ua_shared_dict my_limit_conn_sto

RabbitMQ消息可靠性投递解决方案 - 基于SpringBoot实现

谈到消息的可靠性投递，无法避免的，在实际的工作中会经常碰到，比如一些核心业务需要保障消息不丢失，接下来我们看一个可靠性投递的流程图，说明可靠性投递的概念：Step 1： 首先把消息信息(业务数据）存储到数据库中，紧接着，我们再把这个消息记录也存储到一张消息记录表里（或者另外一个同源数据库的消息记录表）Step 2：发送消息到MQ Broker节点（采用confirm方式发送，会有异步的返回结果）Step 3、4：生产者端接受MQ Broker节点返回的Confirm确认消息结果，然后进行更新消息记录表里的消息状态。比如默认Status = 0 当收到消息确认成功后，更新为1即可！Step 5：但是在消息确认这个过程中可能由于网络闪断、MQ Broker端异常等原因导致 回送消息失败或者异常。这个时候就需要发送方（生产者）对消息进行可靠性投递了，保障消息不丢失，100%的投递成功！（有一种极限情况是闪断，Broker返回的成功确认消息，但是生产端由于网络闪断没收到，这个时候重新投递可能会造成消息重复，需要消费