Jgroups 协议栈和高级概念

时间 2019-12-04

标签 jgroups 协议高级概念繁體版

原文原文链接

本章讨论怎么样正确使用和配置JGroups的协议栈协议，以及一些 JGroups 的高级概念。 java

1. jGroups协议栈

咱们知道jGroups是一个可靠多播传输工具包，它可以为集群中成员提供点对点，点对组的通讯，全部通讯经过通道完成。通道基于协议栈之上，协议栈中协议各自有本身特别的功能，这些功能综合起来使通道通道具备完成多波传输的能力。协议栈中多种协议所具备的主要功能能够总结为：消息传输，集群发现，消息排序，消息无损耗传输，错误节点发现，集群成员管理。下图显示三个节点的集群，协议栈底层传输协议基于物理网络之上，通道基于协议栈之上，构建块接口和应用基于通道之上，以下： node

接下来咱们讨论这些被通道普遍使用的协议，根据他们各自的特定功能，咱们讨论提供这些功能所需的关键属性，注意，这些属性只有在很是理解jGroups协议栈的状况下能够进行修改，因此咱们不建议初学者对协议栈中协议的属性进行修改。咱们讨论这些属性的目的是为了了解协议栈的功能。服务器

1.1 传输协议

传输协议是协议栈最底层的协议，它负责从物理网络环境接收消息，将接收到的消息传递到协议栈中上层相邻的协议，以及将协议栈中上层协议传递下来的消息发送到物理网络。传输层协议主要包括UDP，TCP，TUNNEL。这些协议时独一的，在同一个协议栈中您只能配置一个传输层协议。
网络

1.1.1 UDP

UDP使用IP多播（咱们也能够配置使用多个单播）发送和接收数据，是默认推荐的传输层协议。若是您选择UDP做为您群组通讯的传输协议，UDP配置以下: 异步

<UDP
mcast_port="${jgroups.udp.mcast_port:45588}"
tos="8"
ucast_recv_buf_size="20M"
ucast_send_buf_size="640K"
mcast_recv_buf_size="25M"
mcast_send_buf_size="640K"
loopback="true"
discard_incompatible_packets="true"
max_bundle_size="64K"
max_bundle_timeout="30"
ip_ttl="${jgroups.udp.ip_ttl:8}"
enable_bundling="true"
enable_diagnostics="true"
thread_naming_pattern="cl"
timer_type="new"
timer.min_threads="4"
timer.max_threads="10"
timer.keep_alive_time="3000"
timer.queue_max_size="500"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="8"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="10000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Run"/>

如上咱们能够发现UDP传输协议包括不少配置选项，接下来咱们首先列出UDP特有的配置属性，随后列出UDP，TCP，TUNNEL所共有的配置项。UDP 特有的属性： tcp

ip_mcast肯定是否使用IP多播，默认值为true，若是设为false，多个单播通讯的模式（发送多个单播包）代替多播通讯模式。全部包的发送都是经过UDP协议发送UDP数据包
mcast_addr 肯定多播通讯的地址，若是配置时省略了这个属性，则默认的配置为288.11.11.11
mcast_port 肯定多播通讯的端口，若是这个属性被省略了则默认的端口为45588
mcast_send_buf_size， mcast_recv_buf_size,，ucast_send_buf_size ，ucast_recv_buf_size 定义了jGroups发送和接收多播和单播包的大小，jGroups在发送和接收多播和单播包时根据这些配置向操做系统发送请求。若是这些属性配置过小，容易在Java层面形成丢包等现象，但多播和单播运行最大包的大小在操做系统层面也有限制，因此为了使jGroups高效率工做咱们须要在操做系统层面作优化配置，随后咱们在高级概念部分会讨论此问题
bind_port肯定单播接收套接字绑定的端口，默认为0，即便用短时间的端口
port_range肯定若是bind_port肯定的端口不可用从新尝试的端口，默认为1
ip_ttl肯定IP多播包的生存周期（TTL），TTL是多播通讯中常见的概念，主要指多播通讯中一个包被容许的网络跳跃次数，超过这一值后网络设备将包丢弃
tos 肯定发送多播和单播包的类

UDP，TCP，TUNNEL所共有的属性：分布式

singleton_name提供一个单例的传输层配置项，被ChannelFactory使用，若是传输层配置了此属性，ChannelFactory将使建立的通道共享传输层协议，随后咱们在高级概念部分会讨论此属性
bind_addr肯定一个发送和接收消息的地址，默认，jGroups使用JVM系统参数jgroups.bind_addr来肯定此地址
receive_on_all_interfaces肯定此节点是否监听全部多播地址（多个网卡），默认值为false，该属性重写了bind_addr定义的接收多播的地址，但节点发送多播地址任由bind_addr定义
send_on_all_interfaces肯定此节点是否经过您本地全部网卡发送多播消息，若是您本地有N个网卡（即N个IP地址），则同一个多播包被发送了N此，使用此属性能够避免此状况
receive_interfaces肯定接收多播包的地址列表，多播接收的套接字将监听于这些接口，这些地址是用逗号隔开的IP地址或网卡名，例如：192.168.5.1,eth1,127.0.0.1
send_interfaces肯定发送多播消息的地址，多播发送套接字将经过这些地址发送多播消息，这个地址一样是用逗号隔开的IP地址或网卡名，例如：192.168.5.1,eth1,127.0.0.1，这说明同一个多播包将在这三个地址上同时发送，即一个包被发送了3次
enable_bundling，max_bundle_size，max_bundle_time肯定是否容许消息捆绑。若是enable_bundling只为true，传输层协议将要发送的消息放在一个队列中，直到队列的大小达到max_bundle_size，接着传输层协议将全部队列中的消息捆绑成一个大消息而后发送。固然在消息队列没有达到max_bundle_size以前，队列中的消息等待时间超过max_bundle_time，则传输协议一样将队列中的消息捆绑成一个发消息发送。在接收端，传输层将这个大消息分裂而后传递该高层协议处理。该属性的默认值为true，即JGroups默认容许消息捆绑，消息捆绑的大小为64000字节，超时时间为30毫秒。JGroups提供API接口指定是否进行消息捆绑，RequestOptions.setFlags(Message.DONT_BUNDLE)可使要发送的消息不进行消息捆绑发送机制，例如DONT_BUNDLE标记的消息，传输层协议不将其放入等待队列，会当即发送。
loopback肯定线程给群组发送消息是否携带消息备份（消息发送到组中老是也发送到者本身）。若是此属性职位false，发送线程不携带消息，传输层协议读取网络中的消息，使用传输层线程池中线程传递消息。若是此属性值为true，则运行通道接收本身的消息，以防网卡出现故障
discard_incompatible_packets肯定是否忽略群组中的成员使用其余版本的JGroups发送消息。群组中的任何一个消息都绑定着一个JGroups版本，若是此值得设定为true，则接收到的消息中版本不匹配的消息将被忽略，会员相应的警告日志输出，此属性的默认值为true
enable_diagnostics，diagnostics_addr，diagnostics_port 肯定是否传输层打开一个监听在地址diagnostics_addr和端口diagnostics_port上，若是该属性为true则容许监听请求链接
thread_pool.*定义JGroups用来处理消息，将消息传递向高层协议的线程池的属性，这些属性用来初始化java.util.concurrent.T hreadPoolExecutorService，在以前的配置中咱们定义链接池的最小线程数为2，最大链接数为8，若是多于最小线程数个线程建立，若是线程携带返回则将等待5000毫秒后分配一个新的消息，若是没有线程可供携带消息，消息则被放置在一个队列中，直到队列的大小为10000，若是尚未线程可用则消息被丢弃。
oob_thread_pool.*与thread_pool相似，初始化java.util.concurrent.T hreadPoolExecutorService，用来将接收到的消息传递到高层协议。在这里的线程用来传递Out-Of-Band (OOB)消息，OOB消息是脱离顺序传递即NAKACK 和UNICAST相关的消息，OOB消息是JGroups协议内部使用，一样也能够被应用程序使用。例如，JBossCache在REPL_SYNC模式下OOB消息用于2象限提交中的第二象限。

1.1.2 TCP

可供选择的，JGroups构建群组通讯业能够基于TCP链接。与UDP相比，TCP则须要更多的网络流量，特别是当群组的成员的数量较多时。从根本上来讲，TCP是单播协议，发送多播消息，JGroups使用多个TCP单播。若是要使用TCP做为传输协议，则须要在JGroups协议栈中配置TCP协议，以下是一个配置的例子: 工具

<TCP singleton_name="tcp" start_port="7800" end_port="7800"/>

以下为TCP协议专有的属性： oop

start_port，end_port定义了应用所能绑定的TCP端口的范围，服务器端监听的套接字绑定start_port开始的第一个可用的端口，若是end_port以前的全部端口不可以使用（被其它监听套接字使用），JGroups将会抛出异常。若是没有配置end_port，或end_port的值小于start_port，则端口的范围没有限制；若是start_port的值等于end_port，则JGroups使用惟一肯定的端口，即在上面的配置中惟一的端口号为7800。JGroups提供的默认配置是7800，若是该值设为0则须要操做系统选择一个随机端口（MPING和TCPGOSSIP协议使用）。
bind_port它至关于start_port的化名，若是咱们配置此属性，则start_port的值为它
recv_buf_size, send_buf_size定义了接收和发送缓冲区的大小，通常咱们建议配置一个较大的缓冲区，这样咱们不会由于接收的消息太大而致使消息丢失
conn_expire_time定义了最大过时时间（毫秒），即多长时间若是没有消息接收链接被链接释放器关闭
reaper_interval定义了链接释放器运行的时间间隔（毫秒），若是该属性的值为零，链接释放器释放链接的功能被禁止，若是该属性大于零，则每隔属性值定义的值进行一次链接释放。该属性的默认值为零
sock_conn_timeout定义了Java套接字建立的最大时间，若是进行初始化节点发现，且该节点异常，则不处于一只等待的状态，而是在等待该时间后去发现另外的节点。该属性默认值为2000
use_send_queues定义每一个链接是否使用本身独自的发送队列。这个能够预防通讯中一方若是发生异常通讯一只处于等待状态。该属性默认值为true
external_addr定义了对群组成员发送广播的外部的IP地址。特别在有网络交换，即一个节点位于一个私有网络中，这个私有网络位于防火墙以后，在这种状况下该属性特别有用。若是不设定external_addr属性，若是你的节点位于防火墙以后，则你的节点不可以发送广播给防火墙外的群组成员
skip_suspected_members肯定是否单播消息应该发送到异常的节点，该属性默认值为true
tcp_nodelay肯定TCP_NODELAY，TCP默认会对小消息绑定成一个大消息而后发送，若是咱们进行异步群组通讯咱们最后应该禁止TCP的这种延迟机制，该属性的值默认为false

1.1.3 TUNNEL

TUNNEL协议使用一个外部路由进程发送消息。外部的路由进程能够经过运行org.jgroups.stack.GossipRouter的main方法启动。群组中的任何节点都要注册到这个路由，任何消息都首先发送到路由，而后路由给他的目的接收者。TUNNEL协议能够用来创建防火墙两点节点的通讯，一个节点穿过防火墙于路由进程创建链接（使用80端口）将消息方式给防火墙对面的节点，一样使用与路由进程的TCP链接防火墙对面节点发送的消息。TUNNEL协议配置大体以下: 性能

<TUNNEL singleton_nam e="tunnel" router_port="12001" router_host="192.168.5.1"/>

TUNNEL协议全部的属性以下:

router_host指定路由进程的运行地址
router_port指定路由进程监听的端口
reconnect_interval指定TUNNEL尝试链接到路由进程的的时间间隔（毫秒），若是TUNNEL链接路由进程失败，该属性设定了时间间隔，TUNNEL则会每隔这个时间间隔尝试链接路由进程

1.2 发现协议

当一个节点上的通道第一次链接，它必须探测发现是否有其它节点运行着一致的通道，即找到集群的协调者（第一个建立的节点为协调者，负责新建立的节点加入集群）。发现协议用来发现集群中活跃的节点及集群的协调者。这些信息接着传递给集群成员管理协议（GMS），GMS协议与协调者的GMS通讯，将新加入的节点加入到集群。消息关于GMS的描述咱们随后介绍。发现协议一般也协助合并协议（MERGE2）处理集群分裂的情形。关于MERGE2一样咱们随后会作详细的介绍。发现协议位于传输协议之上，所以须要传输协议的不一样使用相应的发现协议，接下来咱们列出jGroups中用到的发现协议。

1.2.1 PING

发现协议PING既能够工做于发生多播PING到一个IP多播地址，也能够链接到TUNNEL的路由进程。也就是说发现协议PING位于传输协议UDP或TUNNEL之上。任意一个节点对PING消息的反馈消息包括协调者的地址和本身的地址，JOIN PING消息发送后等待timeout属性定义的时间或num_initial_members属性定义的节点回复后，该加入的节点会根据反馈消息肯定协调者，发送JOIN消息，若是没有收到任何反馈，会认为本身是集群中第一个节点为协调者。

以下为PING基于IP多播的配置:

<PING tim eout="2000" num _initial_mem bers="3"/>

以下是PING基于TUNNEL路由进程的配置:

<PING gossip_host="localhost" gossip_port="1234" timeout="2000" num _initial_mem bers="3"/>

PING协议的属性以下：

timeout肯定最大等待num_initial_members个成员的响应时间，该属性的默认值为3000
num_initial_members等待最小数量的成员响应的个数，这个响应个数具体指timeout以前的响应成员最小个数，默认为2
gossip_host肯定TUNNEL路由进程运行的地址
gossip_port肯定TUNNEL路由进程监听的端口
gossip_refresh肯定拿到TUNNEL路由进程的时间间隔（毫秒），默认为20000
initial_hosts是用逗号隔开的地址和端口（例如host1[12345],host2[23456]）肯定PING的目的地址，默认为空，表示IP多播被使用。若是该属性列出地址，你必须列出全部集群地址，不能指定部分已知的地址，合并协议（MERGE2）将不可以可靠地工做

若是gossip_host 和 gossip_port属性被定义，集群使用PING路由进程来完成初始的发现；若是initial_hosts被定义，集群PING定义好的地址来完成初始的发现；其余状况IP多播被使用来完成初始化发现。

1.2.2 TCPGOSSIP

TCPGOSSIP协议只能和路由消息一块儿工做。它和PING消息使用gossip_host 和 gossip_port属性提供的功能同样，它可位于TCP和UDP传输协议之上，以下为一配置的示例:

<TCPGOSSIP timeout="2000" num_initial_m em bers="3" initial_hosts="192.168.5.1[12000],192.168.0.2[12000]"/>

TCPGOSSIP协议的全部属性以下：

timeout肯定最大等待num_initial_members个成员的响应时间，该属性的默认值为3000
num_initial_members等待最小数量的成员响应的个数，这个响应个数具体指timeout以前的响应成员最小个数，默认为2
initial_hosts是用逗号隔开的地址和端口（例如host1[12345],host2[23456]）用来注册路由进程

1.2.3 TCPPING

TCPPING 协议属性包括要发现的成员地址，经过Ping这些已知的成员完成发现。TCPPING协议基于TCP传输协议之上。以下为TCPPING协议属性配置示例。

<TCPPING timeout="2000"
num_initial_members="3"
initial_hosts="hosta[2300],hostb[3400],hostc[4500]"
max_dynamic_hosts="3"
port_range="3">

具体属性包括：

timeout 肯定等待PING num_initial_members个成员返回的最大等待时间（毫秒），默认值为3000
num_initial_members 肯定要等待返回相应的最小成员个数，直到timeout发生，该属性的默认值为2
initial_hosts 逗号分开的地址，例如host1[1234 5]，host2[23456]，该属性肯定发现协议TCPPING 要PING的地址
max_dynamic_hosts 肯定最大能够动态加入到集群的地址个数（默认为0）。若是动态加入集群的特性被禁止，则要确保<initial_hosts>属性列出了全部成员地址，不然有些成员在集群启动时会遗漏某些成员
port_range 肯定连续的端口号当进行初始化成员关系。起始端口为initial_hosts肯定的端口号，如上initial_hosts的定义，TCPPING 协议将尝试PING hosta[2300]， hosta[2301]，hosta[2302]， hostb[3400]， hostb[3401]，hostb[3402]，hostc[4500]，hostc[4 501]，及 hostc[4502]

1.2.4 MPING

MPING使用IP多播发现初始的成员关系。不像其余发现协议须要借助于传输层协议发送发现消息，MPING经过它本身的套接字发送和接收多播消息。因为使用MPING协议经过多播消息完成初始发现，因此它可使用与任何传输协议，可是它最常被TCP协议使用。咱们知道TCPPING 协议须要经过initial_hosts属性明确的列出要初始发现的地址，但MPING则不须要。MPING一般用作TCP作传输协议，IP多播作为初始发现的场景，以下为MPING协议配置示例。

<MPING timeout="2000" num_initial_members="3" bind_to_all_interfaces="true" mcast_addr="228.8.8.8" mcast_port="7500" ip_ttl="8"/>

1.3 错误探测协议

错误探测协议用来发现集群中发生错误的节点。当某一个节点发生错误被探测到，一个怀疑确认会发生，当怀疑确认完成后该节点认为是死的（发生错误），集群则会更新本身的成员关系视图，群组中新的消息就不会发向该发生错误的节点。错误探测协议也是JGroups配置<config>的子元素，接下来咱们明细这些协议。

1.3.1 FD

FD协议基于心跳消息（are-you-alive）。该协议须要任意一个节点周期性的Ping它的邻居节点，若是邻居节点没有返回，发生心跳消息的节点发送SUSPECT消息给集群，集群协调者接收到SUSPECT消息后验证怀疑的节点是否死掉（VERIFY_SUSPECT），若是节点被确认为死掉，协调者更新集群成员关系视图，死掉的节点被移除。以下为FD配置示例。

<FD timeout="6000"
max_tries="5"
shun="true"/>

1.3.2 FD_SOCK

错误探测协议FD_SOCK基于群组成员建立的TCP套接字环。集群中的任何一个节点都链接到它的邻居，集群中第一个节点链接到第二个节点，第二个节点链接到第三个节点，这样最后一个节点链接到第一个节点。这样若是某一个节点发送异常，它的邻居节点会发现异常，检测到错误。FD_SOCK 能够不包含任何属性，以下为FD_SOCK配置示例。

相关FD_SOCK属性元素列表以下：

bind_addr 肯定发送和接收多播消息的地址，JGroups默认使用系统参数jgroups.bind_addr来确实该属性的值

1.3.3 VERIFY_SUSPECT

VERIFY_SUSPECT协议确认被怀疑的节点是否确实死掉了（经过发送确认消息）。这个操做是被集群的协调者执行的。若是确认节点死掉，则该节点将会被异常集群成员列表视图。以下为VERIFY_SUSPECT协议属性配置。

<VERIFY_SUSPECT timeout="1500"/>

1.4 可靠传输协议

可靠传输协议确保群组消息确实可靠传递，并以正确的顺序（先入先出，FIFO）传递到目的地。可靠的消息传递基础是正面和非正面的确认消息（ACK和NAK）。在ACK模式中，发送者从新发送该消息，直到从接收者接收到确认。在NAK模式，接收者请求发送者从新传输，直到发现了缺失的消息。

1.4.1 UNICAST

UNICAST协议在发送单播消息时使用。UNICAST协议使用ACK模式，它的配置也在JGroups <config>中，注意，若是底层传输协议使用TCP，UNICAST则不须要配置，由于TCP传输自己就能够保证消息传输时可以FIFO。以下为UNICAST协议配置示例。

<UNICAST timeout="300,600,1200,2400,3600"/>

UNICAST协议只包含一个属性：

timeout 肯定从新传输的超时时间（毫秒）。例如，若是timeout值为100，200，400，800，若是消息发送者在等待100毫秒尚未接收到消息接收者的ACK消息，则消息发送者从新发送消息（第一次重发），消息发送者继续等待200毫秒仍然没有接收到ACK消息，则消息发送者再次从新发送消息（第二次重发），这样直到等待800毫秒进行第四次重发。若是第一次重发的等待时间很小，消息可能被重发两次（发送者收到ACK消息大于等待时间）。等待时间较大（如1000，2000，4000）能够提升网络传输性能，特别是在网络环境能够确保UDP数据包不会丢失的环境中。固然若是时间较大，且UDP数据包丢失频繁发生，在这种环境下传输性能很低，由于重传的等待时间很大。

1.4.2 NAKACK

NAKACK协议在发送多播消息时使用。NAKACK协议使用NAK模式。在这种协议下，每一个消息绑定一个序列号，消息接收者根据序列号确保消息按正确的顺序传递。若是接收者发现了一个序列号的缺失，接收者安排一个周期性的任务去要求发送者从新发送该序列号的消息，当缺失的序列号的消息收到，则任务取消。NAKACK协议也是配置在JGroups <config>中，以下为一配置示例。

<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false"
retransmit_timeout="300,600,1200,2400,4800"
gc_lag="0"
discard_delivered_msgs="true"/>

相关pbcast.NAKACK属性元素列表以下：

retransmit_timeout 定义了一系列超时时间（毫秒），接收者发现某一序列号消息丢失，消息重发请求发送给消息发送者，消息接收者等待超时后从新发送消息重发请求给发送者，该属性定义了这个超时时间，并且依次递增（第二次等待超时时间大于第一次）
use_mcast_xmit 肯定消息发送者是否重发消息给整个集群，仍是只重发消息给请求重发消息的接收者
max_xmit_size 肯定捆绑重发消息的大小。若是不少消息须要被重发，这些重发消息可能被捆绑成一个大消息而后重发
discard_delivered_msgs 肯定是否在接收端清除已接收的消息。默认状况下，消息接受者将接收到的消息保存起来，放置原始的发送者发生异常或离开集群后，消息能够继续重发。若是咱们只须要消息发送者重发消息，那么咱们能够在接收端清除接收到的消息，该中状况咱们须要设定此属性的值为true
gc_lag 确保在周期性清除协议（随后有消息介绍）提示全部节点已经收到了消息后仍然保留在发送者内存中的消息个数。该属性默认值为20

1.5 GMS

GMS即群组成员关系协议，该协议时JGroups协议栈中的重要协议，它维护者一个活着节点的列表。GMS负责群组成员加入和离开群组的请求，同时它也处理错误探测协议发送的SUSPECT协议。GMS协议也是配置在JGroups <config>中，以下为一配置示例。

<pbcast.GMS print_local_addr="true"
join_tim eout="3000"
join_retry_tim eout="2000"
shun="true"
view_bundling="true"/>

相关pbcast.GMS属性元素列表以下：

join_timeout 肯定新节点加入请求成功的最大时间（毫秒），若是超时随后从新尝试
join_retry_timeout 肯定新节点加入请求失败后从新加入请求的超时时间（毫秒）
print_local_addr 肯定是否在启动时输出本身的地址发哦标准输出
shun 肯定一个节点在接收到集群视图代表本身不是集群的节点时将本身从集群中断开
disable_initial_coord 肯定是否阻止该节点在集群初始化（初始化通道）时成为集群的协调者。注意该属性只是在集群初始化时起做用，但在集群初始化完成后不起做用，即若是集群中当前协调者离开集群，从新分配协调者时该属性不起做用
view_bundling肯定是否容许同时接收到多个加入或离开请求。这样集群视图只更新一次就完成多个请求，这样更有效率

1.6 FC

FC即流量控制协议。流量控制协议用来在集群中调节消息发送的比率和消息接收的比率。若是消息发送者的节点发送的速度很快超过了消息接收者节点处理消息的速度，这可能会致使接收到陷入异常或某些消息丢失，流量控制协议负责调解此类情况。事实上，JGroups流量控制协议基于相似信贷的设计，一开始消息发送者和消息接收者有相同的贷款（字节数），发送者减小贷款值经过本身发送的字节数，接收者已接收到本身累加本身的贷款，若是发送者贷款下降到某一阈值，接收者发送一些贷款给发送者，若是发送者用完本身的贷款，则发送者处于阻塞状态直到接收到接收者的贷款。流量控制协议也是配置在JGroups <config>中，以下为一配置示例。

<FC max_credits="2000000"
min_threshold="0.10"
ignore_synchronous_response="true"/>

可配置的流量控制协议属性以下：

max_credits 肯定最大的信贷系统的贷款值（字节），该属性定义的值应该小于JVM启动时分配的堆的大小
min_credits 肯定信贷系统的贷款最小值，若是发送者贷款下降到这个值则接收者要发送贷款给发送者
min_threshold 肯定计算信贷系统的贷款最小值的比率，信贷系统的贷款最小值=max_credits* min_threshold，若是min_threshold定义，min_credits属性定义的信贷系统的贷款最小值被重写
ignore_synchronous_response 肯定JGroups线程是否在流程控制阻塞的状况下携带消息到应用，禁止携带可能会致使大量的锁现象发生，因此咱们推荐此属性的值为true

1.7 分裂协议

当一个消息的大小大于某一肯定的值时，分裂协议将消息分裂成多个小消息，而后进行发送；而在接收端，一样分裂协议将分裂的消息进行重组。无论多播仍是单播发送消息，分裂协议均可以起做用。分裂协议是JGroups <config>中的一个元素（FRAG2），以下为一配置示例。

<FRAG2 frag_size="60000"/>

FRAG2协议的可配置属性以下：

frag_size 肯定消息被分裂协议分裂的临界点（字节），即如上配置，当要发送的消息大于60000字节时，消息被分裂。若是JGroups协议栈配置UDP做为底层的传输协议，则这个属性的值必须小于64000字节（64KB），由于UDP容许的传输的最大数据包为64000字节（64KB）。若是JGroups协议栈配置TCP做为底层的传输协议，这个属性的值必须小于流量控制协议的max_credits属性定义的字节大小

1.8 状态交换协议

状态交换协议负责从已经存在的节点（集群协调者）交换状态到新加入的节点。状态交换协议也是JGroups 配置<config>中的一个元素（pbcast.STATE_TRANSFER），状态交换协议没有任何可配置的属性，以下为一配置示例。

<pbcast.STATE_TRANSFER/>

1.9 分布式垃圾回收协议

在JGroups中，全部节点必须保持已经接收到的消息以防止错误所须要的消息重传。可是若是咱们永远保存接收到的消息，则咱们会面临内存溢出的问题。分布式垃圾回收协议负责周期性的释放全部节点上已经被全部节点收到的消息，从而达到回收各个节点上内存的目的。分布式垃圾回收协议也是JGroups 配置<config>中的一个元素（pbcast.STABLE），以下为一配置示例。

<pbcast.STABLE stability_delay="1000"
desired_avg_gossip="5000"
max_bytes="400000"/>

pbcast.STABLE协议的可配置属性以下：

desired_avg_gossip 肯定分布式垃圾回收的时间间隔（毫秒）。若是此属性的值为0，则禁止分布式垃圾回收机制
max_bytes 肯定激活分布式垃圾回收的最大接收消息的字节数。若是此属性值设为0则禁止此功能。若是集群消息交换比较频繁则此属性的设置是很是有必要的
stability_delay 肯定集群中节点在垃圾回收结束以前发送STABILITY消息的随即推迟的时间间隔（毫秒）。若是与max_bytes属性同时使用，则该属性应设定一个较小的值

1.10 合并协议

若是网络异常发生，集群可能被分割成多个区域而造成多个集群（多个协调者）。合并协议负责将分割成的多个区域从新合并成一个集群（经过多个协调者之间的沟通）。合并协议是JGroups 配置<config>中的一个元素（MERGE2），以下为一配置示例。

<MERGE2 max_interval="10000"
min_interval="2000"/>

MERGE2协议的可配置属性以下：

max_interval肯定等待发生合并消息的最大时间（毫秒）
min_interval肯定等待发生合并消息的最小时间（毫秒）

JGroups选择max_interval与min_interval之间的一个随机值周期性的发送合并消息。

- See more at: https://developer.jboss.org/wiki/BelaBansJGroupsManualTranslationSerialIV-#sthash.jFCo1Q1A.dpuf