Update README.md

Author: klboke

README.md

@@ -4,9 +4,9 @@
 两种限流算法。使得项目拥有分布式限流能力变得很简单。限流的场景有很多，常说的限流一般指网关限流，控制好洪峰流量，以免打垮后方应用。这里突出`偏业务应用的分布式限流`
 的原因，是因为区别于网关限流，业务侧限流可以轻松根据业务性质做到细粒度的流量控制。比如如下场景，
 
-- 案例一：时间窗口限流 有一个公开的 openApi 接口， openApi 会给接入方派发一个 appId，此时，如果需要根据各个接入方的 appId 限流，网关限流就不好做了，只能在业务侧实现
+- 案例一：有一个公开的 openApi 接口， openApi 会给接入方派发一个 appId，此时，如果需要根据各个接入方的 appId 限流，网关限流就不好做了，只能在业务侧实现
 
-- 案例二：令牌桶限流 公司内部的短信接口，内部对接了多个第三方的短信通道，每个短信通道对流量的控制都不尽相同，假设有的第三方根据手机号和短信模板组合限流，网关限流就更不好做了
+- 案例二：公司内部的短信接口，内部对接了多个第三方的短信通道，每个短信通道对流量的控制都不尽相同，假设有的第三方根据手机号和短信模板组合限流，网关限流就更不好做了
 
 以上举例的场景，通过 ratelimiter-spring-boot-starter 可以轻松解决限流问题
 
@@ -352,4 +352,4 @@ Transfer/sec:      2.87MB
 
 - 1、配置策略变化，不在从应用的上下文中获取 Redis 数据源，而是必须配置。但是配置的数据源在 Spring 上下文中声明了 `rateLimiterRedissonBeanName`，应用也可以获取使用
 - 2、代码重构，新增了`令牌桶`的限流策略支持
-- 3、抽象了限流器服务 `RateLimiterService`，并在 Spring 上下文中声明了，应用可以直接注入使用
+- 3、抽象了限流器服务 `RateLimiterService`，并在 Spring 上下文中声明了，应用可以直接注入使用