关于带有健康检查的一致性哈希机制

ssdrliu · 2016-08-25T09:58:10+00:00

Hello在 2016年8月25日上午11:41，Jinhua Luo <home...@163.com>写道：其实&#...

关于带有健康检查的一致性哈希机制

ssdrliu

Hi，春哥：

先说下需求。

我想根据用户请求url一致性哈希到后端缓存，后端使用多个redis实例，后端redis实例的需要健康检查，当某个redis挂掉或有新redis加入时，一致性哈希算法自动感知。

我的做法：

一致性哈希使用lua-resty-balancer；

健康检查使用了lua-upstream-nginx-module + lua-resty-upstream-healthcheck；

（lua-resty-upstream-healthcheck只支持http，做了redis的检查扩展）

在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）；

当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：

测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

doujiang24

Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：

在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）

；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

ssdrliu

Hi，doujiang，

打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。

这是否说明了package.loaded.*缓存server列表和chash实例的问题？

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：

Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

doujiang24

Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：

Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

ssdrliu

问题查到了，是在多进程下package.loaded不共享导致的，一个进程更新了，其他进程没有更新。

doujiang，这种场景有什么建议?

在 2016年8月25日星期四 UTC+8下午12:44:06，doujiang写道：

Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：
Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

doujiang24

Hello

在 2016年8月25日下午4:07，牧童 <ssd...@gmail.com>写道：

问题查到了，是在多进程下package.loaded不共享导致的，一个进程更新了，其他进程没有更新。
doujiang，这种场景有什么建议?

就眼下而言，解决多进程之间的同步问题，最好是：

1. 把数据放入共享内存，同时把数据版本号也放入共享内存

2. 按你需要的频率检查版本号（比如每请求，每分钟？）版本号不一致则重新生成一个 chash instance（chash:reinit)

在 2016年8月25日星期四 UTC+8下午12:44:06，doujiang写道：
Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：
Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

--

ssdrliu

重新生成一个instance不会打乱之前的哈希结果吗？会保持单调性吗？

在 2016年8月25日星期四 UTC+8下午10:29:37，doujiang写道：

Hello

在 2016年8月25日下午4:07，牧童 <ssd...@gmail.com>写道：
问题查到了，是在多进程下package.loaded不共享导致的，一个进程更新了，其他进程没有更新。
doujiang，这种场景有什么建议?

就眼下而言，解决多进程之间的同步问题，最好是：

1. 把数据放入共享内存，同时把数据版本号也放入共享内存
2. 按你需要的频率检查版本号（比如每请求，每分钟？）版本号不一致则重新生成一个 chash instance（chash:reinit)

在 2016年8月25日星期四 UTC+8下午12:44:06，doujiang写道：
Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：
Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

--

doujiang24

在 2016年8月26日上午9:54，牧童 <ssd...@gmail.com>写道：

重新生成一个instance不会打乱之前的哈希结果吗？会保持单调性吗？

不会乱，只要权重一样，哈希结果就是一致的

在 2016年8月25日星期四 UTC+8下午10:29:37，doujiang写道：
Hello

在 2016年8月25日下午4:07，牧童 <ssd...@gmail.com>写道：
问题查到了，是在多进程下package.loaded不共享导致的，一个进程更新了，其他进程没有更新。
doujiang，这种场景有什么建议?

就眼下而言，解决多进程之间的同步问题，最好是：

1. 把数据放入共享内存，同时把数据版本号也放入共享内存
2. 按你需要的频率检查版本号（比如每请求，每分钟？）版本号不一致则重新生成一个 chash instance（chash:reinit)

在 2016年8月25日星期四 UTC+8下午12:44:06，doujiang写道：
Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：
Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

--

--

ssdrliu

还是不大明白，如果版本号变了，哈希结果应该会变吧。举个例子：

起初有三台server a, b, c，权重都一样，哈希空间是三者平分；

后来比如c挂了（相当于版本号变了），这时我用a，b重新初始化一个instance，哈希空间应该是a，b两者平分。

那么，原先哈希到a，b上的object应该不会依然分别哈希到a，b上吧？

在 2016年8月26日星期五 UTC+8上午9:59:05，doujiang写道：

在 2016年8月26日上午9:54，牧童 <ssd...@gmail.com>写道：
重新生成一个instance不会打乱之前的哈希结果吗？会保持单调性吗？

不会乱，只要权重一样，哈希结果就是一致的

在 2016年8月25日星期四 UTC+8下午10:29:37，doujiang写道：
Hello

在 2016年8月25日下午4:07，牧童 <ssd...@gmail.com>写道：
问题查到了，是在多进程下package.loaded不共享导致的，一个进程更新了，其他进程没有更新。
doujiang，这种场景有什么建议?

就眼下而言，解决多进程之间的同步问题，最好是：

1. 把数据放入共享内存，同时把数据版本号也放入共享内存
2. 按你需要的频率检查版本号（比如每请求，每分钟？）版本号不一致则重新生成一个 chash instance（chash:reinit)

在 2016年8月25日星期四 UTC+8下午12:44:06，doujiang写道：
Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：
Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

--

--

doujiang24

Hello

在 2016年8月26日上午10:27，牧童 <ssd...@gmail.com>写道：

还是不大明白，如果版本号变了，哈希结果应该会变吧。举个例子：

嗯嗯，是的哈

起初有三台server a, b, c，权重都一样，哈希空间是三者平分；
后来比如c挂了（相当于版本号变了），这时我用a，b重新初始化一个instance，哈希空间应该是a，b两者平分。
那么，原先哈希到a，b上的object应该不会依然分别哈希到a，b上吧？

嗯嗯，这个一致性的语义还是有的，原来哈希到 a，b 的还是不动

原来到 c 的会分摊到 a，b

在 2016年8月26日星期五 UTC+8上午9:59:05，doujiang写道：

在 2016年8月26日上午9:54，牧童 <ssd...@gmail.com>写道：
重新生成一个instance不会打乱之前的哈希结果吗？会保持单调性吗？

不会乱，只要权重一样，哈希结果就是一致的

在 2016年8月25日星期四 UTC+8下午10:29:37，doujiang写道：
Hello

在 2016年8月25日下午4:07，牧童 <ssd...@gmail.com>写道：
问题查到了，是在多进程下package.loaded不共享导致的，一个进程更新了，其他进程没有更新。
doujiang，这种场景有什么建议?

就眼下而言，解决多进程之间的同步问题，最好是：

1. 把数据放入共享内存，同时把数据版本号也放入共享内存
2. 按你需要的频率检查版本号（比如每请求，每分钟？）版本号不一致则重新生成一个 chash instance（chash:reinit)

在 2016年8月25日星期四 UTC+8下午12:44:06，doujiang写道：
Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：
Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

--

--

--

ssdrliu

good! 刚才我也test了一下，多次new()也没有问题，会保持一致单调性~

在 2016年8月26日星期五 UTC+8上午11:07:42，doujiang写道：

Hello

在 2016年8月26日上午10:27，牧童 <ssd...@gmail.com>写道：
还是不大明白，如果版本号变了，哈希结果应该会变吧。举个例子：

嗯嗯，是的哈

起初有三台server a, b, c，权重都一样，哈希空间是三者平分；
后来比如c挂了（相当于版本号变了），这时我用a，b重新初始化一个instance，哈希空间应该是a，b两者平分。
那么，原先哈希到a，b上的object应该不会依然分别哈希到a，b上吧？

嗯嗯，这个一致性的语义还是有的，原来哈希到 a，b 的还是不动
原来到 c 的会分摊到 a，b

在 2016年8月26日星期五 UTC+8上午9:59:05，doujiang写道：

在 2016年8月26日上午9:54，牧童 <ssd...@gmail.com>写道：
重新生成一个instance不会打乱之前的哈希结果吗？会保持单调性吗？

不会乱，只要权重一样，哈希结果就是一致的

在 2016年8月25日星期四 UTC+8下午10:29:37，doujiang写道：
Hello

在 2016年8月25日下午4:07，牧童 <ssd...@gmail.com>写道：
问题查到了，是在多进程下package.loaded不共享导致的，一个进程更新了，其他进程没有更新。
doujiang，这种场景有什么建议?

就眼下而言，解决多进程之间的同步问题，最好是：

1. 把数据放入共享内存，同时把数据版本号也放入共享内存
2. 按你需要的频率检查版本号（比如每请求，每分钟？）版本号不一致则重新生成一个 chash instance（chash:reinit)

在 2016年8月25日星期四 UTC+8下午12:44:06，doujiang写道：
Hello

在 2016年8月25日上午11:19，牧童 <ssd...@gmail.com>写道：
Hi，doujiang，
打日志确认调到delete了，并且在delete后立即调用同一个key是可以find到新redis实例的，但在其他位置find却还是挂掉的redis实例。
这是否说明了package.loaded.*缓存server列表和chash实例的问题？

嗯，应该是你缓存的这些示例没有更新

在 2016年8月25日星期四 UTC+8上午10:17:36，doujiang写道：
Hello

在 2016年8月25日上午9:58，牧童 <ssd...@gmail.com>写道：
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）
；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

是不是有些 case 没有调用到 chash:delete 呢？这个 delete 接口应该没有问题才对

--

--

--

--

--

pjc685

你好，请问你的问题解决了吗？我也遇到你一样的需求，能不能交流下？万分感谢！

在 2016年8月25日星期四 UTC+8上午9:58:10，牧童写道：

Hi，春哥：

先说下需求。
我想根据用户请求url一致性哈希到后端缓存，后端使用多个redis实例，后端redis实例的需要健康检查，当某个redis挂掉或有新redis加入时，一致性哈希算法自动感知。

我的做法：
一致性哈希使用lua-resty-balancer；
健康检查使用了lua-upstream-nginx-module + lua-resty-upstream-healthcheck；
（lua-resty-upstream-healthcheck只支持http，做了redis的检查扩展）
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

ssdrliu

是的解决了。

不使用package.loaded，使用共享词典保存活动的server列表，healthcheck动态更新。

每请求到来，根据server列表构建chash实例，并查找对应的server。

在 2016年8月26日星期五 UTC+8下午4:36:07，pjc...@hotmail.com写道：

你好，请问你的问题解决了吗？我也遇到你一样的需求，能不能交流下？万分感谢！

在 2016年8月25日星期四 UTC+8上午9:58:10，牧童写道：
Hi，春哥：

先说下需求。
我想根据用户请求url一致性哈希到后端缓存，后端使用多个redis实例，后端redis实例的需要健康检查，当某个redis挂掉或有新redis加入时，一致性哈希算法自动感知。

我的做法：
一致性哈希使用lua-resty-balancer；
健康检查使用了lua-upstream-nginx-module + lua-resty-upstream-healthcheck；
（lua-resty-upstream-healthcheck只支持http，做了redis的检查扩展）
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？

pjc685

能否请教下实现脚本? 可以给个联系方式吗?

在 2016年8月25日星期四 UTC+8上午9:58:10，牧童写道：

Hi，春哥：

先说下需求。
我想根据用户请求url一致性哈希到后端缓存，后端使用多个redis实例，后端redis实例的需要健康检查，当某个redis挂掉或有新redis加入时，一致性哈希算法自动感知。

我的做法：
一致性哈希使用lua-resty-balancer；
健康检查使用了lua-upstream-nginx-module + lua-resty-upstream-healthcheck；
（lua-resty-upstream-healthcheck只支持http，做了redis的检查扩展）
在healthcheck模块中，当发现peer_fail的时候，将对应server删除（调用lua-resty-balancer的delete接口）；
当发现peer_ok的时候，重新加入server（调用lua-resty-balancer的set接口）。

问题：
测试发现，挂掉的redis健康检查可以自动发现，但是一致性哈希还是会将请求哈希到挂掉的redis上（调用lua-resty-balancer的find接口）。

另外，存储redis的server和lua-resty-balancer实例，是用来官方示例的方法package.loaded.*，根据healthcheck的结果动态更新。

请问，这是问题是我用法不对，还是lua-resty-balancer模块有问题？