罗彬桦的博客

分布式限流要注意的问题为什么需要匀速限流我们做这样一个场景假设，在某个限流策略中我们设置了10r/s（每秒十个请求）的限流速率，在令牌桶算法的实现中，令牌生成器每秒会产生10个新令牌放入令牌桶。Guava的RateLimiter采用了一种“匀速”的策略生成令牌，也就是说，这10个令牌平均分到1秒钟的时间窗口中生成，每0.1秒产生一个令牌。如果在这一秒来了10个请求，这些请求会在一秒钟以内匀速消化掉。假如我们不采用匀速发放，而是采用一把梭的模式发令牌，在每一秒开始的时候把令牌一次性发放，这样会带来什么问

限流组件封装-自定义注解基于AspectJ创建自定义注解AccessLimit配置限流规则的切面为目标方法添加@AccessLimit注解，验证效果AccessLimiterpackage com.imooc.springcloud.annotation;import java.lang.annotation.*;/** * Created by 半仙. */@Target({ElementType.METHOD})@Retention(RetentionPolicy.RUN

限流组件封装-Redis+Lua编写Lua限流脚本spring-data-redis组件集成Lua和RedisDefaultRedisScript加载Lua脚本RedisTemplate配置（调用Redis）在Controller中添加测试方法验证限流效果pom.xml<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xml

Redis预加载Lua在Redis中执行Lua脚本Lua脚本预导入Redis127.0.0.1:6379> eval "return 'hello redis+lua'" 0"hello redis+lua"127.0.0.1:6379> eval "return {KEYS[1], ARGV[1]}" 2K1 K2 V1 K2(error) ERR value is not an integer or out of range127.0.0.1:6379> eval

Lua介绍和基本用法Lua特点开始之前-插件安装Lua基本安装很不错https://blog.youkuaiyun.com/Chinar优快云/article/details/78667262创建LuaLua基本用法Hello Lua一个简易脚本（Lua入门级语法）---- Created by IntelliJ IDEA.-- User: qiyao-- Date: 10/15/19-- Time: 11:36 PM-- To change this template us

基于Redis+Lua的分布式限流Nginx做网关层限流，利用Redis+Lua实现服务端限流。为什么用Redis性能 Redis作为缓存组件，如果不采用持久化方案的话，Redis的大部分操作都是纯内存操作，性能十分优异线程安全 只用单线程承接网络请求（其他模块仍然多线程），天然具有线程安全的特性，而且对原子性操作的支持非常到位限流服务不仅需要承接超高QPS，还需要保证限流逻辑的执行层面具备线程安全的特性。利用Redis的这些天然特性做限流，既能保证线程安全，也能保持良好的性能。基于Redi

基于Nginx的IP限流添加Controller方法网关层配置（修改Host文件和nginx.conf文件）配置Nginx限流规则package com.imooc.springcloud;import com.google.common.util.concurrent.RateLimiter;import lombok.extern.slf4j.Slf4j;import org.springframework.web.bind.annotation.GetMapping;import

Guava RateLimiter预热模型什么是流量预热我们都知道在做运动之前先得来几组拉伸之类的动作，给身体做个热身，让我们的身体平滑过渡到后面的剧烈运动中。流量预热也是一样的道理，对限流组件来说，流量预热就类似于一种热身运动，它可以动态调整令牌发放速度，让流量变化更加平滑。我们来举一个例子：某个接口设定了100个Request每秒的限流标准，同时使用令牌桶算法做限流。假如当前时间窗口内都没有Request过来，那么令牌桶中会装满100个令牌。如果在下一秒突然涌入100个请求，这些请求会迅速消耗令牌

Guava RateLimiter客户端限流创建rate-limit子项目，引入依赖项非阻塞式的限流方案同步阻塞式的限流方案pom.xml<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:sch

限流方案常用算法讲解正所谓天下武学殊途同归，不管是Nginx限流还是Redis限流，也不管招式耍的再花哨，到了最后都是应用几种特定的限流算法。常见的限流算法一只手都可以数的过来，今天我们挑选令牌桶算法、漏桶算法、滑动窗口和计数器算法来讲一下。令牌桶算法Token Bucket令牌桶算法是目前应用最为广泛的限流算法，顾名思义，它有以下两个关键角色：令牌 获取到令牌的Request才会被处理，其他Requests要么排队要么被直接丢弃桶 用来装令牌的地方，所有Request都从这个桶里面获取令牌

常见的分布式限流方案Guava乱入Google出品的客户端限流工具，上手简单。它最早源于2007年的"Google Collections Library"项目。Guava不甘于将自己平凡的一生都耗费在Collections上面，于是乎它开始了转型，慢慢扩展了自己在Java领域的影响力，从反射工具、函数式编程、安全验证、数学运算等等方面，都提供了响应的工具包。在限流这个领域中，Guava也贡献了一份绵薄之力，在其多线程模块下提供了以RateLimiter为首的几个限流支持类。我们前面提到了，Guava

分布式限流介绍其实在生活中，大家都肯定经历过被限流的情况，只是大家浑然不知。春运，一项人类历史上最大的迁移活动，那么抢火车票也成为一个严肃的话题拉，大家每年都要通过某个网站购买火车票，那么这个系统在春运的时候所承受的访问压力是相当的大，毕竟不是所有人都会参加双11，单身大家过年是要回老家的纳。话说降低压力最有效的方式就是减少访问流量，说白点吧就是把用户拒之门外。比如说，我可以给用户一句“服务正忙”的提示，将用户请求丢弃不管。但是这事又不能光明正大的做，毕竟全国人民都知道我这网站花了好几个亿的成本。那怎

常用限流方案介绍分布式限流介绍常见方案技术选型分布式限流常用算法基于客户端的限流方案Guava RateLimiter客户端限流Guava的预热模型基于Nginx的分布式限流基于IP地址的限流方案基于最大连接数的限流方案基于Redis + Lua的分布式限流Lua脚本而Lua的解释器又是预编译性质的，明显比其他的脚本语言快许多（是javascript、perl等几倍到十倍吧），所以脚本语言性能上的劣势lua相对较小。而且lua很适合作为“胶水语言”，用于连

混合操作的幂等性就是有插入或者修改等的混合操作混合操作，一个接口包含多种操作同样可以使用Token机制

Insert操作的幂等性有唯一业务号的Insert操作，例如：秒杀，商品ID+用户ID可通过分布式锁，保证接口幂等业务执行完成后，不进行锁释放，让其过期自动释放没有唯一业务号的Insert操作，比如：用户注册，点击多次使用Token机制，保证幂等性进入到注册页，后台统一生成Token，返回到前台隐藏域中用户在页面点击提交时，将Token一同传入后台使用Token获取分布式锁，完成Insert操作执行成功后，不释放锁，等待过期自动释放...

Update操作的幂等性根据唯一业务员去更新数据的情况用户查询出要修改的数据，系统将数据返回页面，将数据版本号放入隐藏域用户修改数据，点击提交，将版本号一同提交给后台后台使用本本号作为更新条件update set version = version + 1,xxx = ${xxx} where id = xxx and version = ${version}更新操作没有唯一业务号，可使用Token机制本身的update是不受影响的，就是幂等的，那如果表中有个字段为更新次数的话，那就不一

Delete操作的幂等性根据唯一业务号去删除第一次删除时，已将数据删除第二次再次执行时，由于找不到记录，所以返回的结果是0，对业务数据没有影响。可在删除前进行数据的查询。删除操作没有唯一业务号，则要看具体的业务需求例如：删除所有审核未通过的商品。第一次执行，将所有未通过审核的商品删除在第二次执行前，又有新的商品未审核通过。执行第二次删除操作，新的未审核通过的商品要不要删除？根据业务需求而定根据唯一的业务单号进行删除...

概述与接口重试的问题什么是幂等性幂等性涉及的核心思想select、update、delete、insert和混合操作的接口幂等性接口设计与重试机制引发的问题接口幂等性提交订单按钮如何防止重复提交？表单录入页如何防止重复提交？微服务接口，客户端重试时，会对业务数据产生影响吗？幂等性：f(f(x)) = f(x)幂等元素运行多次，还等于它原来的运算结果在系统中，一个接口运行多次，与运行一次的效果是一致的什么情况下需要幂等性重复提交、接口重试、前端操作抖动等业务场景：