用nginx_lua做截流的考虑？

382482175

hello

我们用在access_by_lua阶段做截流，大致架构是：

在init_worker阶段启一个timer，定时去redis把截流的数据拉取到dict，截流的数据的key是servername+location，value是一个1－100的数值。

然后在access_by_lua阶段对每个请求做匹配，如果从dict中有该请求的servername+location的key值，那么就randdom数值和其value进行大小比较决定是否放行，达到百分比截流的效果。

现在的问题：

1 为了使整个过程自动化，简化配置，选择在http块放access_by_lua，这样所有的server块（server块很多，2k＋个）都能接入这个逻辑，但是所有的请求也都会走这个匹配逻辑，这是否是可行的？

2 这个匹配目前做的很粗糙，是根据uri的每个字符来逐一匹配的（为了达到前缀匹配的效果），所以一个请求访问cache的次数和其uri长度一致，效率很低下，用火焰图定位也确实瓶颈在这里。

所以想问下是否有更好的匹配做法也能够达到前缀匹配的效果呢？

3 最后，如果需要到达我说的这种按照servername+uri粒度的百分比截流效果，有啥好的方案可以参考下？

谢谢了。

382482175

在 2017年3月1日星期三 UTC+8上午9:36:48，wwaz wwaz写道：

hello

我们用在access_by_lua阶段做截流，大致架构是：

在init_worker阶段启一个timer，定时去redis把截流的数据拉取到dict，截流的数据的key是servername+location，value是一个1－100的数值。

然后在access_by_lua阶段对每个请求做匹配，如果从dict中有该请求的servername+location的key值，那么就randdom数值和其value进行大小比较决定是否放行，达到百分比截流的效果。

现在的问题：

1 为了使整个过程自动化，简化配置，选择在http块放access_by_lua，这样所有的server块（server块很多，2k＋个）都能接入这个逻辑，但是所有的请求也都会走这个匹配逻辑，这是否是可行的？

2 这个匹配目前做的很粗糙，是根据uri的每个字符来逐一匹配的（为了达到前缀匹配的效果），所以一个请求访问cache的次数和其uri长度一致，效率很低下，用火焰图定位也确实瓶颈在这里。
所以想问下是否有更好的匹配做法也能够达到前缀匹配的效果呢？

3 最后，如果需要到达我说的这种按照servername+uri粒度的百分比截流效果，有啥好的方案可以参考下？

谢谢了。

Attachment: flame.svg
Description: image/svg

382482175

上下匹配逻辑的代码：

local degrade_get_percent=function(cache,servername,location)

local prefix=""

local deg_key=""

local percent,err

for i=1,#location do

if location:sub(i,i)=='/' then

prefix=location:sub(1,i)

if #prefix>1 then --escape the last '/',of coure except for single '/'

prefix=prefix:sub(1,#prefix-1)

end

deg_key=table.concat({degrade_policy_prefix,servername,prefix},degrade_concat_symbol)

percent,err=cache:get(deg_key)

if percent then

return percent

--elseif err then

-- ngx.log(ngx.ERR,"cache get:",err)

end

deg_key=table.concat({degrade_policy_prefix,servername,location},degrade_concat_symbol)

percent,err=cache:get(deg_key)

if percent then

return percent

elseif err then

ngx.log(ngx.ERR,"cache get:",err)

return nil,err

end

return nil --Not set percent for this request

end

在 2017年3月1日星期三 UTC+8上午9:36:48，wwaz wwaz写道：

hello

我们用在access_by_lua阶段做截流，大致架构是：

在init_worker阶段启一个timer，定时去redis把截流的数据拉取到dict，截流的数据的key是servername+location，value是一个1－100的数值。

然后在access_by_lua阶段对每个请求做匹配，如果从dict中有该请求的servername+location的key值，那么就randdom数值和其value进行大小比较决定是否放行，达到百分比截流的效果。

现在的问题：

1 为了使整个过程自动化，简化配置，选择在http块放access_by_lua，这样所有的server块（server块很多，2k＋个）都能接入这个逻辑，但是所有的请求也都会走这个匹配逻辑，这是否是可行的？

2 这个匹配目前做的很粗糙，是根据uri的每个字符来逐一匹配的（为了达到前缀匹配的效果），所以一个请求访问cache的次数和其uri长度一致，效率很低下，用火焰图定位也确实瓶颈在这里。
所以想问下是否有更好的匹配做法也能够达到前缀匹配的效果呢？

3 最后，如果需要到达我说的这种按照servername+uri粒度的百分比截流效果，有啥好的方案可以参考下？

谢谢了。

doujiang24

Hello

其实这个是程序设计问题，提点个人的小建议：

1. 使用这种结构存储数据 server => { prefix1 => percent, prefix => precent }

2. 使用两级 cache，lrucache + shdict，这样可以减少 shdict 读取操作

3. prefix 不用逐个字节比较，可以类似这样：string.sub(uri, 1, #prefix) == prefix

说明：

1. 每请求常数个数的 shdict 操作，这个不用怎么担心

但是当你放入循环中时候，你就应该尽量避免了

2. 字符串截取，拼接，一般也不需要注意

当你放入大循环体的时候，也应该多注意了

在 2017年3月1日上午9:40，wwaz wwaz <3824...@qq.com>写道：

上下匹配逻辑的代码：

local degrade_get_percent=function(cache,servername,location)

local prefix=""

local deg_key=""

local percent,err

for i=1,#location do

if location:sub(i,i)=='/' then

prefix=location:sub(1,i)

if #prefix>1 then --escape the last '/',of coure except for single '/'

prefix=prefix:sub(1,#prefix-1)

end

deg_key=table.concat({degrade_policy_prefix,servername,prefix},degrade_concat_symbol)

percent,err=cache:get(deg_key)

if percent then

return percent

--elseif err then

-- ngx.log(ngx.ERR,"cache get:",err)

end

end

end

deg_key=table.concat({degrade_policy_prefix,servername,location},degrade_concat_symbol)

percent,err=cache:get(deg_key)

if percent then

return percent

elseif err then

ngx.log(ngx.ERR,"cache get:",err)

return nil,err

end

return nil --Not set percent for this request

end

在 2017年3月1日星期三 UTC+8上午9:36:48，wwaz wwaz写道：
hello

我们用在access_by_lua阶段做截流，大致架构是：

在init_worker阶段启一个timer，定时去redis把截流的数据拉取到dict，截流的数据的key是servername+location，value是一个1－100的数值。

然后在access_by_lua阶段对每个请求做匹配，如果从dict中有该请求的servername+location的key值，那么就randdom数值和其value进行大小比较决定是否放行，达到百分比截流的效果。

现在的问题：

1 为了使整个过程自动化，简化配置，选择在http块放access_by_lua，这样所有的server块（server块很多，2k＋个）都能接入这个逻辑，但是所有的请求也都会走这个匹配逻辑，这是否是可行的？

2 这个匹配目前做的很粗糙，是根据uri的每个字符来逐一匹配的（为了达到前缀匹配的效果），所以一个请求访问cache的次数和其uri长度一致，效率很低下，用火焰图定位也确实瓶颈在这里。
所以想问下是否有更好的匹配做法也能够达到前缀匹配的效果呢？

3 最后，如果需要到达我说的这种按照servername+uri粒度的百分比截流效果，有啥好的方案可以参考下？

谢谢了。

--

hadalsyang

还可以使用非随机的方式来处理。

因为本身用户请求进来就是随机的，所以可以用计数法，前N个放行，后M个拦截，到达一定数值置零计算。

在 2017年3月1日星期三 UTC+8上午9:36:48，wwaz wwaz写道：

hello

我们用在access_by_lua阶段做截流，大致架构是：

在init_worker阶段启一个timer，定时去redis把截流的数据拉取到dict，截流的数据的key是servername+location，value是一个1－100的数值。

然后在access_by_lua阶段对每个请求做匹配，如果从dict中有该请求的servername+location的key值，那么就randdom数值和其value进行大小比较决定是否放行，达到百分比截流的效果。

现在的问题：

1 为了使整个过程自动化，简化配置，选择在http块放access_by_lua，这样所有的server块（server块很多，2k＋个）都能接入这个逻辑，但是所有的请求也都会走这个匹配逻辑，这是否是可行的？

2 这个匹配目前做的很粗糙，是根据uri的每个字符来逐一匹配的（为了达到前缀匹配的效果），所以一个请求访问cache的次数和其uri长度一致，效率很低下，用火焰图定位也确实瓶颈在这里。
所以想问下是否有更好的匹配做法也能够达到前缀匹配的效果呢？

3 最后，如果需要到达我说的这种按照servername+uri粒度的百分比截流效果，有啥好的方案可以参考下？

谢谢了。

382482175

在 2017年3月1日星期三 UTC+8下午3:38:06，Hadals Yang写道：

还可以使用非随机的方式来处理。

因为本身用户请求进来就是随机的，所以可以用计数法，前N个放行，后M个拦截，到达一定数值置零计算。

现在的问题瓶颈在于匹配逻辑，。。希望只进行一次匹配一次访问内存操作即可出结果

在 2017年3月1日星期三 UTC+8上午9:36:48，wwaz wwaz写道：
hello

我们用在access_by_lua阶段做截流，大致架构是：

在init_worker阶段启一个timer，定时去redis把截流的数据拉取到dict，截流的数据的key是servername+location，value是一个1－100的数值。

然后在access_by_lua阶段对每个请求做匹配，如果从dict中有该请求的servername+location的key值，那么就randdom数值和其value进行大小比较决定是否放行，达到百分比截流的效果。

现在的问题：

1 为了使整个过程自动化，简化配置，选择在http块放access_by_lua，这样所有的server块（server块很多，2k＋个）都能接入这个逻辑，但是所有的请求也都会走这个匹配逻辑，这是否是可行的？

2 这个匹配目前做的很粗糙，是根据uri的每个字符来逐一匹配的（为了达到前缀匹配的效果），所以一个请求访问cache的次数和其uri长度一致，效率很低下，用火焰图定位也确实瓶颈在这里。
所以想问下是否有更好的匹配做法也能够达到前缀匹配的效果呢？

3 最后，如果需要到达我说的这种按照servername+uri粒度的百分比截流效果，有啥好的方案可以参考下？

谢谢了。

leomicv

Trie树

在 2017年3月1日星期三 UTC+8上午9:36:48，keke fan写道：

hello

我们用在access_by_lua阶段做截流，大致架构是：

在init_worker阶段启一个timer，定时去redis把截流的数据拉取到dict，截流的数据的key是servername+location，value是一个1－100的数值。

然后在access_by_lua阶段对每个请求做匹配，如果从dict中有该请求的servername+location的key值，那么就randdom数值和其value进行大小比较决定是否放行，达到百分比截流的效果。

现在的问题：

1 为了使整个过程自动化，简化配置，选择在http块放access_by_lua，这样所有的server块（server块很多，2k＋个）都能接入这个逻辑，但是所有的请求也都会走这个匹配逻辑，这是否是可行的？

2 这个匹配目前做的很粗糙，是根据uri的每个字符来逐一匹配的（为了达到前缀匹配的效果），所以一个请求访问cache的次数和其uri长度一致，效率很低下，用火焰图定位也确实瓶颈在这里。
所以想问下是否有更好的匹配做法也能够达到前缀匹配的效果呢？

3 最后，如果需要到达我说的这种按照servername+uri粒度的百分比截流效果，有啥好的方案可以参考下？

谢谢了。