JGroups使用过程中出现的问题及追踪

可参考的资料1：

http://community.jboss.org/wiki/FDVersusFDSOCK

看完资料之后，自己作了实验。

GMS的失效检测推荐使用FD + FD_SOCK，如果有多个节点同时失效，最好使用FD_ALL+FD_SOCK。

其实比较有用的是使用FD_SOCK + KEEP_ALIVE + ALIVE_INTERNAL_TIME，遗憾的是，FD_SOCK有个参数KEEP_ALIVE，却没有设置ALIVE_INTERNAL_TIME的地方，导致FD_SOCK检测方式形同虚设，好多时候都是kill -9方式杀掉java进程，根本不可能gracefully.由于操作系统缺省的tcp ALIVE_INTERNAL_TIME=7200s，所以很要命的问题啊。

bela ban推荐：

关于FD_ALL:

Per Bela, UDP based stacks should use FD_ALL instead of FD. TCP based stacks should not.

FD_ALL works better in cases where X > 1 nodes fail; with FD it will take X * the failure timeout to suspect the Xth node. E.g. 3 nodes C, D, E fail, 30 sec failure timeout, it will be 90 secs before the failure of E is discovered.

参考https://issues.jboss.org/si/jira.issueviews:issue-html/JGRP-195/JGRP-195.html

https://issues.jboss.org/si/jira.issueviews:issue-html/JBAS-3004/JBAS-3004.html

https://issues.jboss.org/si/jira.issueviews:issue-html/JBAS-3003/JBAS-3003.html

https://issues.jboss.org/si/jira.issueviews:issue-html/JBAS-6604/JBAS-6604.html

https://issues.jboss.org/si/jira.issueviews:issue-html/JGRP-937/JGRP-937.html

最后总结：

项目中使用的oscache + jgroups在启动时偶尔会卡住，主要是因为FD_SOCK没有有效检测到leader失效导致新启动的服务获取一个失效的port，GMS join... retrying的死循环导致。现在配置调整如下：

PING(timeout=2000;num_initial_members=3):\
MERGE2(min_interval=5000;max_interval=10000):\
FD_SOCK(down_thread=false;up_thread=false):\
FD(timeout=20000;max_tries=3;shun=false;down_thread=false;up_thread=false):\
VERIFY_SUSPECT(timeout=1500):\
pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;max_xmit_size=8192):\
UNICAST(timeout=300,600,1200,2400):\
pbcast.STABLE(desired_avg_gossip=20000):\
FRAG(frag_size=8096;down_thread=false;up_thread=false):\
pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=true)

即是这样修改之后，如果在FD检测有效期内，20*4=80秒，重新加入的节点，仍然会去联结失效的leader，但是过段时间之后就会正常，如果在leader之后很多节点同时失效，这个时间会比较长。可根据实际情况调整时间，如果每次都是大量实效，还是使用FD_ALL比较好。

JGroups使用过程中出现的问题及追踪

猜你喜欢