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"/>

相關MPING屬性元素列表：

timeout 肯定初始成員列表時等待任意返回的最大時間（毫秒）。默認值爲3000
num_initial_members肯定要等待返回相應的最小成員個數，直到timeout發生，該屬性的默認值爲2
bind_addr 肯定發送和接收多播消息的地址，JGroups默認使用系統參數jgroups.bind_addr來確實該屬性的值
bind_to_all_interfaces 重寫bind_addr屬性，若是多個多播地址存在，咱們則使用多個多播地址
mcast_addr，mcast_port， ip_ttl 這些屬性與UDP協議中的描述相同

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"/>

相關FD屬性元素列表以下：

timeout 肯定等待接收心跳消息返回的最大時間（毫秒），該屬性的默認值爲3000
max_tries 肯定等待超時重發心跳消息的次數，重發max_tries次數後若是還不能收到心跳消息的返回，則認爲該節點發生異常，發送SUSPECT消息給集羣，該屬性的默認值爲2
shun 肯定發送錯誤的節點在從新加入集羣以前是否能夠向集羣發送消息。發生異常的節點須要經過發現協議從新加入集羣，JGroups有這樣的功能，即發送錯誤的節點從新獲取集羣狀態加入集羣

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屬性同時使用，則該屬性應設定一個較小的值