本章节描述了weblogic集群如何使用IP套接字和IP单播或组播进行通信的。
Weblogic集群中服务实例之间的通信主要使用下面两种网络策略:
- IP单播或多播,服务器实例使用该技术来广播服务和心跳(表明持续的可用性)的可用性。
- IP套接字,这是群集服务器实例之间进行P2P通信的管道。
本章节主要包含以下部分:
3.1 选择weblogic集群通信协议
3.2 使用IP套接字端到端的通信
3.3 通过套接口进行的客户端通信
3.4 集群范围内的JNDI命名规范
3.1 选择weblogic集群通信协议
Weblogic服务器支持两种消息传输协议:
多播:基于UDP协议,从weblogic4.0版本开始支持。
单播:依赖于端到端的TCP/IP协议,从weblogic10.0版本开始支持。
3.1.1 使用IP多播
3.1.2 基于单播的一对多通信
3.1.3 选择单播或者多播方式通信的考虑因素
3.1.1使用IP多播
IP 多播是一种简单的广播技术,使多个应用程序能够“订阅”某个给定的 IP 地址和端口号,并监听消息。多播地址是一个介于 224.0.0.0 到 239.255.255.255 之间的 IP 地址。
注意:WebLogic Server 使用的默认多播值为 239.192.0.0。不应使用 x.0.0.1 范围内的多播地址。多播端口使用普通的UDP端口(0-65535),有一些端口被保留应避免使用。
IP 多播向应用程序广播消息,但是不能保证这些消息真正被接收到。如果应用程序的本地多播缓冲区已满,则新的多播消息则无法写入该缓冲区,当消息被“丢弃” 时,也不会通知该应用程序。因为此限制,所以 WebLogic Server 实例允许存在偶尔丢失通过 IP 多播广播的消息的可能性。
Weblogic多播基于标准的UDP多播向群组发送消息。因为UDP是不可靠的传输协议,weblogic服务器建立了自己的可靠的消息传输机制来监测和重传丢失的消息。
大多数的操作系统和交换机默认支持同一子网下的机器的UDP多播通信,然而多数的路由器默认是不支持的。在不支持UDP多播的环境中,UDP多播启用TTL机制。每次消息抵达一个路由器,它的TTL值就会减一。当TTL值达到0,说明消息不能在网络之间传播,这样可以有效的控制UDP多播消息传输的范围。默认,weblogic服务器为它的集群多播消息的TTL值设为1,限制消息在当前的子网中。
当使用多播的时候,集群的心跳机制会移除那些连续三次没有心跳消息的服务实例,默认的心跳消息发送频率为10s每次,这意味着30s没有发送心跳消息的话,服务实例被视为离开了集群。套接字监测机制或失败的连接也能监测并缩短这个时间。
总之,weblogic的多播传送机制:
- 使用非常高效的,可扩展的对等网络模型,服务实例直接发送消息到网络中,网络确保每一个集群中的实例能直接接收到消息。
- 多数的环境中,集群的成员在一个子网中。
- 如果应用到跨子网的环境中,需要更多的针对路由器和服务器的设置。
- 服务实例如果连续三次不能收到另一实例的心跳消息便从自己的实例列表中移除该实例。
Weblogic服务器提供了Java命令行,MulticastTest,来测试环境是否支持weblogic服务多播协议。
WebLogic Server 对于群集中服务器实例之间的所有一对多通信均使用 IP 多播。此类通信包括:
-
群集范围的 JNDI 更新 - 群集中的每个 WebLogic Server 实例均使用多播来公告本地部署或本地删除的群集对象的可用性。群集中的每个服务器实例都监视这些公告,并更新其本地 JNDI 树以反映群集对象的当前部署。有关详细信息,请参阅群集范围的 JNDI命名服务。
-
群集心跳 - 群集中的每个 WebLogic Server 实例均使用多播来广播通告其可用性的规律的“心跳”信号。群集中的服务器实例通过监视心跳信号来确定某个服务器实例的失效时间。(群集服务器实例也会监视 IP 套接口,以此作为确定服务器实例失败时间的一种更为即时的方法。)