Update README.md

Author: yizhenqiang

README.md

@@ -55,13 +55,16 @@ sds-client除了需要统计滑动窗口的数据，还有两个任务，统计
 ### 4.2 并发限流
 并发限流有两种常见的实现方式，一种是通过线程池来隔离，通过线程池的线程数量来限制并发调用，另一种是使用Semaphore来做并发限制。著名的限流熔断工具Hystrix采用的就是这两种方法。这两种方法各有优缺点，线程池的方案开销比较大，如果使用不当反而会增加系统的不稳定性，但可以做到超时提前返回，因为执行是异步的。Semaphore的优点也很明显，开销小，性能高，风险也比线程池的方案小，但无法做到超时返回。SDS2.0采用的是Semaphore的方式。和访问量限流一样，并发限流的阈值也是可以在sds-admin来动态调整的。
 
-### 4.3 异常限流
+### 4.3 令牌桶限流
+SDS也提供令牌桶这种比单纯QPS限流更有“弹性”的限流方式，SDS默认每个自然秒就是一个桶，我们可以设置每秒生成多少个令牌以及每个桶的容量上限，使用方式见：https://github.com/didi/sds/blob/master/sds-client/src/test/java/com/didiglobal/sds/client/test/TokenBucketDowngradeTest.java
+
+### 4.4 异常限流
 有时候我们很难评估一个接口方法的服务能力，特别是在没有历史数据的情况下，这将导致访问量限流和并发限流的阈值很难设置成一个合适的值，所以这时候，我们可以利用该接口方法抛出的异常数量或比例来作为该接口是否已经达服务提供的最大能力的信号，所以就有了异常量限流和异常率限流。异常量限流，顾名思义，将以滑动窗口来统计异常数量，当这个异常数量达到我们设置的阈值，那么就按照我们在sds-admin配置的降级比例来进行限流。注意，这里提到和下面提到的滑动窗口和上面访问量限流的滑动窗口是同一个。有了异常量限流，就会有异常率限流的需求，异常率限流指的是异常率达到一定的比例，比如40%，就开始进行限流，注意，这里的 异常率 = 滑动窗口异常数量 / (滑动窗口访问量 - 滑动窗口降级量)。细心的朋友一定会想到，在流量很小时，比如每秒才几笔请求进来，这时候产生的异常数量将导致异常率的统计有较大变化，比如4笔请求有2笔抛出了异常，那么异常比例就达到了50%！这显然不符合我们预期，所以当我们采用异常率限流方式时，除了异常率阈值需要设置以外，还需要设置一个异常率计算的起始访问量值。
 
-### 4.4 超时限流
+### 4.5 超时限流
 某些服务，当流量上涨后，随着系统负载的增加，平均耗时通常会有所提高，当流量继续上涨，系统负载继续增高，这时候通常就会出现超时等错误。SDS2.0提供了超时限流方案，在滑动窗口内统计耗时超过指定超时时间阈值（单位毫秒）的请求数量，如果该数量超过指定的超时数量阈值，那么将进行限流，当然，超时时间阈值和超时数量阈值在sds-admin端可配。
 
-### 4.5 降级比例
+### 4.6 降级比例
 降级比例是一个[0-100]的整数，代表如果判断为降级，那么真正要降级的比例，例如，配置为50，表示如果策略执行器判定该流量需要降级，那么最终被降级的概率是50%，所以，如果配置成100，那么策略执行器判断为降级后，最终肯定会被降级，相反，如果配置成0，那么永远不会被降级。
 
 降级比例可以用作策略执行的灰度发布方案！