-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jodis问题 #9
Comments
刚kill的时候当时还在进行的请求是肯定会断的,但是过了一段时间,最长不超过proxy配置的session超时时间,再请求就不会报错了 2015年12月15日星期二,Ady Xiong notifications@github.com 写道:
Thanks, |
你说的”session超时时间“,是不是session_max_timeout?如果这个值很大,那等待时间是不是也很久? |
不是,是zk_session_timeout。详情见配置文件中的注释。 |
Jodis是监控zk上结点变化来增加proxy的 首先手动kill如果是kill -9的话需要一段时间zk上的结点才会消失(取决于proxy设置的zk session超时时间)。 这中间需要一个trade off,如果超时时间特别短那jodis切换就会很快,但代价就是proxy很容易因为网络抖动或者高负载而死掉。如果超时时间很长那代价就是jodis切换会很慢。 谢谢 |
经过测试发现,Jodis无法负载均衡,@Apache9说的很对 |
“无法负载均衡”是什么意思? |
对,你说的无法负载均衡是啥意思?我的意思是jodis最终还是能把坏的节点踢掉的,只是时间长短的问题 |
可能我说的有点过哦,呵呵,就是像@Apache9说的:”如果超时时间很长那代价就是jodis切换会很慢“,我本地测试结果也是切换时间比较长。 |
你的zk_session_timeout设的是多少? |
那你就把超时时间设短一点儿。。。这个看你业务本身的需求到底是要反应多快 |
还有个问题就是,无论你怎么设参数,业务上如果要求不能访问失败,肯定是要加重试的逻辑的,基于zk的HA永远是比实际的情况慢半拍的 |
赞同 |
我启用了2个proxy(分别是proxy1、proxy2),用jodis并发测试。在测试过程中,我手动kill掉proxy2,这个时候jodis客户端报:
redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream.
感觉jodis实现负载均衡没有起到作用,还是我使用不正确?
The text was updated successfully, but these errors were encountered: