balancer_by_lua模块可否实现负载均衡

dongxingong2014 · 2016-01-15T11:24:02+00:00

Hello! 2016-06-05 23:54 GMT-07:00 Terry Zheng: > 我试了一下，没有安装 OpenSSL 的&#x65F6...

balancer_by_lua模块可否实现负载均衡

dongxingong2014

最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，

如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

yuansheng

根据自己需要，每次设置不同的 ip、port 即可。说白了，使用ip hash还是weight，自己处理。

2016-01-15 11:24 GMT+08:00 <dongxin...@gmail.com>:

最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

--

YuanSheng Wang

---------------------------------------

My Github: https://github.com/membphis

OpenResty lover ^_^

guanglinlv

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：

最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

Thanks

doujiang24

Hello,

在 2016年1月15日下午2:44，Guanglin Lv <guan...@gmail.com>写道：

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：
最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

哈哈，balancer_by_lua 提供了最基础的接口，完全可以做到每请求动态配置

balancer_by_lua 并不是修改当前 upstream 的 server list

而是，在每请求在 balancer 阶段 get_peer 的时候动态指定

这个可定制程度非常高，当然玩法也不一样

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量

目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑

同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

当然，可以有不同的玩法，不同的玩法适用的场景不太一样

Thanks

--

dongxingong2014

嗯，这个动态扩展upstream的方法我去研究下先

在 2016年1月15日下午2:44，Guanglin Lv <guan...@gmail.com>写道：

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：
最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

Thanks

--

dongxingong2014

set_current_peer的时候，如果对应节点不通，直接返回connect() fail了。配置多个peer的时候，如何能在peer fail情况下，再次连接到其他的peer节点。

在 2016年1月15日下午3:29，DeJiang Zhu <douj...@gmail.com>写道：

Hello,

在 2016年1月15日下午2:44，Guanglin Lv <guan...@gmail.com>写道：

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：
最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

哈哈，balancer_by_lua 提供了最基础的接口，完全可以做到每请求动态配置

balancer_by_lua 并不是修改当前 upstream 的 server list
而是，在每请求在 balancer 阶段 get_peer 的时候动态指定
这个可定制程度非常高，当然玩法也不一样

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

当然，可以有不同的玩法，不同的玩法适用的场景不太一样

Thanks

--

--

freelingchang

你看我提的这个问题
https://groups.google.com/forum/#!topic/openresty/0VJk1-_oqPI
春哥回答了

在 2016年1月15日星期五 UTC+8下午3:50:00，L.D写道：

set_current_peer的时候，如果对应节点不通，直接返回connect() fail了。配置多个peer的时候，如何能在peer fail情况下，再次连接到其他的peer节点。

在 2016年1月15日下午3:29，DeJiang Zhu <douji...@gmail.com>写道：
Hello,

在 2016年1月15日下午2:44，Guanglin Lv <guang...@gmail.com>写道：

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：
最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

哈哈，balancer_by_lua 提供了最基础的接口，完全可以做到每请求动态配置

balancer_by_lua 并不是修改当前 upstream 的 server list
而是，在每请求在 balancer 阶段 get_peer 的时候动态指定
这个可定制程度非常高，当然玩法也不一样

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

当然，可以有不同的玩法，不同的玩法适用的场景不太一样

Thanks

--

--

dongxingong2014

意思在balancer中set_more_tries()，然后去通过get_last_failure 来获取上次失败情况，来重新指定peer吗

在 2016年1月15日下午4:44，凭栏 <freeli...@gmail.com>写道：

你看我提的这个问题
https://groups.google.com/forum/#!topic/openresty/0VJk1-_oqPI
春哥回答了

在 2016年1月15日星期五 UTC+8下午3:50:00，L.D写道：
set_current_peer的时候，如果对应节点不通，直接返回connect() fail了。配置多个peer的时候，如何能在peer fail情况下，再次连接到其他的peer节点。

在 2016年1月15日下午3:29，DeJiang Zhu <douji...@gmail.com>写道：
Hello,

在 2016年1月15日下午2:44，Guanglin Lv <guang...@gmail.com>写道：

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：
最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

哈哈，balancer_by_lua 提供了最基础的接口，完全可以做到每请求动态配置

balancer_by_lua 并不是修改当前 upstream 的 server list
而是，在每请求在 balancer 阶段 get_peer 的时候动态指定
这个可定制程度非常高，当然玩法也不一样

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

当然，可以有不同的玩法，不同的玩法适用的场景不太一样

Thanks

--

--

--

doujiang24

Hello,

在 2016年1月15日下午3:49，董鑫功 <dongxin...@gmail.com>写道：

set_current_peer的时候，如果对应节点不通，直接返回connect() fail了。配置多个peer的时候，如何能在peer fail情况下，再次连接到其他的peer节点。

这个重试逻辑还是由 nginx 来完成，下一次重试的时候还是会进入 balancer_by_lua

具体你可以看看测试用例里的用法：

https://github.com/openresty/lua-resty-core/blob/master/t/balancer.t#L179

文档 > 测试用例 > 源码，我觉得这个阅读次序是个不错的方式

在 2016年1月15日下午3:29，DeJiang Zhu <douj...@gmail.com>写道：
Hello,

在 2016年1月15日下午2:44，Guanglin Lv <guan...@gmail.com>写道：

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：
最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

哈哈，balancer_by_lua 提供了最基础的接口，完全可以做到每请求动态配置

balancer_by_lua 并不是修改当前 upstream 的 server list
而是，在每请求在 balancer 阶段 get_peer 的时候动态指定
这个可定制程度非常高，当然玩法也不一样

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

当然，可以有不同的玩法，不同的玩法适用的场景不太一样

Thanks

--

--

--

dongxingong2014

嗯，谢谢，我已经有大致的思路了。

在 2016年1月15日下午5:31，DeJiang Zhu <douj...@gmail.com>写道：

Hello,

在 2016年1月15日下午3:49，董鑫功 <dongxin...@gmail.com>写道：
set_current_peer的时候，如果对应节点不通，直接返回connect() fail了。配置多个peer的时候，如何能在peer fail情况下，再次连接到其他的peer节点。

这个重试逻辑还是由 nginx 来完成，下一次重试的时候还是会进入 balancer_by_lua
具体你可以看看测试用例里的用法：
https://github.com/openresty/lua-resty-core/blob/master/t/balancer.t#L179

文档 > 测试用例 > 源码，我觉得这个阅读次序是个不错的方式

在 2016年1月15日下午3:29，DeJiang Zhu <douj...@gmail.com>写道：
Hello,

在 2016年1月15日下午2:44，Guanglin Lv <guan...@gmail.com>写道：

在 2016年1月15日星期五 UTC+8上午11:24:02，dongxin...@gmail.com写道：
最近在实现个动态的代理配置，在balancer_by_lua中从redis中获取ip,port 进行转发，看了下wiki目前好像只能配置单ip和port，
如何实现多个节点的负载均衡策略，比如ip hash,weight策略等。

个人觉得目前的balancer_by_lua有点名不副实，目前该模块的做的事情和balance无关，只是提供了一个动态修改upstream server的接口；

哈哈，balancer_by_lua 提供了最基础的接口，完全可以做到每请求动态配置

balancer_by_lua 并不是修改当前 upstream 的 server list
而是，在每请求在 balancer 阶段 get_peer 的时候动态指定
这个可定制程度非常高，当然玩法也不一样

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

我的场景里也是有动态设置upstream的需求，那时balancer_by_lua还没发布哈，我的思路是：

使用ngx_http_dyups_module模块动态创建upstream，每个server一个upstream，然后自己实现分发算法，再转发出去；

如果你自己不想实现分发算法，也可以用ngx_http_dyups_module动态创建upstream，但是多个server一个upstream，并配上分发算法应该也是可行的；

当然，可以有不同的玩法，不同的玩法适用的场景不太一样

Thanks

--

--

--

--

guanglinlv

在 2016年1月15日星期五 UTC+8下午3:29:57，doujiang写道：

Hello,

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

这个想法很好哈，集成一个upstream的通用能力库；一致性hash这里有一个纯lua实现的https://github.com/jaderhs/lua-consistent-hash

thanks.

dongxingong2014

这个纯lua实现，只提供了chash.get_upstream，节点宕机的话，怎么剔除节点

在 2016年1月19日星期二 UTC+8上午11:13:32，Guanglin Lv写道：

在 2016年1月15日星期五 UTC+8下午3:29:57，doujiang写道：
Hello,

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

这个想法很好哈，集成一个upstream的通用能力库；一致性hash这里有一个纯lua实现的https://github.com/jaderhs/lua-consistent-hash

thanks.

dongxingong2014

噢，只能重新使用hash key了是吧

在 2016年1月19日星期二 UTC+8下午6:07:24，L.D写道：

这个纯lua实现，只提供了chash.get_upstream，节点宕机的话，怎么剔除节点

在 2016年1月19日星期二 UTC+8上午11:13:32，Guanglin Lv写道：

在 2016年1月15日星期五 UTC+8下午3:29:57，doujiang写道：
Hello,

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

这个想法很好哈，集成一个upstream的通用能力库；一致性hash这里有一个纯lua实现的https://github.com/jaderhs/lua-consistent-hash

thanks.

doujiang24

Hello,

纯 Lua 的实现，性能应该不够好，尤其是频繁有节点上下线的时候

从我目前的尝试来看，用 C + LuaJIT 的方式还是不错的

在 2016年1月19日下午6:32，L.D <dongxin...@gmail.com>写道：

噢，只能重新使用hash key了是吧

在 2016年1月19日星期二 UTC+8下午6:07:24，L.D写道：
这个纯lua实现，只提供了chash.get_upstream，节点宕机的话，怎么剔除节点

在 2016年1月19日星期二 UTC+8上午11:13:32，Guanglin Lv写道：

在 2016年1月15日星期五 UTC+8下午3:29:57，doujiang写道：
Hello,

诚然，只有最基础的接口，要做一个完善一些的应用还是有些工作量
目前我在开发一个 resty.chash 用以替代 upstream 里的标准 chash 指令中的一致性哈希逻辑
同时，我们的灵活程度，远远高于原生的 up/down 策略

同时，我想还可以有类似 resty.upstream.chash，把通用的逻辑都实现了，用起来也可以非常方便，同时也能拥有最大的灵活特性

这个想法很好哈，集成一个upstream的通用能力库；一致性hash这里有一个纯lua实现的https://github.com/jaderhs/lua-consistent-hash

thanks.

--

guanglinlv

在 2016年1月19日星期二 UTC+8下午6:07:24，L.D写道：

这个纯lua实现，只提供了chash.get_upstream，节点宕机的话，怎么剔除节点

所以这个库只适合这种用法：每次请求处理时，调用add_upstream添加server后，调用get_upstream获得结果；

Thanks.

guanglinlv

在 2016年1月19日星期二 UTC+8下午9:32:00，doujiang写道：

Hello,

纯 Lua 的实现，性能应该不够好，尤其是频繁有节点上下线的时候
从我目前的尝试来看，用 C + LuaJIT 的方式还是不错的

的确，按照我上述描述的用法，就不存在节点上下线的场景了；预测cpu可能会占用较多，我还没做具体测试；

这种用法比较适合我现在的场景：动态获取后端服务器列表，均衡后进行转发；

thanks.

millken

网上也查了些资料，综合考量了下，最终使用dyups来做动态加载，ngx.balancer颗粒度很细，但实在不方便，或者是我懒。
在ngx.balancer再实现hash, round, weight之类的算法，无疑加重了工作量。并且性能也有待验证。

dongxingong2014

嗯，目前我用ngx.balancer实现的，按照nginx的RR动态加权算法实现了一遍，也不是很复杂，配合lrucache性能感觉不是问题。

在 2016年1月21日下午4:13，Millken Chen <mil...@gmail.com>写道：

网上也查了些资料，综合考量了下，最终使用dyups来做动态加载，ngx.balancer颗粒度很细，但实在不方便，或者是我懒。
在ngx.balancer再实现hash, round, weight之类的算法，无疑加重了工作量。并且性能也有待验证。

--