JGroup功能十分強大，通過配置各種參數就可以充分利用它所提供的各項功能。JGroup最大的特點就是支持協議棧的可配置性，它本是實現了基本的Java的協議棧實現，也就是最基本的消息廣播的基礎，同時支持附加協議棧的配置，消息的傳遞就是在這些協議棧之間相互傳遞，封裝，檢查，丟棄，重發。JGroup可以基於TCP協議來實現消息廣播，也可以通過UDP方式來廣播消息，利弊不言而喻，TCP可靠，但是代價大，性能沒有UDP來的好，UDP速度快，代價小，但是消息的丟失率以及無序性有着很大的限制。但是JGroup在UDP方式的基礎上，增加了協議棧的配置，通過配置上層的協議，可以保證消息的重發，大包體的分解（同時保證消息包體順序），組內機器的狀態檢測等功能。
這裏大致描述一下使用中的配置參數的內容，可以在配置中正確合理的配置好JGroup的功能，使之在分佈式環境中起到最合適的作用。
當我們啓動一個JGroup的組的時候，其實建立了一個通道，可以通過配置文件爲這個通道配置相應的協議棧，那麼在這個通道上傳遞的消息也就會在配置的協議棧中傳遞交互。但是配置多協議的時候也需要注意，當配置的協議越多，那麼功能也越強大，支持的傳輸特性也越多，但是其損失的可能就是性能，所以和平時的網絡編程一樣，UDP和TCP各有優缺點，只是根據使用的場景需求不同來合理的使用不同的協議棧疊加，達到最佳的效果。
先貼一段JGroup的範例配置：
"UDP(mcast_addr=224.0.0.35;mcast_port=45566;ip_ttl=32;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(timeout=2000;num_initial_members=3):" +
"MERGE2(min_interval=5000;max_interval=10000):" +
"FD_SOCK:" +
"VERIFY_SUSPECT(timeout=1500):" +
"pbcast.STABLE(desired_avg_gossip=20000):" +
"pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" +
"UNICAST(timeout=5000;min_wait_time=2000):" +
"FRAG(frag_size=4096;down_thread=false;up_thread=false):" +
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" +
"shun=false;print_local_addr=true)"
UDP：使用IP多波協議來廣播組內消息並且使用的是UDP包作爲消息發送給獨立的Member。
PING：是用多波協議來查找初始化的在線Member。
MERGE2：允許將子組合併到一個組。
FD_SOCK：基於Socket的錯誤檢測（通過Member之間的環形檢測來實現）。當發現有member失敗就產生消息通知。
VERIFY_SUSPECT：雙重檢測member是否確實Dead，多了Suspect的狀態。
Pbcast.STABLE：刪除被全部member查看到的消息（作用就是如果在分佈式的情況下，其中某些member沒有看到，那麼這條消息就不會被刪除，會重發，保證消息廣播的全局性）
Pbcast.NAKACK：保證消息的可靠性和FIFO（消息的順序傳遞）。
UNICAST：類似於NAKACK的功能。
FRAG：大消息的拆分和組裝。
Pbcast.GMS：組成員協議，響應加入離開組的消息以及新建view的消息。
UDP配置：
UDP廣播模式可以配置成兩種方式：使用UDP和常規IP多波傳輸。配置類似於範例中的配置。所有的組內成員都運行在一個host上，分佈在一個LAN內。但是這個需要確認的就是IP的多波傳遞是否允許穿越多個子網，通常情況下是不允許穿越多個子網的，因此就需要確保多個組內的member在一個局域網中，並且可以相互間通信。
另一種模式就是使用UDP但是不使用IP多波傳遞。UDP和PING的配置都是基於IP的多波傳遞的，因此消息傳遞以及組內成員的初始化檢測都是要依靠於IP多波。因此這裏提供了另外一種方式就是設定一個每一個member都能夠訪問到的機器，在這臺機器上面設置一個GossipRouter，類似於路由一樣，每一個member的註冊都直接在這臺機器上的服務上管理。
需要配置的就是設置ip_mcast爲false。同時需要配置gossip_host gossip_port gossip_refresh這三個參數（地址，端口，刷新一次GossipRouter的時間）。
然後就在那臺服務器上運行GossipRouter程序：
java org.jgroups.stack.GossipRouter -port 5555 -bindaddress localhost
配置如下：
"UDP(ip_mcast=false;mcast_addr=224.0.0.35;mcast_port=45566;ip_ttl=32;" +
"mcast_send_buf_size=150000;mcast_recv_buf_size=80000):" +
"PING(gossip_host=localhost;gossip_port=5555;gossip_refresh=15000;" +
"timeout=2000;num_initial_members=3):" +
當如果需要在WAN中使用JGroup的時候就需要配置TCP來替換UDP了。
"TCP(start_port=7800):" +
"TCPPING(initial_hosts=localhost[7800];port_range=5;timeout=
"num_initial_members=3;up_thread=true;down_thread=true):" +
"VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):"
"pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_
"pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_
"pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;"
"print_local_addr=false;down_thread=true;up_thread=true)";
FD 協議棧（Failure Detection）
FD的作用就是探測組內的成員是否還活着。當組內的成員被懷疑可能死掉了，那麼SUSPECT消息就會傳播到集羣的每一個節點上。不過這個協議沒有將crashed的member踢出去的功能，這個工作由GMS來做，它只是通知的功能。
FD是基於心跳消息檢測來實現的，如果回覆消息在timeout的規定時間內沒有收到，那麼就會宣佈那個node被suspected，然後會被GMS給踢出去。一共三個參數作爲配置項：
Timeout,max_tries,shun。前面兩個不說了，最後一個十分重要。例如：一個組內有a,b,c,d四個成員，當d由於負荷過高沒有在timeout的時間內作出響應，導致被踢出組的時候，a,b,c的組員view中只有abc三個member，而d的view卻還有abcd四個成員，此時如果D再發消息給組內的成員，組內成員將會拒絕接受。那麼如果設置shun爲true的時候，D就重新加入組內在下面兩種情況：1.ABC接受到了D發過來的are-you-alive的檢測消息。2.D自己收到了一個view消息，view內不包含D。（類似於重連機制）。這點很重要特別是在分佈式的環境中，當某些服務器的壓力可能較高，配置的超時時間又不確定是否可以滿足高負荷響應。記得要在GMS裏面的shun也配置一樣的情況。
FD_ALL也是基於簡單的心跳協議，只不過是每個節點會向每一個member週期的發送心跳包，同時將會保存每個member的狀態表。
FD_SOCK是基於環形的TCP Socket互聯，相互監測來實現FD的功能的，每一個member都有自己的鄰居，使得member組成一個環形的校驗鏈。但是有幾個缺點，第一當使用多網卡機器的時候，2.2.8以前的版本就可能造成隨機綁定ip的問題，以後可以指定bind_addr這個參數，明確鄰居的ip。另外的缺點也就是我們在實施過程中發現的問題，由於TCP的異常產生未必都能被檢測到，同時例如網絡問題等因素，往往這種FD很難保證真實的掛起出錯的node，加之他是ring的檢測方式，會導致明明某個member已經dead了，但是由於沒有檢測到，導致後面再加入的member或者自己重啓，都無法正常使JGroup正常工作，不斷地在重複join/leave的操作。（所以不建議使用這種模式）
Group Membership
他關注新member的加入，member離開的請求，處理crashed的member suspect消息等操作。