基于nginx的频率控制方案思考
标签： 频率控制 nginx
背景
nginx其实有自带的limit_req和limit_conn模块，不过它们需要在配置文件中进行配置才能发挥作用，每次有频控策略的增删都需要直接改动配置文件，再让nginx重新加载配置文件。由于以配置文件的形式来管理导致整个流程不够灵活，因此它的实用性其实并不强，而且这也不适合大量的差异化的配置策略，不然配置文件更难维护了。基于此，下面展开了基于nginx的频率控制方案思考。本文不是最终的系统设计文档，很多地方都显得比较啰嗦和发散。
正文
上面简单谈了使用nginx自带的限流模块的局限性，下面谈谈我想要达到的目标。
目标
1 配置方面
支持组合频率控制，如对具体的ip地址,userid,参数值的组合项进行频率控制。在这里我打算只对固定元素进行频率控制，如对ip 1.2.3.4进行频率控制，或者对ip 为1.2.3.4且userid为u1024的请求进行频率控制，在这里不考虑以集合作为参数，如以ip为key做频率控制(1是因为这会涉及到元素的淘汰,2是因为在实际业务需求中往往都是对指定调用来源做频控)
2 控制方面
可即时更改，即时生效，控制灵活,毕竟nginx自带的频率控制模块在使用上最大的缺陷就是不够灵活，导致实用性不强。
整体设计
针对上面的两点目标，再简单看一下整体设计
1开发人员在配置页面上配置相关限制策略，通过配置cgi将其写入DB
2 agent服务定期从DB中拉取全量最新的配置内容，根据各机器权重，计算出本机的频率控制速率，处理后存储于共享内存中
3 接入层编写nginx模块，在Pre_Access阶段定期更新配置内容，同时获取请求信息，根据配置内容和请求信息进行频率控制
整体结构如下
结构非常简单，其中同步agent直连db取配置这里在nginx接入层机器较少时是可以接受的。不过如果是为了长远考虑，可以在DB到nginx接入层之间加一层频率配置服务，由频率配置服务定期扫描db处理配置信息，同时每次配置cgi写db时也可通知频率配置服务有更新，而agent则直接请求频率配置服务即可。另外也只有在加上了频率配置服务才能更好的做到即时生效，因为agent可以以更短的时间间隔向频率控制服务轮询，是否有配置变更。
详细设计
1 配置模块设计
配置系统较为简单，可采用配置页面+配置cgi+mysql的模式，主要作用为将用户的配置项落地db，此处直接略过。
2 限流算法选取
采用漏桶算法或者令牌桶算法，两种算法各有优劣
漏桶算法模型
此处引用一下网上的图
算法逻辑
1 根据配置的速率，按固定速率处理请求
2 当有请求到达时，计算桶内当前水量
3 若当前水量超过桶容量，请求被限制，直接返回错误(503)
4 若当前水量小于桶容量，请求根据当前水量进行休眠，休眠结束后处理请求
算法特性
流量稳定，均匀
令牌桶算法模型
此处引用一下网上的图
算法逻辑
1 根据配置的速率，按固定速度往桶中添加令牌，若桶内令牌数已满，则放弃
2 请求到达时从桶中获取一个令牌，获取失败则返回错误(503)
3 获取成功则放行请求
算法特性
允许并发，其中最高并发数为令牌桶容量
Nginx限流模块参考
Nginx的limit_req模块采取的限流算法是漏桶算法，但是做了一些改进，允许一定程度的并发(允许的并发大小由用户配置，当未配置并发时，则采用的就是原生的漏桶算法了)。
3 共享内存设计
1 全局设计
共享内存一共分为2块，分别是配置块，统计块，分别存储配置信息和请求统计信息。其中配置块又均分为A/B配置块用于实现RCU
配置块的表头结构如下(单位为byte)
| flag | segment | padding | seq | bitset |
|---|---|---|---|---|
| 4 | 1 | 3 | 4 | 128 |
1 flag
初始化flag，标识该块内存是否被初始化
2 segment
当nginx worker需要更新配置内容时进行读取，指向当前应该读哪片内存
3 padding
填充字节以及作为保留字节，用于保证seq 4字节对齐
4 seq
为总的配置操作流水，所有的nginx worker每次处理请求时都会读取该值，判断跟本地保存的配置内容的seq是否相等，如果相等的话，则是最新配置，无需更新，如果不相等，则触发配置更新逻辑
5 bitset
128字节，共1024bit，每个bit表示对应偏移的统计slot(用于统计请求信息，下文会提到)是否已被使用，因此当前系统的设计最多可配置1024条策略(此处采用bit并不是为了节省内存占用，而是为了加速寻找到未被使用的统计slot,以8字节进行操作时，每次可判断64个bit的状态)
2 A/B内存块设计
由agent负责创建和管理,分为 A/B两块区域，通过RCU来避免agent与nginx worker的读写冲突。对于每条配置策略，agent都将分配一个统计slot用于统计请求信息。每块区域的结构如下
| magic | size | item |
|---|---|---|
| 2 | 2 | ... |
1 magic
固定值，检测内存是否出现异常
2 size
表示后面有多少条策略item
3 item
策略item的内容
3策略item
即用户配置的具体限流策略
3 策略item
即用户配置的具体限流策略
| magic | version | length | padding | s_id | seq | offset | rate | size | key | value | ... |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 2 | 2 | 2 | 4 | 2 | 2 | 4 | 2 | ... | ... | ... |
1 magic
固定值，用于检测当前的策略item是否出现异常，当读到错误值时，说明后续内容可能已经错乱，将跳出策略的加载逻辑，并进行错误上报
2 version
版本号,为后续功能扩展考虑
3 length
length为该条策略的总长度
4 padding
padding为填充和保留字段
5 s_id
策略id
6 seq
seq为该条策略的操作流水号，对配置更新时，大部分配置内容都是无需更新的，通过判断seq是否相等完成配置内容的增量更新
7 offset
用于定位对应的统计slot,初始化时将配置内容按s_id从小到大写入内存中，offset从0开始自增，策略更新时，不会影响offset值。(该字段的值与上面的bitset有关联)
8 rate
配置速率
9 size
维度数量，即有几对key/value组合
10 key
Key表示限流维度，如为ip，userid或者业务参数等等，其存储结构为length+value的组合，表示具体的限流纬度
11 value
同key的设计，表示具体的值
4 统计表
根据配置内存块的策略item的offset值以及统计共享内存的初始地址，可以确定每条策略对应的统计slot
统计slot设计
| magic | lock | padding | current burst | timestamp |
|---|---|---|---|---|
| 2 | 1 | 1 | 4 | 8 |
1 magic
固定值，用于检测当前的slot是否出现异常，当出现异常时，将初始化该块slot
2 lock
用于自旋锁上锁使用
3 padding
保留及填充区域，用于保证字节对齐
4 current burst
上一次被处理后桶中遗留的水量,或者桶内当前的令牌数
5 timestamp
统计周期时间戳
字节对齐，共16byte
5 初始化及更新
初始化
共享内存的初始化工作由agent来做。
这里再回顾一下配置块表头的结构
| flag | segment | padding | seq | bitset |
|---|---|---|---|---|
| 4 | 1 | 3 | 4 | 128 |
初始化流程如下:
agent:
1 获取或者创建共享内存
2 如果是获取成功，则判断头4个字节是否为初始化完成flag，如果是的话则直接跳过初始化流程，否则进入4
3 如果是新创建的共享内存，则清0头4个字节
4 根据从db中读取到的数据初始化共享内存
5 将共享内存的头4个字节赋值为初始化完成flag
nginx worker:
1 获取共享内存地址失败，则直接放行请求
2 判断头4个字节是否为初始化完成flag，不是的话直接放行请求
2 将配置load进进程内存
6 配置策略存储
在各进程初始化完毕之后，开始加载共享内存中的配置策略，策略的加载按顺序读取共享内存中的信息即可，配置信息的存储结构如下
typedef strcut {
uint32_t s_id;
uint16_t seq;
uint16_t offset;
uint32_t rate;
uint32_t burst;
uint8_t *slot;
map<string,string> limits;
} LimitConf;
7 配置策略查找
当请求进来时，依次遍历所有限制策略,对匹配的策略执行限流算法相关的逻辑,直至请求被限制，或请求通过所有策略为止，流程如下
1 遍历限流策略
2 策略是否匹配，不匹配则返回1，匹配则进入3
3 记录下该条命中策略的offset，在统计更新逻辑中将被使用到
4 遍历结束
5 对命中策略的统计slot信息进行更新
假设我们有N条策略，每条策略平均有M个限制维度,那么遍历算法下的时间复杂度为O(MN),当策略变得很多时，策略的查找将会成为性能消耗的大头，如何解决呢？策略数量小的时候，无需解决。当数量较多时，可以有如下的方法:
1 可以以某些参数为索引，比如，在我的需求中，频率控制的粒度可以细化到接口，那可以以接口名作为索引，从而减少无效的匹配
2 每次请求进来时，我们都进行一次策略的遍历，很明显这是在做重复的事情，我们是否可以把每个请求中属于限流维度的信息提取出来，组成一个key，做一个缓存？
2这一点在当前的设计下可行性不强，因为我们的限流纬度包括ip，userid这种扩散性太强的维度。既然如此，我们可以把ip，userid这类参数单独提取出来,将除去ip，userid后的维度信息提取出来，组成一个key做一下缓存，再去单独匹配各个策略的ip和userid。不过考虑到系统的后续运维，一旦ip，userid多起来，还是会对性能产生较大的影响，转而一想，对于ip，userid一类的参数我们经常需要的是黑名单的功能，我们可以将ip与userid拿出来，设计一个黑名单模块，这样就消除了这种威胁。这里到底该如何处理还是需要针对实际情况来进行取舍，直接拉黑应该是不能满足所有的情况的。接下来我分别讨论下黑名单的设计和对于处理ip，userid之类参数的一点思考。
黑名单模块的设计在下面会单独提出来。现在先分析一下为什么有ip，userid类型参数后匹配会慢，主要原因是由于这类参数的取值扩散性太强，无法组成缓存用的key，导致只能先取到满足其它维度信息策略集合(设为集合A)后的一个一个策略去遍历。但是反过来想，如果我们有了某ip下能命中的策略集合(设为集合B)，那只要取A,B的交集就能得到最终命中的策略了，从而避免了一个一个策略去做字符串匹配(当然ip和userid也可以转换为int加速匹配)。
集合匹配
我们在初始化配置策略时，同时初始化策略里面每个ip和userid(如果有对ip或userid做限制的话)命中的策略集合，集合的存储结构如下
typedef struct{
int max_offset;
uint64_t elts[20];//最多存放1280条策略
} StrategyColl;
elts存储该集合拥有的元素，由于每条策略都有自己的offset值(该值由0开始递增)，因此elts对应的第offset个bit为1即表示对应的策略在此集合中
max_offset表示该集合中的所有策略中的最大的offset值
集合求交集的伪代码如下:
i = 0;
offset = (max(A.max_offset,B.max_offset)>>6)+1
while(i < offset){
C.elts[i] = A.elts[i]&B.elts[i];
i++;
}
C.max_offset = max_bit(C.elts,i);
得到的集合C即匹配的策略集合。
8多进程统计
由于nginx是多进程模型，而对于同一个限制策略我们都是在同一块共享内存上进行操作(读/写)，这样会带来一个问题：如何解决读写冲突。
冲突的内存有如下位置:
1 配置策略
配置策略的冲突来源为多个nginx worker进程的读与agent的写。由于是单写多读的模式，采用RCU的模式可以完美解决该问题，将内存分为A/B两块区域，由变量X(1 byte)的值来决定使用哪块内存，如X=1使用A区域，X =2使用B区域。
2 统计slot
对于slot的统计由于我们需要同时更新水量(4字节)和时间戳(8字节)，并且一个请求可能同时命中多条策略，因此需要使用锁来保证互斥。
统计逻辑
在这里我们以漏桶算法(令牌痛算法也类似)为例。
1 获取当前时间戳(cur_time)
2 使用自旋锁上锁
3 遍历命中的策略
4 对每一个策略，根据上一次请求被处理的时间戳(last_time)，以及配置的速率rate，和上一次遗留的水量(pre_burst)，计算当前的水量(cur_burst)，根据当前水量和桶的最大容量MAX_BURST决定是否需要限流,伪代码如下
cur_burst =pre_burst - (cur_time - last_time) * rate + 1;
cur_burst = cur_burst > 0 ? cur_burst : 0;
5 如果需要限流，释放锁,直接返回错误
6 不需要限流，则继续遍历
7 遍历结束后，对所有的命中策略进行更新，同时记录需要休眠的最大时间
8 释放锁
9 根据需要休眠的最大时间开始休眠，休眠结束后放行请求。
选取自旋锁的原因
自旋锁实现原理伪代码如下
while(!cas(p,0,1))
cpu_pause();
其中cas为原子操作，如果p指向的地址中的值为0，则将其设置为1。返回true或者false，cpu_pause()并不是要让该进程放弃cpu，进入阻塞或者就绪状态，而是让CPU以一种节能的方式空转。可通过下面的pause指令实现
__asm__ ("pause" )
实际上使用时我们对于cpu_pause()的使用还会进行优化，用于减少激烈的cas操作,另外为了避免有进程上锁后core了，导致其它进程死循环，我们会对循环次数加上限制，最后的伪代码如下
cnt = 1;
while(!cas(p,0,1) && cnt <= MAX_LOOP){
for(i = 1; i <= cnt;i++ )
cpu_pause();
cnt=cnt<<1;
}
解锁只需要
cas(p,1,0);
由于我们上锁后的逻辑都属于计算型，且计算量较小，此处使用自旋锁的效率是很高的
风险
这里存在死锁的风险，一旦有进程上锁后，还没来得及释放，nginx重启了，那就没法再上锁了。由于共享内存的初始化是由agent做的，但是agent很难感知nginx是否重启(当然也是可以做到的，但是由agent去感知nginx重启以及找到死锁也是非常繁琐的一件事)，因此需要有一种死锁识别和恢复策略，一种简单的策略是这样的:
1 在A/B块共享内存的信息头里扩展一个2字节的fail_cnt变量,每次有进程成功获取到slot锁都将对fail_cnt清0。
2 每次有进程在对该内存上锁失败后对fail_cnt进行value = fetch_and_add(p,1)的原子操作， 通过判断value的值，比如当value >= MAX_FAIL_CNT之后(另外我们可以在value>=MAX_FAIL_CNT时将value值进行上报，以此来监控是否有死锁出现)，就认为此时出现了死锁,从而实现了死锁的识别。
识别之后，自然还需要对死锁进行恢复，恢复逻辑中可以采用文件锁，获取到文件锁的认为成功获取到了slot锁，进而清零fial_cnt变量，一切如初。
采用文件锁的原因:如果继续对一个新的变量使用自旋锁，那么由于自旋锁还是存在可能造成死锁的风险,导致这成为了一个死结。而文件锁在进程重启或者core时会自动释放掉。
当然，其实还有一种更优的方案，我们可以通过原子操作对fail_cnt进行清0，伪代码如下
update = true;
do{
fail_cnt = *pt_fail_cnt;
if(fail_cnt < MAX_FAIL_CNT){
update = false;
break;
}
}while( !cas(pt_fail_cnt,fail_cnt,0) );
通过判断update值可知道是否是本进程清0成功，清0成功的认为获取到了锁。
如何无锁
在上述的频率控制方案中我们不得不使用自旋锁来实现互斥，原因有2点:
1 上述方案中一个请求可能命中多条策略，为了实现统计的精准度我们对共享内存进行了加锁
2 上述方案下多个进程都需要对burst(4byte) 和 timestamp(8byte)进行读和写，没法做到一次内存访问，但这两片内存的数据是有逻辑关联的，一荣俱荣，一损俱损，因此对它们的更新也需要做到原子性。
因此如果想做到无锁，需要针对以上两点做出如下两点对策
1 牺牲掉命中多条策略情况时的统计精准度
2 将上面对burst和timestamp的两次读/写操作合并为一次原子读/写操作
在实际的频率控制需求上，可以允许少量的误差，因此牺牲掉一定的精准度以换取更高的性能，在这里是可以接受的。
先设想这样一种情况，对于任何一个请求它都只会命中一条限制策略。在这种情形下，命中策略的查找能做到O(1)，同时能轻松的实现无锁。
方案如下：
新的统计slot的结构如下
| magic | padding | timestamp | count |
|---|---|---|---|
| 2 | 6 | 4 | 4 |
共16个字节，这里不再采用漏桶算法，而是采用分时统计算法，当然相应的配置策略结构那边也需要调整，比如不再需要burst变量来存储桶容量了,另外还需要扩展一个字段unit，表示统计时间粒度，在这里我们以秒来讨论。
1 count
统计变量
2 padding
填充字节，用于保证count,timestamp整体8字节对齐，timestamp 4字节对齐
3 timestamp
保存最新的时间周期，秒级。
更新逻辑
所有的更新操作都需要判断当前的时间戳(以下简称进程时间戳)与共享内存中的时间戳(以下简称共享时间戳)
当共享时间戳>=进程时间戳时，共享时间戳不需要更新
当共享时间戳< 进程时间戳时，count以及timestamp都需要更新。
更新时，count清0，同时更新时间戳，由于低32位就足够存储秒为单位的时间戳，以及机器字节序为小端模式，因此cas原子操作8字节(以uint64_t类型表示)直接赋值时间戳即可
伪代码如下
uint64_t cur_time = time(NULL);
uint64_t *pt_mix = p+offsetof(struct,timestamp);
uint64_t shm_mix;
uint32_t shm_time;
do{
shm_mix = *pt_mix;
shm_time = shm_mix & 0xFFFFFFFF;
if(shm_time >= cur_time)
break;
}while(!cas(pt_mix ,shm_mix,cur_time )//更新失败，则继续循环
以此保证最新的时间开始时，统计量也将被清0。
以一个实例来说明该方案的运转。
当请求到来时，我们获取当前的时间戳(秒为单位)，对共享时间戳执行判断和更新逻辑。
更新时统一采用原子操作,伪代码如下
origi_value = fetch_and_add(pt,1);
通过origi_value可以知道请求是当前时间周期内的第多少个请求，再根据配置的速率决定是否限流。
现在回到之前的一个请求可能命中多条策略的情况。依然采用上述的无锁方案。更新逻辑将变成如下:
1 遍历命中的策略
2 对命中策略执行更新逻辑，用于保证统计新周期开始时，该策略的count会被清0
3 读取当前策略的count来判断是否会超过限流策略，如果会超过则直接返回503
4 遍历结束
5 再次遍历命中策略，对各条命中策略的统计变量count原子加1
误差分析
该方案的误差主要有如下2点:
1 由于一个请求可能命中多条策略，因此方案一中对统计变量count的限流逻辑判断和自增分离开了，即有可能连续的两个请求，上个请求通过后，还没来得及自增统计变量，或者只自增完部分统计变量，进程被切走，这时候落在另一个worker进程的下一个请求到达时，使用的还是上次的统计变量。
2 来自时间周期交界处的误差。设想一种极端情况，一个请求在某一秒的999ms时开始进行限流处理，当它更新完时间戳之后，进程被切走了，再切回来时shm_time已经变成了下一秒(这说明count变量也被清0过一次了)，这会使本应属于上一周期的请求被统计到当前周期了，同理，当统计周期连续时，本周期的请求也可能被统计到下一周期。不过这个误差是可以定量分析的，其最大误差即系统的nginx work进程数-1。
隐患
隐患来自于分时统计算法本身的不稳定性，在漏桶算法下，流量将均匀的下传，这就像水坝一样，先对流量进行围堵，再通过闸门进行泄洪。而分时统计算法下，流量是可能在一个极小的时间片段中集中下传，容易对下层服务造成冲击(特别是一些涉及到访问db的服务)。
黑名单
讲到这里，内容其实已经快结束了，不过上面有提过将ip，userid一类扩散性极强的参数提取出来实现一个黑名单那模块，让我们来看看如何高效实现这一点。
黑名单内容只存放在共享内存，采用多阶hash(其中最后一阶采用线性探测来处理冲突，用于兜底)存储userid的hash值，ip地址由于本身可转化为一个uint32_t值，为避免误杀，因此不进行hash，直接使用。
表头结构如下
| magic | step_num | max_slot | current_num | seq |
|---|---|---|---|---|
| 2 | 2 | 4 | 4 | 4 |
1 magic
固定值，检测异常
2 max_slot
多阶hash的最大阶的slot数
3 step_num
多阶hash的阶数
4 current_num
当前的黑名单数量
5 seq
当前的公共seq值，每个slot也会有一个seq值，slot的seq值大于等于公共seq值才是有效的slot
黑名单slot设计
| hash_value | seq |
|---|---|
| 4 | 4 |
1 hash_value
Hash值
2 seq
当前slot的seq，当slot的seq大于等于公共seq时，才是有效的
黑名单更新
黑名单更新操作由agent来做，更新时将从db中将全量黑名单数据取出来，先将hash值全部计算出来，找到对应的slot将其seq值置为公共seq值+1，当slot冲突时，判断冲突slot的seq值是否大于头部的seq值，若小于等于的话直接替换，否则在下一阶继续寻找。若最后一阶依然冲突，则开始进行线性探测，若最后无slot可用，则上报错误。更新完毕后，公共seq值+1。此种更新方案下，可保证多阶hash不会出现断层，即在多阶hash表中不会有无效的策略位于有效策略前面(hash值取模后相同时将会产生slot冲突，保证了位于多阶hash前面的阶数的一定是最新的要被使用的策略)。
黑名单查找
黑名单查找工作由nginx worker来做，分别取出用户端ip,guid值计算hash值，经hash后，看slot中的hash值是否一致，再看对应的slot是否有效，当有效时拒绝掉请求。共享内存还未初始化时，将跳过黑名单查找过程，直接放行。
最后
以上为对固定元素进行频率控制时的方案思考。全文较长，对碰到的一些技术问题均进行了分析和解决，部分地方进行了发散，最终频率控制系统该怎么实现还是需要根据实际情况来进行选取，在这里只是将我所想到的一些情况分享出来。
为什么最后的无锁方案中采用了分时统计算法而不是漏桶算法?
主要原因:在这里一旦采用漏桶算法后，性能将变得无法预期。
一般而言漏桶算法的时间精确度至少会为ms，这是因为一般而言我们的配置速率都是以s为单位，漏桶算法采用的时间精确度至少要小它一个数量级才行，否则无法对其进行精确划分，均匀控制流量。因此timestamp必须占用6个字节才行，下面是使用上述无锁方案，同时采用漏桶算法的伪代码。
uint64_t cur_time = time_ms(NULL);
uint64_t *pt_mix = p+offsetof(struct,timestamp);
uint64_t shm_mix;
Uint64_t cur_mix;
uint64_t shm_time;
Uint64_t shm_burst;
uint64_t cur_burst;
do{
shm_mix = *pt_mix;
shm_time = shm_mix & 0xFFFFFFFFFFFF;//低48位
shm_burst = shm_mix >> 48;
cur_burst =shm_burst - (cur_time - shm_time) * rate + 1;
cur_burst = cur_burst > 0 ? cur_burst : 0;
if(cur_burst > MAX_BURST)
fail();//请求结束，该请求被拒绝
cur_mix = cur_time + (cur_burst << 48)
}while(!cas(pt_mix ,shm_mix,cur_mix )//更新失败，则继续循环
由于shm_time很可能会大于cur_time(持续的几次更新失败之后，就可能出现这种情况了)，这时必须再次获取当前时间戳，否则算出来的cur_burst的误差会比较大。所以真正的伪代码如下:
uint64_t cur_time = time_ms(NULL);
uint64_t *pt_mix = p+offsetof(struct,timestamp);
uint64_t shm_mix;
uint64_t cur_mix;
uint64_t shm_time;
uint64_t shm_burst;
uint64_t cur_burst;
do{
shm_mix = *pt_mix;
shm_time = shm_mix & 0xFFFFFFFFFFFF;//低48位
shm_burst = shm_mix >> 48;
if(shm_time > cur_time)
cur_time = time_ms(NULL);
cur_burst =shm_burst - (cur_time - shm_time) * rate + 1;
cur_burst = cur_burst > 0 ? cur_burst : 0;
if(cur_burst > MAX_BURST){
fail();//请求结束，该请求被拒绝
return;//可以返回了
}
cur_mix = cur_time + (cur_burst << 48)
}while(!cas(pt_mix ,shm_mix,cur_mix )//更新失败，则继续循环
不同于分时统计算法当shm_time > cur_time时，它能跳出循环，即当别的进程更新成功时，本进程也能跳出循环，所有进程的目标都是让shm_time保持最新，它在性能方面的最差表现是当所有的nginx进程都进入新的统计周期时间戳后，必定会有进程更新成功，因为此时count变量不会再有变化，而所有worker的时间戳又都是一致的。
在采用漏桶算法时，当别的进程更新成功时，还将影响本进程的更新逻辑(需要重新获取时间戳)，同时这里的cas操作成功的难度也非常高，在实现时自旋锁时，自旋锁的cas只有两种值，非0即1，而这里有无数种值，在性能方面的表现将变得很难预期，因此在无锁方案中放弃了漏桶算法。