CN1552020A - 用于在集群式消息传递服务器中在节点故障以及网络划分期间确保操作的方法 - Google Patents
用于在集群式消息传递服务器中在节点故障以及网络划分期间确保操作的方法 Download PDFInfo
- Publication number
- CN1552020A CN1552020A CNA028174275A CN02817427A CN1552020A CN 1552020 A CN1552020 A CN 1552020A CN A028174275 A CNA028174275 A CN A028174275A CN 02817427 A CN02817427 A CN 02817427A CN 1552020 A CN1552020 A CN 1552020A
- Authority
- CN
- China
- Prior art keywords
- message
- state
- message manager
- node
- cluster
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Abstract
一种用于在包括集群的个体计算机由网络分区分隔开时,保证由集群式消息服务器的JMS语义规定的正确行为的装置。集群式消息服务器负责不同的分布式计算机应用之间的消息的可靠传输。它采用多个计算机来执行好象还可以由运行在一个计算机上的单个服务器来执行的功能,但是具有比一个计算机提供更大的容量和可靠性。如果集群中的计算机故障,那么另一个计算机将自动地承担已故障的计算机的角色。然而,对于集群中的其他机器来说,不可能检测出集群中一个或多个计算机的故障以及与那些计算机连接的数据网络的故障之间的差异。在普通的集群中,在这两种情况下将需要不同的动作,但是由于它们无法辨别,所以计算机故障始终被假定,并且网络故障被忽视并且后果不可确定。这里描述的本发明提供了一种响应故障的装置,不管所述故障起因于计算机故障还是网络故障,该装置都可以产生JMS语义所规定正确行为。
Description
发明领域
本发明涉及用于经由消息服务器、在计算机程序之间传送消息的方法以及系统的领域。更具体地说,本发明属于面向消息的中间件(MOM)的领域。
发明背景
MOM能够使多个计算机程序在通信网络之上彼此交换离散消息。MOM具有消息生产者以及消息消费者的“松耦合”特性,因为消息的生产者无须知道关于消息消费者的身份、位置或者数目。此外,当采用中间消息服务器时,即使当消息的最终消费者在消息被产生时是不可用的,也能够确保消息的发送。这能够与面向连接的中间件形成对照,所述面向连接的中间件需要计算机程序具有另一个计算机的身份以及网络位置的细节,以便在与其交换数据之前,能够建立与该计算机的连接。为了建立连接,在所述连接活动的整个期间,两个计算机必须是可用的并且要作出响应。
本发明尤其涉及这样一种情况,其中采用中间消息服务器来存储消息,并且向消费者分发消息。虽然当经由MOM进行通信时、所述生产者以及消费者(统称为客户端)是彼此松耦合的,但是通常要求中间消息服务器以面向连接的方式与这些客户端通信。由此在发送方和接收方不同时都处于可用的情况下,允许发送方和接收方进行通信需要服务器始终是可用的。此外,将可能希望交换消息的所有客户端必须连接到同一服务器,或者连接到不同的服务器,其中所述不同的服务器要有能力或者能够合作来实现单个服务器的等效功能,也就是说作为单个逻辑服务器。往往将MOM用于其中很多服务器必须充当一个逻辑服务器的系统,作为采用MOM的一个理由是:能够由此减少定义哪些程序可能彼此交换数据的必要条件。这意味着为遍及组织所分发的计算机应用程序而使用MOM的大型组织,或者使用MOM以在因特网上向公众提供服务的组织,必须准备容纳经由单个逻辑服务器而通信的成千上万的程序。
本发明尤其涉及将MOM服务器作为多个计算机集群来实现的情况。在此文献的上下文中,我们将集群定义为一组计算机,与使用单个计算机来实现的情况相比,所述计算机组可以相互协作,从而以更高的容量和更高的可靠性来提供单个服务。为了在集群中的一个或多个机器出现故障的情况下确保高可靠性,必须将由服务器保存的消息以及它们的相关联状态信息重复地存储在多台计算机上。这确保了如果一台计算机发生故障,所述集群仍旧能够使用上述数据。
本发明涉及使用主/备用式的重复存储的可靠集群。在这种情况下,对于由消息服务器集群执行的消息过程的一些子集来说,一台计算机充当主节点。所述主节点负责存储所述消息并且将它们主动地传送给消息消费者。一台或多台其他计算机充当相对于该主节点的备用节点。所述备用节点负责存储已存储在主节点上的数据的相同副本,但是它们不会主动地试图向消费者传送存储的消息。如果所述主节点发生故障,那么所述备用节点必须检测出此故障并且确保正确地将一个备用节点提升为主节点的角色,并且开始主动地向消费者传送消息。所述备用节点通过它们不再能够与主节点进行通信的事实,来识别主节点的故障。为了保证消息系统的正确行为,重要的是对于消息的特定子集来说,正确地一次让所述集群中的一个节点充当主节点。“正确行为”的正确含义将在下面描述。
除个别计算机的故障之外,在这种集群中可能发生的另一种故障是网络分区。术语“网络分区”指的是这样一种情况,其中将连接所述集群中的计算机的数据网络分成两个或更多独立的子网络。将这些独立的子网络中的每一个称为一个分区。除了这样一个事实,即处于该分区中的计算机无法与处于其他分区中的计算机通信之外,每个分区都正确地行使职责。网络分区的故障特征与节点故障的故障特征相同,也就是一台或多台计算机变得无法用来进行通信。为此,在通常情况下,对于备用节点来说,不能够区别其对应的主节点发生故障的事件和网络被分区并且所述对应的主节点继续行使职责但是它处于不同的分区中的事件。
以上这些问题在主/备用式服务器的可靠性方面产生了根本的困难。如果主节点通过网络分区与备用节点分离,但对应的备用节点假定它已经发生故障,那么备用节点就成为主节点。这导致了对于同一组消息来说,所述集群同时具有两个主节点。如果这两个主节点都与消息消费者联系,那么将不再能够保证所述消息服务器的正确行为。如果在另一方面,所述主节点发生故障,但所述对应的备用节点假定其处于不同的网络分区中,那么所述备用节点不会成为主节点,并且由于而后没有消息被传送,因此无法实现所述消息服务器集群的可靠性。
依照现有技术的消息服务器集群实现方式假定:不能与一台或多台计算机进行通信,就表明这些计算机已经发生故障。如果有人认为计算机故障比网络分区发生的更频繁,这是有道理的。在主/备用可靠性方案情况下,由于两台计算机能够同时成为同一组消息的主节点这样的事实,所以这在网络分区期间导致了不正确的系统行为。由于本发明提供了即便在网络分区期间,也能用于保证使用主/备用可靠性的集群消息系统的正确行为的装置,因此,本发明是独一无二的。本发明能够在无需发现通信失效是起因于计算机故障还是起因于网络分区的情况下执行上述内容。照此,本发明没有提供新的用于发现故障属性的装置,而是提供了一个用于提供主/备用式的高可用性的装置,所述高可用性也就是说由于该装置在不需要以不同的方法处理两种故障类型的情况下保证了正确的行为,所以是健壮的。
定义消息服务器集群必须展现的行为、以便被视为正确是十分重要的。本发明保证了消息传送系统的正确行为,所述正确行为如在由Sun微系统公司出版的Jave消息业务(JMS)应用编程接口(API)的说明书中,在1.0.2版本中定义的那样。这些接口的定义可以在http://java.sun.com/products/jms/docs.html上获得。这些行为的主要方面在于:
·确保消息发送:JMS定义了两个消息发送模式:持久的和不持久的。如果发生系统故障事件,可允许释放不持久的消息。然而,JMS适应的消息系统必须确保在系统发生故障之后、总是能够将持久的消息恢复,并且确保将持久的消息发送到预定的接收方。使用消息系统来利用持久的发送模式发送消息的计算机程序,不必使用额外的装置来确保将消息成功地发送到适当的接收方。本发明的一个目的在于:即使在网络分区使计算机分离的情况下,也能提供确保持久的消息发送,所述计算机包括消息服务器集群。(如果发生网络事件,本发明还防止不持久消息的丢失,即使这种丢失实际上是可允许的。)
·保证仅一次发送:JMS定义了两个消息范围:点到点和发布/预订。将点到点消息必须恰好被一次传送给一个恰好合格的接收方。这些通常对应于一些动作,诸如在银行帐户中存款,这些动作不允许执行一次以上。必须将发布/预订消息恰好一次传送到每个合格的用户。这种消息通常包含这样一种信息,其中该信息可能被传送给任意数目的接收方、但是必须恰好一次被传送到每个接收方。(在两个发送模式中,所述客户端具有选择权,以便规定允许对一个消费者进行重复发送)。如果消息消费者处理一条消息,然后在确认收到所述消息以前出乎意料地终止处理,那么依照JMS,将认为所述消息未送达。本发明的另一个目的在于:尽管存在网络分区,也能保证正确的点到点和正确的发布/预订消息的发送,所述网络分区使包括消息服务器集群的计算机分离开。
·按次序的消息发送:JMS消息系统的一个客户端也许具有多个生产者和消费者。将这些生产者和消费者分组到一次或多次会话,其中每次会话包含零个或多个生产者以及零个或多个消费者。必须将在一次会话内产生的所有消息、按与产生它们的顺序相同的顺序传送到消费者。所述JMS规范显示地标识出故障条件,其中不可能即保证确保发送又保证按次序发送:当将消息传送到消费者时,并且该消费者在确认收到消息以前发生故障,而随后已经将在同一会话中产生的消息传送给其他消费者。在这种情况下,尽管不按顺序,也仍可允许将关注的消息传送给另一消费者。
·事务:正如在前述几点中提到的那样,可以将一个客户端的任意数目的生产者以及消费者分组到一次会话。每次会话可以有选择性的被规定为“提事务”。所述客户端必须命令提事务的会话提交所有的消息,这些消息是从它们发送生效之前上一次提交以来所产生以及消费的消息。在连续的提交之间发生的消息的所有生产以及消费,必须以单个单元来继续或者中止。这意味着无论可能发生任何系统故障,对于在两个连续的提交之间、在一个提事务的会话内产生以及消费的消息组来说,都仅仅存在两个允许的结果:1)在提交的时候,所述消息系统核实所有已接收消息的消费,并且在提交时,所生成的消息变成可用来传送给消费者,或者2)中断所有已产生的消息,并且拒绝所有已消费的消息,有效地使所述会话回滚到它所处在的紧接着上一次提交之后的状态。由此,如果在同一事务内发布两个消息,一个消息命令从银行帐户取出款项,而另一个消息命令将同样数量的款项存入另一银行帐户,那么在相应的存款不发生的情况下,永不可能发生取款。由此,本发明的另一个目的在于提供正确的事务语义,而不管在成功进行事务以前是否会发生网络分区。
除上述之外,我们还希望本发明提供一个其他方面的行为,所述其他方面的行为不是JMS规定的,但是对于满足消息系统的基本目的是至关重要的。
所述消息传送系统总是可用来从消息生产者接收消息:JMS没有显示地说明涉及消息传送系统可用性的任何需求。然而,基于服务器的消息传送系统意欲减少需要实现存储转发消息传送功能本身的计算机程序。在不提供一些可用性保证的情况下,消息传送系统无法满足此意图。此外,在可用来将消息分发给消费者这方面,能够始终从生产者那里接收消息是尤为重要的。总的来说,所述JMS规范以及消息传送系统没有保证从生产者到消费者的最小传送时间。因为其无法假设消费者始终能够接收消息,所以这在消息传送系统的控制之外。为此,必须以下述方式来设计消息消费者,所述方式为:相对于消息发送中的延迟,它们是健壮的。另一方面,假定有一种简单的消息生产者,从人类用户交互地收集订购信息,将所述信息打包成为消息,将所述消息发送到消息传送系统,向用户确认订单已经发送,然后才准备处理另一个命令。如果所述消息传送系统在此周期期间不准备对所述消息负责,那么要么:1)在他收到订单被订购的确认之前,所述用户必须等待不定量的时间,直到所述消息传送系统可用为止,要么2)所述消息生产者必须提供所述消息的可靠的、可恢复的存储器,直到所述消息传送系统可用为止。这两种选择打消了以这种方案使用消息传送系统的意图。因此,我们认为能够在任何时候接收所产生的消息的能力,是对消息服务器的可用性的最高可用性标准。由此,本发明的又一个目的在于:即使当所述集群受到网络分区时,也能确保集群式消息服务器始终总是可以用来接收来自于消息生产者的消息,并且保证那些消息的正确发送。
本发明提供了针对网络划分的健壮性,特别针对在09/750,009号专利申请“Scaleable Message System”中所描述的集群式消息服务器。关于这一消息传送系统的细节,涉及此申请的公开内容,在此引入这篇申请,以供参考。这里仅仅提供简短的描述。在图1中描述了可扩展的消息系统。所述可扩展的消息系统包括两个或多个逻辑节点。每个节点都可以在独立的计算机上运行,或者可以在同一计算机上运行多个节点。存在两种节点:客户端管理器(CM)和消息管理器(MM)。消息管理器节点负责存储和分发消息。它们不能够直接地由客户端访问。客户端必须与客户端管理器节点连接,并且所述客户端管理器节点经由可靠的、原子多点通信消息总线、将客户端请求中继到消息管理器节点。所述消息总线允许同时将数据从一个节点发送到几个其他节点,而不会比要求将相同的数据只发送到单个单元时所消耗的网络资源多。个别的客户端管理器节点不包含状态信息,所述状态信息是继续系统功能的关键,因此能够容许一个或多个客户端管理器节点的故障,而不需要备用节点。如果客户端管理器节点故障,那么与其相连的客户端自动地重新连接到另一个客户端管理器节点,并且继续正常运行。图1示出了一群互连的客户端管理器以及消息管理器。
消息管理器节点包含状态信息,所述状态信息是继续系统功能的关键。为此,必须将它们的状态信息重复地存储在多个节点上。存在两种消息管理器节点:主的和备用的。在任一时刻,每个主消息管理器节点负责存储以及分发消息的子集,其中所述消息由消息传送系统传输。同时,在任一时刻,所有的主消息管理器节点负责完整的消息组,其中所述消息组由消息传送系统传输。对于每个主消息管理器来说,存在许多备用消息管理器节点。每个备用消息管理器节点负责维护其对应的主消息管理器节点的状态的确切副本,并且如果原来的主消息管理器发生故障,那么它必须随时可以承担主消息管理器的角色。每个主消息管理器节点与其对应的备用消息管理器节点紧密地相互作用,但是很少与其他消息管理器节点相互作用。为此,将一个主消息管理器节点及其对应的备用消息管理器节点的每个组称为子集群。
上述的消息服务器集群由两个不同类型的节点组成,并且因将这些节点定位在不同的物理计算机上,而具有一些优点。重要的是要注意,能否通过将客户端管理器和消息管理器的功能组合为单个节点类型、并利用单个类型的节点来实现这类消息服务器集群。然而,我们有能力说明本发明通过使用这样一种模式而得以简化,在所述模式中,这些节点类型是物理上独立的,并且此模式将贯穿此文献而使用。
本发明大大地减轻了同步网络视图的概念。所述视图是机器列表,利用所述机器列表,特定的节点能够在某一个时间点、在数据网络上通信。本发明假定处于特定节点的视图中的所有节点自身拥有相同的视图;也就是说:如果A处于B的视图中并且C没有处于B的视图中,那么C就没有处于A的视图中。由此,当没有网络分区时,那么所有的节点使所有其他的节点拥有它们的视图,并且当所述网络被分区时,那么在一个分区中的所有节点拥有相同的视图,并且所述视图不包含处于其他分区中的任何节点。在优选的实施例中,把检测所述视图并且报告视图中变化的职责委托给消息总线,所述消息总线在所述集群内提供多点传输。为了达到上述目的,所述优选的实施例使用了来自于Softwired AG(
www.softwired-inc.com)的产品iBus//TMessageBus,因为它既提供了可靠的、原子的、按次序的多点传输,又提供了视图管理。
发明概要
本发明提供了这样一种装置,该装置用于使集群式消息服务器从消息产生客户端接收消息,并且将这些消息例如以符合当前JMS规范版本条件的方式、分发到消息消费客户端,所述当前JMS规范版本诸如JMS规范版本1.0.2以及随后的版本,并且即使当集群中的计算机发生故障或者将连接集群中的计算机的数据网络分成多个网络分区时,也能确保所述集群高度可用来接收消息。
本发明例如适用于在美国第09/750,009号专利申请“ScaleableMessage System”中规定的、以及先前在背景部分中描述的消息服务器集群类型。09/750,009号美国专利申请更详细地描述了新型的消息服务器集群,并且将该篇申请在此引入,以供参考。因为可以将所有的消息以及相关联状态信息冗余地存储在多个不同的计算机上,所以认为此类型的消息服务器集群高度可用,其中所述服务器必须存储上述所有的消息以及相关联状态信息以便保证正确操作。如果集群中的一台或多台计算机出乎意料地发生故障,这允许消息服务器集群继续正常操作,而不会中断,并且不会丢失消息。
然而,本发明还可用于不同于上述09/750,009号美国专利申请的节点体系结构的消息集群系统。将依照本发明采用的集群的唯一先决条件就是提供多个消息管理器。所述消息管理器原则上还能够同时充当客户端管理器的来用。
对于点到点消息传送,所述规范的条件要求将每个持久的消息传送到合格的消息接收方中恰好一个。对于发布/预订通信,所述规范的条件要求将每个消息恰好一次传送给每个合格的预订者。这些必要条件暗含这样一些动作,所述动作对于在多个物理机器上的节点之间相互协调是耗费时间的。这些动作包括决定在点到点域内、哪个合格的接收方将接收消息,并且何时将消息传送给所有预订者,以及何时在发布/预订域内可以被安全地删除。为了以高效的方式执行这些动作,在任何给定的时间,在集群中只有一个消息管理器节点得负责任来发送特定消息。将其指定为主消息管理器节点。存储该消息的所有其他消息管理器节点是备用消息管理器,并且扮演被动角色。对于特定的消息组来说,在任一时刻,当只有一个主消息管理器存在时,能够确保正确的系统行为。由此,备用消息管理器只应当在它已经确定当前不存在主消息管理器之后,才成为主消息管理器。
此主/备用方案无法确保当将连接所述计算机的网络进行分区时,只存在单一的主消息管理器。此事实的结果是:分区的计算机无法得知它们已经失去联系的计算机是否已经停止操作,或者它们是否在另一个网络分区中继续操作。本发明提供了这样一种方案,其中每个网络分区可以包含相同消息组的主消息管理器,而不会违反JMS规范的条件,并且不防碍客户端向消息服务器集群发送新消息。
为了允许每个网络分区让负责相同组的点到点消息的主消息管理器作为其他分区中的主消息管理器,我们为点到点域定义了两种主消息管理器:正常的和受限的。允许正常的主消息管理器执行与点到点消息的主消息管理器相关联的整套的功能。不允许受限主消息管理器分派在网络故障开始之前发送的点到点消息。这样做足以确保在集群中存在不止一个的正常(非受限的)主消息管理器,以便保证点到点域中的正确的JMS语义。
在所述发布/预订域中,不必限制任何主来传送消息。然而,需要确保不会将发布/预订消息从所述消息管理器中删除(除非因为消息期满),直到所述网络分区或者计算机故障被纠正,以便确保在其他分区中可能的消费客户端最终可以接收打算送给它们的所有消息。在此操作模式中,所述主消息管理器必须保留所有的发布/预订消息以及它们的关联发送状态,并且将所述主消息管理器称为保留主消息管理器。注意,当一个分区使消息管理器从相同的子集群中独立出来的任何时候,来自于该子集群的所有主消息管理器开始保留发布/预订消息,同时最多一个消息管理器可以成为点到点消息的正常主消息管理器。
在纠正了网络分区之后,先前在不同的分区中独立的多个主消息管理器必须使它们的状态同步,以便使所有的主消息管理器都被更新,以反映其他分区中发生的活动。然后,除主消息管理器外的其他所有消息管理器必须恢复成备用节点,并且所述单个保留的主消息管理器承担该子集群的消息的全部责任。
为了可靠地确定何时发生故障,以及确定特定分区中的主消息管理器可以具有什么样的功能级别(正常的、保留或者保留/受限),以下信息必须可以被所有节点使用:
·集群结构:这是由系统管理员所定义的集群的结构。它包含对以下内容的完整说明,所述内容为:什么节点应该存在、它们是什么类型(客户端管理器或者消息管理器)、它们如何分组成子集群,以及它们应该在哪些计算机上运行。这通常对所有节点始终是一样的。
·网络视图(视图):这是计算机的列表,所述计算机可以经由多点传送消息总线获得。当没有故障时,所有的计算机共享相同视图,并且这应该与集群结构一致。当发生故障时,那么所述视图将会与所述集群结构不一致。如果所述故障起因于网络分区,那么每个分区中的计算机将共享相同视图,但是所述视图自然在每个分区中是不同的。
本发明使用一离散状态模式来确定特别的子集群中的主消息管理器是否将是保留和/或受限的。此分区状态具有四个可能的值,这些值以字母A、B、C和D来表示。每当发生视图改变时,根据新的网络中的客户端管理器和消息管理器的数目和在前分区状态、以及预定的集群结构来重新评估节点状态。状态A表示没有故障或者只有客户端管理器故障的正常操作。在状态B和C中,所述主消息管理器是保留的而不是受限的。在状态D中,所述主消息管理器是受限的并且保留的。即使当发生多个连续的复合网络分区时,所述状态模式也能允许高度的连续操作并且允许保证JMS一致性。
对于发布/预订消息来说,保留主节点将行使与正常主节点相同的职责。唯一的差异在于:保留主节点无法得知是否存在还没有接收特定消息的处于其他分区中的预订者,所以它不应该删除消息,直到纠正了所述故障,并且该子集群的所有主节点能够与它们的状态一致,除非出现纠正故障以前、消息期满的情况。
对于点到点消息来说,与非受限的主节点相比,受限主节点在允许其执行的动作方面更加受到限制。受限主节点可以随时接受输入消息。受限主节点只分发在最近的视图改变之后接收的消息,这是因为能够保证这些消息不会存在于任何其他分区。由于必须将通过单次会话产生的所有消息按次序传送,所以将由当前视图中的目的地收到的消息、排在来自于在前视图期间接收的相同客户端会话的消息后面是可能的,并且由此不用于分发,直到纠正了分区。
本发明假设在故障发生之后没有立即发出视图改变事件。在视图管理器(在优选实现方式的情况下是多点传送消息总线)能够最后地确定故障已经发生、而不会冒过多的假警报的风险以前,通常存在一些时间延迟。在发生网络分区之后,能够使每个分区在不同的时间检测所述故障。这能够导致这样一种危险的情况,在其他分区中的主消息管理器检测其必须开始受限操作以前,其中一个分区将备用消息管理器提升为非受限的主消息管理器。
为了避免在发生故障和视图改变之间的间隔期间重复发送消息,在消息分派期间,由客户端管理器执行额外的校验。每当为了分派而将消息从消息管理器发送到客户端管理器时,接收该消息的每个客户端管理器都向所有其他客户端管理器发送确认,以证实它已经看到了该消息。实际上负责将消息转发到客户端消费者的一个客户端管理器将保留所述消息,直到接收到来自于相同网络视图中的大多数其他客户端管理器的确认。如果已经发生故障,所述故障在报告对应的视图改变以前可能会导致重复发送消息,那么就无法接收大多数的确认,并且客户端管理器将拒绝所述消息。
总的来说,本发明的重要的思想在于:在网络分区的情况中,每个节点评估一个分区状态信息。首先,两个操作状态之间的重要的区别是受限的和非受限的。必需弄清楚的是,两个消息管理器无法分派相同的点到点消息。由此,建立了确保两个消息管理器不会彼此“看到”的标准,即因为缺少(硬件或者软件)网络连接而无法通信,并且只有当其中一个消息管理器处于非受限的状态时,才能负责分派相同的点到点消息。只有处于非受限的状态中的消息管理器才能分派在发生网络分区之前创建的消息。
建立用于确定消息管理器是将被设置为受限的、还是非受限的类别的标准,即处于受限还是非受限的操作状态,存在不同的可能性。依照上述的、并且下面要更详细地描述的四个状态模式,所述标准为:消息管理器必须具有将要处于非受限状态的分区状态A、B或者C。服务器属于分区状态A、B还是C,要取决于可用于通信的节点的数目和种类,以及历史记录,也就是说,在所述历史记录上有上次视图状态改变之前的分区状态。
这四个状态模式或者其简化的甚至更成熟的版本,可以适用于具有两个不同种类的节点——消息管理器和客户端管理器的体系结构,这两个种类在上述美国专利申请中公开,以及例如适用于其中每个服务器既充当客户端管理器又充当消息管理器的常规类别的体系结构。还可能的标准例如是标明一个服务器节点将成为特定(阿尔法或者“中介层(tie-breaker)”)服务器。阿尔法服务器的分区中包含的所有服务器是非受限的,而所有其他的服务器是受限的。另外的标准可以使用与特殊客户端连接等等有关的信息,然而,关键的是始终只有一个分区可以是非受限的。
第二,在保留和不保留的两个操作状态之间存在重要的区别。依照所述四个状态模式,如果消息管理器处于分区状态A,那么它处于不保留操作状态,否则它处于保留操作状态。依照此模式,如果在所述子集群内所有消息管理器都是可用的,并且如果至少一个客户端管理器是可用的,那么得到分区状态A。
依照一个特殊的实施例,可以有选择性地存在与可利用的消息服务器节点的数量有关的另外分区状态。此外,此实施例参照所提及的四个分区状态模式来解释。
本发明的动机在于:希望获得这样一种方法,该方法在发生网络分区或者节点故障事件能够保证JMS语义,其中这两种时间无法由集群的服务器来区别。然而,如果发生网络采用不同的中间件、特别是面向消息的中间件时,本发明同样适合于保证正确操作。专家将立即了解的是:本发明的原理不以专用计算机软件或者计算机语言为基础,而是涉及照此的网络体系结构。
附图简述
图1示出了集群式信息传送系统。
图2举例说明了包括节点以及互连所述节点的单向顶点的分区状态转换图。
图3示出了发生网络分区之后的集群式消息传送系统。
图4举例说明了集群式消息传送系统中的简单事务的处理。
图5举例说明了随时间的事务的执行。
优选实施例说明
在下文中,将参考附图来描述本发明的优选实施例。
在图1中示出的集群包含两个子集群1和2,均包含三个消息管理器MM,以及五个客户端管理器CM。五个客户端管理器中的每个都具有多个客户端相连接。在每个子集群中有一个主消息管理器和两个备用消息管理器。所述附图示出了所述节点(客户端管理器和消息管理器)是如何在广域集群消息总线(cluster-wide message bus)上连接的。
依照图2中所示的模式,假设了由节点A、B、C、D表示的四个不同的状态。每个节点表示一个分区状态,并且为每个网络分区中的每个子集群独立地确定此分区状态。单向箭头表示产生从一个分区状态到另一分区状态的转换的事件。转换是作为视图改变事件的结果而发生的。以下将说明导致从一个分区状态到另一分区状态(或者相同的分区状态)的转换的每种事件:
·顶点aa——相同子集群中的所有消息管理器保持可用,并且一个或多个客户端管理器对于那些消息管理器是可用的。
·顶点ab——该子集群中的一个消息管理器以外的所有消息管理器已经成为不可用,而多数客户端管理器对保持消息管理器来说是可用的。
·顶点ba——相同子集群中的所有其他消息管理器已经成为可用的,并且一个或多个客户端管理器对于那些消息管理器是可用的。
·顶点bd——来自于相同子集群的具有当前分区状态D的一个或多个、而不是所有消息管理器,在此分区中都已经变为可用的,连同已经处于此分区中的、来自于此子集群的单个消息管理器(先前具有分区状态B)也变为可用,并且一个或多个所述客户端管理器对那些消息管理器来说是可用的。
·顶点bb——来自于此子集群(先前具有分区状态B)、也就是说已经处于此分区中的单个消息管理器保留为在此分区中可用的、来自于此子集群的唯一的消息管理器,并且一个或多个所述客户端管理器对于那个消息管理器来说是可用的。
·顶点ac——来自于该子集群的两个或更多、而不是所有消息管理器保持可用,并且大多数所述客户端管理器对于那些消息管理器来说是可用的。
·顶点ca——相同子集群中的所有其他消息管理器已经成为可用的,并且一个或多个客户端管理器对于那些消息管理器来说是可用的。
·顶点cb——所述子集群中的一个消息管理器以外的消息管理器已经成为不可用的,并且多数客户端管理器对所述保持消息管理器来说是可用的。
·顶点cc——来自于此子集群的两个或更多消息管理器保持可用,大多数客户端管理器对那些消息管理器来说保持可用,并且来自于此子集群的至少一个消息管理器保持可用。
·顶点cd——大多数客户端管理器已经成为可用的,并且来自于此子集群的至少一个消息管理器、或者其他消息管理器保持可用,但不是所有都可用。具有当前分区状态D的来自于相同子集群的消息管理器已经成为可用的。
·顶点ad——大多数客户端管理器已经成为不可用的,并且来自于此子集群的至少一个消息管理器已经成为可用的。
·顶点da——在所述子集群之内所有消息管理器是可用的,并且一个或多个客户端管理器对那些消息管理器来说是可用的。
·顶点dd——来自于此子集群的至少一个消息管理器保持可用。
正如从附图中看到的那样,包含正处于分区状态A、B或者C中的消息管理器和客户端管理器的分区,可以具有就点到点消息而言可以主消息管理器操作在非受限的模式下,并且它可以正常地分派点到点消息。另一方面,在分区状态D中,主消息管理器就点到点消息而言、以受限模式进行操作。就发布/预订消息而言,所述主消息管理器可以按不保留模式操作,并且可以在分区状态A中正常运转。在分区状态B、C和D中,所述主消息管理器可以按保留模式操作,并且在它们满期前不能删除消息。
对于每个网络分区来说,一个分区将移到分区状态B或者C,并且所以其他分区将移到分区状态D。为了移出分区状态D,在相同分区之内所有的消息管理器必须都是可用的。由此,只有一个分区可以随时具有分区状态B或者C。
依照本发明的另外的、简化的实施例,还可以采用三个状态模式,组合状态A、C和D。同上述模式类似,如果消息管理器处于分区状态A或者C,那么其属于非受限的操作状态,并且如果该消息管理器处于分区状态D,那么其属于受限状态的可操作状态。此外,如果所述消息管理器处于分区状态A中,那么其属于不保留操作状态,否则属于保留操作状态。依照这种简化模型,仅依靠可用于通信的节点的数目和种类,可以决定服务器属于哪个分区状态,而不必根据其“历史”来确定。
状态A:子集群中的所有的消息管理器都是可用的;
状态C:子集群中不是所有消息管理器都可用,而大多数客户端管理器是可用的;
状态D:子集群中不是所有消息管理器都可用,而大多数所述客户端管理器可用。
此外,此简化模型确保了JMS语义。然而,在比较过程中,所述四个状态模式包括更多情况(c.f.顶点bb),其中所述服务器属于非受限的操作状态。
四个状态模式的总体目的或者其更成熟或者更简单的变化在于:正确地处理多个连续的网络分区的情况。这可以是以下这些情况,即当缺乏经验的技术人员错误地试图修补所述主分区时,或者当网络交换中的固件独立于计算机疯狂地运行并且随机地启动时。所述状态模式提供非常高度的健壮性,并且防止所述系统在发生第一次分区之后变成彻底失效。
完全类似于图1中所示的集群,图3的集群包含两个子集群1和2,均包含三个消息管理器、以及五个客户端管理器。五个客户端管理器的每个都具有多个客户端相连接。
所述附图示出了网络分区如何以这样一种方式具有分区的子集群,在所述方式中,子集群1不受分区的影响,除了两个客户端管理器是不可用的事实。照此,处于子集群1中的节点仍将处于分区状态A。另一方面,子集群2已经以这样一种方式被分区,其中将所述主消息管理器远离其备用消息管理器来分区。原来的主消息管理器驻留在具有大多数客户端管理器的分区之内,但是其他两个消息管理器具有少数的客户端管理器。在缺少主消息管理器的情况下,原来具有两个备用消息管理器的子集群2的分区已经将其中一个备用消息管理器提升为主消息管理器。
然而,此新的主消息管理器将具有分区状态D并且由此是受限的并且是保留的。原来的主消息管理器处于分区状态B中,并且是保留的。
图4举例说明了集群消息传送系统中的简单事务的处理。正如可以看到的那样,一项事务横跨两个子集群,如灰色阴影所示出的那样,并且包括正被发送的消息以及正被接收的消息。
在图4中,与所述客户端管理器相连的客户端已经创建了一个提事务的会话。所述客户端管理器充当事务管理器。然后,所述客户端发送消息,该消息的目的地在子集群1中,并且所述客户端接收位于子集群2中的目的地上的消息。然后,所述客户端请求将要提交的事务,所述事务管理器在多点传送总线上多点传送该事务,并且返回该操作的结果。
图5举例说明了随时间的事务的执行。事务的消息包括自从上次中断/提交以来,在提事务的会话中发送并且接收的消息。正如可以从该图中看到的那样,所述事务包含三个消息操作——一个发送消息的操作、两个接收消息的操作——还包括提交操作。
本发明既不用防止节点故障和网络分区的发生,又不用校正节点故障。相反,本发明承认这些情况是有可能的,并且提出了即使在发生这种情况之后到将它们校正以前的这段时间,能够使所述集群仍能够保证JMS语义的解决方案。这是通过启动所有的客户端管理器和消息管理器来执行的,并且由此当集群(或者其分区)处于执行某一个操作可以导致JMS语义中断的状态时,整个分区用来检测以及识别。具体来讲,对于检测以及识别这种状态来说,每个节点能够推断在消息粒度上的给定操作是否会导致JMS语义被中断,并且由此来制止执行所述操作,直到它在语义上再次安全时才这样做。
当将所述集群同时分成许多网络分区时,本发明能够支持正确操作。然而,本发明假定以这样一种方式来配置所述集群,即其中所有的客户端管理器将永不会与所有的消息管理器分开。这样做的后果无非是所述集群将停止行使职责。这通过在相同机器上共同定位一些客户端管理器以及消息管理器能够易于得到保证。
本发明还支持子集群抽象,这意味着所述集群可以具有一个或多个子集群,它们均包含一个主消息管理器以及零个或多个备用消息管理器。每个子集群负责发送消息的不相交子集,如负载均衡逻辑所确定的那样。由于主消息管理器以及其所有的备用消息管理器位于单个子集群中,节点故障以及网络分区问题在每个子集群中分别地加以处理。不将对消息的响应传遍多个子集群、并且由消息管理器的单个集群处理所有消息的情况,是子集群抽象的一个特例,其中子集群的数目等于一。
最后,本发明还支持事务处理,也就是,多个消息操作(发送/接收)的原子执行,并且当执行事务时,甚至在节点故障以及网络分区期间,也能保证JMS语义。
本发明依赖于集群中的每个客户端管理器以及消息管理器能够通过保持不同的状态信息来检测并且识别集群(或者其分区)的状态。此状态信息用于给予每个节点有关集群预期的以及实际状态的知识,当发生潜在语义误差时,为了使那些节点知道,所述状态信息是一个重要的方面,并且由此能够使它们来防止JMS语义被中断。由依照本发明的客户端管理器以及消息管理器保持的状态是:
·配置状态——定义所述集群如何配置,也就是说,有多少客户端管理器以及消息管理器,并且有多少集合成的子集群,管理员已经配置了整个集群以使其具有这种结构。每当所述管理员向所述集群添加节点或者从所述集群去掉节点时,此状态改变。状态序列号标识所述状态——包含与所述客户端管理器、消息管理器以及它们集合成的一个或多个子集群有关的信息——每当更新所述状态时,将其增加。为了使集群中的节点正确地行使职责,它们必须具有配置状态的一致视图。
在节点故障和/或网络分区期间,通过允许管理员改变此状态,能够确保最高级别的灵活性,而且同时确保跨越节点的一致性,当改变状态时,使用了半数以上投票方法。只要至少半数以上节点可用,半数以上投票方法就允许管理员改变配置状态。当所述管理员改变配置状态时,不可用的节点将由此成为不一致的,并且当它们与其余的集群一致时将被更新。
·视图状态——定义从多点传送层下面看的所述集群的当前视图,也就是说,所述集群当前如何以客户端管理器和消息管理器出现,并且集合成子集群。与配置状态相比,每个节点的视图状态仅仅包含当前可经由多路传送层到达节点的那些节点。通过状态序列号可以标识所述状态,所述状态序列号表示包含与该视图中的客户端管理器、消息管理器以及集合成的子集群有关的信息的数据结构。作为两个分区,可以都具有相同的状态序列号,但是这两个状态的上下文关系不同,所述状态序列号不一对一地映射到数据结构。
对于所述集群来说,每当一个或多个节点成为可用或者不可用时,所述状态改变。照此,因为节点故障以及恢复、网络的分区以及复原、管理员向所述集群添加节点或从集群消除节点,也就是说,改变所述配置状态,所述视图会改变。
·分区状态——定义什么样的分区——给出所述集群/子集群当前如何依照与配置状态相比的视图状态出现——或者整个集群,如果没有故障发生的话,就消息处理而言允许这样做。如果没有故障发生,那么子集群中的所有节点具有相同的分区状态。就分区状态来说,在一些点上,可能在节点之间会出现不一致性,但是只要视图状态改变——那必将出现——触发,然后使节点同步,就可以解决。
其中,当配置状态和视图状态具有不定的状态序列号时,所述分区状态根据客户端管理器和消息管理器的数目来取得有限数值A、B、C或者D,其中所述客户端管理器和消息管理器是处于被比作为当前配置状态的视图状态中的。照此,通过由多路传送层改变视图状态来触发到分区状态的转换。
由于所述客户端管理器在多个子集群之间共享,并且所述客户端管理器必须知道给定的子集群的分区状态,所以这意味着所述客户端管理器将能保持多个分区状态——用于在当前视图状态中表示的每个子集群的分区状态。客户端管理器必须知道分区状态的理由是:必要时它们必须能够阻塞消息由特定子集群发送,如将稍后描述的那样。
·目的地状态——定义每个消息管理器中的每个目的地的内部状态,所述消息管理器包括当前存储在目的地的消息,并且具有它们的全球标识符、优先级、发送模式以及发行者,连同发送状态、锁、下标定义、个别的下标状态等等。目的地状态不具有标识序列号,而是由其表示上述信息的数据结构来限定的。
处于子集群中的节点在视图状态改变期间交换状态信息。利用这种方法,将状态冲突作为视图状态改变的一部分来检测,所述状态冲突是多个节点具有不同配置状态、视图状态、分区状态以及目的地状态的方案。如果检测到状态不一致,那么如稍后所描述的那样,通过使所述状态同步来解决。
在集群/子集群的使用期限内,其——其节点的——分区状态根据网络分区以及节点故障的频率、作为视图状态改变的一部分可以改变多次。本发明使用状态机方法来为分区状态定义可能的状态转换。图2示出了以节点表示的可能的分区状态,以及以顶点表示的它们之间可能的转换事件。所述转换图的起点是分区状态A,其中假设当系统启动时,所有的客户端管理器和消息管理器最初都是可用的。正如可以从图2看到的那样,包含正处于分区状态A中的消息管理器和客户端管理器的分区可以具有正常操作的主消息管理器。另一方面,在分区状态B、C和D中,主消息管理器无法正常地操作,这是因为:
·受限——就点到点消息而言,所述主消息管理器在它可以发送什么样的点到点消息方面受到限制。将主消息管理器在分区状态D中进行限制。
和/或
·保留——就发布/预订消息而言,所述主消息管理器必须保留发布/预订消息,否则,所述消息本已经被处理了。在分区状态B、D中保留主消息管理器。
稍后将说明限制和保留的语义。在所有状态转换期间,没有主消息管理器的任何分区将提升备用消息管理器作为新的——并且也许是受限/保留——主消息管理器,并且当进入分区状态D时,具有正常的主消息管理器的任何分区将被降至受限主消息管理器,并且当进入分区状态B、C或者D时,被降至保留主消息管理器。
从图2获悉的另一要点是:所述集群/子集群只得通过进入分区状态A才能离开分区状态D。当且仅当如在配置状态中定义的集群/子集群中的所有消息管理器是可用的时,这才能发生,意思是说,就可用的消息管理器而言,所述集群/子集群将从网络分区或节点故障中完全地恢复。按照这些状态所示,这意味着当就每个子集群组成的消息管理器而言、所述集群/子集群的当前视图状态与管理员设立时以及在配置状态中所表示的结构相同时。
此分区状态的分类意味着如果发生将网络分为两个分开的部分,那么一个部分必须处于分区状态D,并且其他部分必须处于分区状态B、C或者D。兼备分区状态B和C的理由在于:如果发生连续的网络分区时,可以防止不必要的限制。图3示出了利用注释的分区状态分区的集群/子集群的例子。
作为分区状态D中的受限/保留主消息管理器用于排队的含意以及主题目的地如下:
对于点到点目的地来说,它指的是限制受限主消息管理器发送消息,所述消息是在任何在前视图状态中已经接收的消息。相反,当它们是潜在的重复消息候选时,阻塞点到点消息。这样做的理由是:另一个正常的且由此是非受限的主消息管理器,可以在另一个网络分区中运转,并且可能或者未必发送候选消息。除阻塞在任何先前的视图状态中接收的点到点消息之外,受限主消息管理器继目的地上阻塞的消息之后还阻塞排队信息,如果它们来源于相同的会话。这样,消息的部分排序就得以确保。无法发送被阻塞的点到点消息,直到所述子集群以这样一种方式从网络分区或节点故障中恢复,所述方式为:它将处于分区状态A中。
如果主消息管理器仍然试图发送重复的排队信息候选者,那么因为在网络分区时状态不一致,所以由客户端管理器——负责将消息发送给客户端——将所述消息送回到消息管理器,并且发送回一个通知,通知所述主消息管理器应该停止发送来自于先前视图状态的消息。将所述消息送回的理由是:接收客户端管理器请求——作为校验以防止重复消息候选被发送的一部分——但是不接收来自于当前视图状态内的大多数其他客户端管理器的确认,其中所述当前视图状态允许它向客户端发送消息。它决不会接收来自于大多数客户端管理器的确认的理由是:最多一个分区可以包含没有处于状态D的消息管理器。如果随后将这个分区分开,那么这些后生的分区的最多一个可以包含大多数客户端管理器。
照此,如果此刻目的地及时发生网络分区,那么点到点目的地不包含将要处理的消息,“受限”主消息管理器在新视图状态中没有限制。由此,在这些条件下,受限主消息管理器可以继续正常操作,而不会中断JMS语义。
对于发布/预订目的地来说,由于在发布/预订范围中防止重复消息的观念没有意义,所以作为保留主消息管理器的含意是不同的。照此,对于发布/预订目的地来说,所述保留主消息管理器不阻塞任何消息。发布/预订目的地的语义的必要条件是:将已向目的地发布的消息全部传送给该目的地的所有预订者。一旦已经将发布/预订消息(耐久的或者不耐久的)传送到所有感兴趣的预订者,那么消息管理器就能因此移去所述消息。由于连接在一个分区上的客户端(预订者)因分区而无法接收在另一个分区上发布的消息,所以这在网络分区期间产生了一个问题。因此,不可能知道什么时候已经将特定发布/预订消息传送到集群中的所有预订者。为了解决这个问题,本发明建议停止处理除状态A以外的所有分区状态中的发布/预订消息,——只处理处于分区状态A中的发布/预订消息。相反,将发布/预订消息保持在目的地,直到所述网络分区已经以这样一种方式恢复,所述方式为:将整个集群后退到分区状态A。因为所有的主消息管理器无论它们的分区状态是什么样的、都由于网络分区而无法到达所有预订者,所以它们都是保留主消息管理器,这意味着它们必须保留发布/预订消息而不处理这些消息。此处理的一个例外涉及消息期满。在节点故障以及网络分区期间,本发明让消息期满优先于发送到所有的预订者,这符合JMS语义。
当校正网络分区时,将所述集群/子集群的分区合并在一起,并且由此分区状态转换作为视图状态改变的一部分发生。如果网络的另一个分区立即超过现存的网络分区,那么也发生分区状态转换。在两种方案中,所述节点也许具有不同的配置状态、分区状态以及视图状态,但是所述状态在分区内一致;在最小限度上,大多数节点在配置状态上是一致的。为了合并网络分区,新视图中的所有节点——分区的或未分区的集群/子集群——首先必须达成一致,并且将新视图状态序列号设定为在新视图中所发现的最高视图状态的序列号加1,并且相应地更新视图状态数据结构。
更新视图状态后,新视图中的每个节点交换它们在视图改变之前拥有的配置状态和分区状态,并且不管它们是否是主消息管理器。将此状态信息通过多点传送要由所有其他节点接收的消息来进行交换。在已经接收来自于新视图中的所有节点的此消息之后,每个节点使用以下规则来更新它们的状态信息,所述规则为:
·视图状态中的所有节点之间的最高配置状态序列号在较低的配置状态序列号之上。新视图中的节点——分区或非分区集群——采用所有节点之间的最高配置状态序列号,并且必要时,所述节点对应于新的配置状态更新它们的结构。
·使用其自身的当前分区状态以及被比作为新的配置状态的新视图状态,每个节点使用图2中所示的分区转换图来更新分区状态。这将使视图中的所有节点具有相同的分区状态。
在已经使这些状态同步后,所述消息管理器必须与受状态改变影响的每个子集群中的主消息管理器相一致。根据信息多点传送,每个消息管理器可以检测是否有其他消息管理器号称主消息管理器。如果子集群内没有消息管理器号称主消息管理器,那么具有最高等级的每个子集群中的消息管理器将自身提升为主消息管理器。另一方面,如果一个以上的消息管理器号称主消息管理器,那么除了具有最高等级的主消息管理器之外,所有的主消息管理器将它们自己降级为主消息管理器,其中所述等级由将所述消息管理器登记到集群中的顺序来表明。在此过程中,所述主消息管理器察看它处于什么样的分区状态。如果其处于分区状态B、C或者D,那么将自身降级为保留主消息管理器,并且如果其处于分区状态D,那么它也将自身降级为受限主消息管理器。
在已经与每个子集群中的主消息管理器达成一致之后,那么所述消息管理器使它们的目的地状态同步,以便实现在目的地方面的一致性,也就是说,在网络分区或节点故障期间、交换与在每个分区中也许已从生产者接收的或者发送给消费者的消息有关的信息。这通过使用一种基于解熵(anti-entropy)的方法来执行,也就是说,在分区的情况下,用于使两个实体一致的方法。在已经使目的地状态同步之后,每个子集群中的所述主消息管理器评估是否应该发送一些未发送的队列或者主题消息。此外,每个子集群中的主消息管理器评估是否存在被阻塞的消息,以及将它们发送与否,并且如果还没有发送,则评估是否现在就可以将它们发送。最后,每个子集群中的主消息管理器评估是否存在现在可以处理的主题消息。
所述节点状态以及它们的确定性行为提供了一个牢固的基础,在这个基础上,可以按这样一种方式来执行消息发送,所述方式为:在节点故障以及网络分区期间保证语义正确。然而,为了实现这一目的,必须要具有适用的消息传送机制并且采用该机制。
为了传递通用消息,客户端向与其相连的客户端管理器发送一条消息。当接收所述消息时,客户端管理器利用当前视图状态序列号来标记所述消息。所述标记符的目的在于识别在一个视图状态期间接收的以及在新视图状态期间发送的消息。这些消息正是潜在的重复消息候选者。原因是:当所述视图状态改变时,在这以后也许已发生网络分区,两个网络分区中的主消息管理器因为相信它们是唯一一个做这件事的,所以将试图发送相同的消息。由此,使用作为潜在候选者的标记消息,可以识别重复消息,并且能够采取适当的动作。
现在所述客户端管理器向其目的地发送所述消息,也就是,在消息管理器上的队列或者主题。所述客户端管理器完全知道所有可能的目的地,并且由此在多点传送子集群多点传送层上的消息以前、被所述消息标记上已选择的目的地。当接收所述消息时,只有主消息管理器确认接收到所述消息。所述备用消息管理器不对其进行确认,而是它们仅仅等着听主消息管理器确认收到所述消息的信。这样做以后,备用消息管理器寄存该消息。这在以下方案中十分有用,所述方案是:在已经接收消息后、但在已经确认收到它之前,主消息管理器成为不可用;新的主消息管理器于是将知道是否应该让所述客户端管理器得到消息的确认。一旦客户端管理器接收消息管理器的消息收到通知,它向客户端告知接收确认,并且将所述消息从存储器中移去。
所述主消息管理器现在选择将要接收给定队列信息的单个客户端,或者接给定主题消息的多个客户端。如此执行之后,所述主消息管理器利用会话的标识符标记所述消息,以接收所述消息并且在子集群信道上多点传送它,以便其可以由所述客户端管理器以及消息管理器接收到。当多点传送所述消息时,所有的消息管理器(主的和备用的)接收由所述主消息管理器发送的消息,并且都登记由主消息管理器向外所发送的。在客户端管理器向客户端实际发送消息以前,它需要从处于当前视图状态中的大多数客户端管理器接收这样做的确认。接收要发送的消息的每个客户端管理器——包括负责实际发送的客户端管理器——将通过在子集群多点传送层上多点传送一条收到通知来确认收到。由负责发送消息的客户端管理器进行的确认、被所有的消息管理器接收并且登记。如果负责的客户端管理器接收到来自于所述客户端管理器的大多数确认——包括其自己的选票——那么将所述消息发送给客户端,并且所述客户端于是将等待来自于所述客户端的确认。使用此确认方案的原因在于:即使是发生视图改变以前,也能确保不会将消息发送到具有少数处于当前视图状态中的客户端管理器的分区中。
当所述客户端管理器接收来自于客户端的确认时,它在多点传送层上多点传送此确认,以便所述子集群中的所有消息管理器可以接收到。所述消息管理器以及发送客户端管理器都指示所述消息已经成功地由所述客户端接收,并且对将被整理的消息进行标记。
如果当主消息管理器发送消息时、所述客户端会话对客户端管理器而言不再可用,那么所述客户端管理器送回对此陈述的消息,这使得所述消息管理器不将所述消息标记为正发送给客户端管理器的消息,然后,在点到点消息的情况下,可以将其重新发送。在不耐久的发布/预订消息的情况下,所述客户端管理器简单地送回用于陈述不再发送给指定客户端的消息,不需要采取其他的动作。对于持久的预订者来说,所述客户端管理器将送回陈述所述客户端不接收所述消息的消息,并且因此必须保留所述消息,至少到所述耐久的预订者与消息服务器集群重新连接时。
目的地可以在任意点、因各种原因及时接收来自于乱序的特定客户端会话的消息。如果会话例如错过一条或多条来自于客户端会话的消息,就会发生这种情况。具体来讲,可以要求目的地在还没有接收所有在前的消息时,接收具有序列号X+10的消息。这只有当在集群中发生一些故障时才会发生,其中移动正在一个子集群上向一个目的地进行发布的客户端,以便在另一个子集群上向相同目的地进行发布。如果在主消息管理器将在一个子集群上向一个目的地发布的消息X+9发送以前,该主消息管理器将在另一个子集群上向相同目的地发布的消息X+10发送给客户端,那么就会可能会潜在地导致对客户端的无序发送。
具体来讲,如果客户端失去其与客户端管理器的连接,就会发生这样的情况,其中该客户端在所述连接上已经产生至某个目的地的消息,之后,该客户端将从另一个客户端管理器重新连接到该集群。通常,由于来自于重连接请求的新的客户端管理器能够看到客户端已经将哪个子集群发布到每个目的地,所以这不会造成问题。然而,假定所述集群/子集群是网络分区并且用作到集群/子集群的入口点的新客户端管理器处于比客户端管理器靠前的另一个分区,那么存在潜在的语义问题。所述问题在于在特定会话上维护消息发送的部分排序。所述问题源于这样的事实,其中特定目的地可能跨越多个子集群——均具有整个消息组的子集——并且在故障期间,客户端会话也许已向不同的子集群上的相同目的地发布了。
客户端发出的重连接请求可以显示出先前向另一个子集群发布消息的客户端。照此,为防止出现任何语义的问题,如果可能的话,所述客户端管理器试图将所述客户端与先前的子集群重新连接。如果这是不可能的,那么所述客户端管理器无论如何也要将接受所述重新连接请求,并且将其留给主消息管理器以便解决任何语义的问题。
为解决所述潜在的语义问题,由客户端发布给目的地的每条消息都具有标识符,所述标识符是由所述会话的客户端分配,并且是会话、目的地以及目的地和会话组合内的信息顺序号的标识符——无论这是否是一部分唯一标识。根据此信息,所述主消息管理器能因此看出在目的地的消息序列中是否存在间隙。一旦所述主消息管理器检测从特定会话到特定目的地的消息丢失,就阻塞连续的消息,也就是说,在目的地的同步以使在目的地上具有按次序的消息的完整序列以前,不会发送所述连续的消息,并且由此观察所述部分有序的消息。
本发明还确保事务的语义正确处理,也就是说,在网络分区与节点故障期间发送多个消息的原子执行。本发明支持跨越多个子集群的事务的处理,如图4中所示。对于事务处理来说,所述客户端管理器充当事务管理器,那么这意味其上连接有客户端的所述客户端管理器负责协调并且执行具有不同的子集群的事务的不同阶段。本发明使用了2状态(phase)——提交事务方案。
为了使用事务,所述客户端必须规定其将要提事务的会话。通过规定将要提事务的会话,需要客户端在某点要么提交要么中断整套消息,所述消息是发送给集群的,或者从集群接收到的。所述2相提交过程完全由所述客户端管理器中的事务管理器来处理,并且在客户端中是透明的。因此,所述事务管理器也是透明地执行这些操作。然而,没有要求所述客户端应该多长时间提交或者中断所述事务一次。假如在提事务会话的使用期限期间所述客户端可以提交或者中断多次,那么从概念上,有人会说提事务会话包含多个自主性事务,所述自主性事务因由客户端发起的提交/中断命令而独立。如果中断其中一个事务,或者其中一个事务发生故障,那么它对先前的或者相继的事务没有影响。图5举例说明了包含三个消息以及一随时间执行的提交。在已经指定其会话是提事务的之后,客户端可以向所述事务管理器发送多个消息,并且客户端可以经由所述事务管理器接收由所述主消息管理器发送的消息。
在某点,所述客户端向所述事务管理器发送一次提交。当接收所述提交请求时,所述事务管理器将其转换为最初的准备操作,然后,将其多点传送到参与所述事务的子集群,所述事务后面是随后的提交或者中断,取决于准备提交的结果。所述准备请求包含按每一子集群分类发送以及接收的包括在所述事务中的所有消息的标识符。刚一接收到所述预备请求时,在参与子集群中的消息管理器就察看它们是否已经接收到所有消息,这些消息是依照预备请求中包括的消息识别符来假设的。如果是这样的话,所述消息管理器积极地响应所述事务管理器,否则相反。
如果只有一个消息管理器(主的或备用的)不响应所述预备请求,那么所述事务管理器通过将它多点传送到子集群并且将所述中断报告给客户端,来中止所述事务。如果所有的消息管理器都积极地响应,那么所述事务管理器将一提交操作多点传送到参与所述事务的子集群中的消息管理器,并且随后报告客户端提交成功。当接收一提交请求时,所有消息管理器以这样一种方式来更新消息存储,所述方式为:立刻将发送操作公开,并且立刻考虑传送所接收的消息。
由于节点故障以及网络分区而引起状态改变对事务处理造成了一个问题。在状态改变期间,所述事务的执行环境可能会以这样一种方式改变,其中如果没有正确地处理这种情况,那么所述事务可以中断消息处理的语义。这例如在这样一种情况下发生,所述情况即:事务管理器与所述集群/子集分开,同时主消息管理器被降至受限/保留主消息管理器。为了防止中断语义,因此在参与的子集群或者整个集群中的状态改变通过参与所述事务的消息管理器触发事务的中止,如果:
·状态改变的后果是包含事务管理器的分区的分区状态改变为D(即便它已经是D)
或者
·所述事务管理器对于参与所述事务的集群/子集群是不可用的,也就是说,失效或者不再独立而进入另一个分区。
在所有其它的情况下,不中止所述事务,而是一旦所述集群已经习惯于它的新状态,就从那里继续。
在子集群中的每个消息管理器中,利用一个标签来标记已接收和发送的消息,所述标签说明将它们作为提事务会话的一部分而加锁并且还没有被提交。状态改变一旦迫使一事务中止,由事务管理器获得的那些保持在消息的锁就将被释放,从这点意义上来讲,所用的事务是未阻塞的。这意味着所述事务中的节点无疑具有一个超时值,所述超时值由底层的多点传送层使用来检测故障。然而,没有其它能够影响所述事务的超时值。
如果在执行事务期间,所述事务管理器无效或者远离所述消息管理器被分区,可是在提交或者中止它以前,参与所述事务的所有消息管理器在已经经由视图状态改变而实现该事件以后、将简单地中止所述事务。如果所述事务管理器失效,那么启动所述事务的客户端将接收一个异常(exception),该异常告诉此客户端它失去了与所述事务管理器的连接,并且由此会当前事务故障。如果将启动所述事务的客户端远离所述事务管理器分区,那么会发生同样的事情。在所述异常中还包括的是事务序列号。利用此事务序列号,所述客户端将在某点与另一个客户端管理器重新连接,并且重新初始化它的事务,然后该事务利用新的事务管理器被重新起动。
如果所述事务管理器在已经接收来自于客户端的提交请求以后立即成为不可用的,那么所述客户端将接收一个异常,该异常表示已经失去与所述事务管理器-客户端管理器的连接。然而,所述客户端不知道所述事务发生了什么事,也就是说,无论它实际上是否提交。在已经通过重新连接另一个客户端管理器来建立新的连接之后,所述客户端立刻试图恢复所述事务。在这一阶段,所述客户端不能只中止所述事务,原因在于如果继消息之后的先前的提交可能已经是可公开访问的了,并且例如已经由其他客户端消费。假定所述客户端不知道所述先前的提交实际上是否已被执行,所以它试图从新的事务管理器-客户端管理器重新提交所述事务。因为这要在语义上是有效的,所以所述提交操作是等幂的,从而如果先前的提交实际上已执行、并且随后发生重新提交相同事务的话,没有任何损害。
为了重新发起提交,所述事务以及要提交的事务的一部分,也就是说,自从上次提交以来发送并且接收的消息,应该是可识别的,以便确保正确事务的正确部分得以提交。事务的每次提交/中止部分必须是可唯一识别,原因在于:确保一重新发起的提交不会提交错误的事务部分。
当接收重新提交(recommit)的操作时,新的事务管理器将其转换为提交或者中止之后的预备操作。这是缺省的2状态-提交事务处理行为。如果所述预备操作的结果是正态,意味着参与所述事务的所有消息管理器——主的备用的——都积极地响应预备操作,这意味着所述先前的提交实际上继续。在另一方面,如果参与所述事务的消息管理器不响应所述预备操作,这意味着所述先前的提交没有继续,并且由此随着因先前事务管理器的故障而触发的状态改变,所述事务被中止。上述操作还适用于这样的方案,即其中所述事务管理器在已经接收来自于所述客户端的中止操作以后所述事务管理器故障。
为了使上述方案有效工作,参与事务的每个消息管理器——主的和备用的——必须为每个提事务的会话记录上次执行的事务的序列号以及这次事务的结果。这个信息由每个消息管理器——主的和备用的——存留。
概括地说,本发明所形成的优点包括以下几点:
-依照本发明的方法,在集群式消息传送系统的节点故障以及网络划分期间可以保证JMS语义。
-本发明尤其确保在集群式消息传送系统的节点故障以及网络划分期间,没有任何消息超过一次被传送到客户端应用,除了在JMS规范中所规定的异常。
-本发明尤其确保在集群式消息传送系统的节点故障以及网络划分期间,不会丢失任何消息,除了在JMS规范中所规定的允许的异常之外。
-本发明尤其确保在集群式消息传送系统的节点故障以及网络划分期间,将处于某点的所有主题消息传送到所有客户端应用,除非所述主题消息在节点故障或者网络故障恢复以前期满。
-作为保证JMS语义的扩展,本发明确保所述集群式消息传送系统始终可以用来从消息生产者那里接收消息,并且保证那些消息的正确发送,即便在所述集群受到网络划分时也是如此。这些自然是假定在所述集群式消息传送系统中不是所有的节点都已经失效。
在不脱离本发明精神和范围的情况下,可以想象出很多其它的提交例。
使用的术语汇编
·集群:在一个以上的计算机上运行的一组过程,并且一起工作起来就像单个消息传送服务器一样动作,但是却具有提高的性能以及可靠性。对于客户端来说,集群在功能上等效于单片服务器,并且因此其对于客户端来说是透明的。
·节点:集群内的单个逻辑过程。节点往往对应于单个计算机,但是这不是绝对的情形。共享一个计算机的多个节点将与其它节点交互,就好象它们处于仅有网络连接的不同计算机上。
·单片服务器:作为单个节点运转的完整的消息服务器。
·服务器实例(instance):单个逻辑消息服务器的泛称。这可以是上述定义单片服务器或者集群。
·客户端:一种应用程序,与集群中的节点相连接以便向服务器实例发送(发布)消息,或者从服务器实例接收(消费)消息。
·JMS:(Java消息服务,Java Message Service)一种用于以Java语言编写的程序的标准应用编程接口(API),以便用于访问消息系统的服务。
Claims (14)
1.对于在消息客户端之间以消息的形式传送数据的消息系统,所述消息系统包括包含一组消息管理器节点的服务器集群,并且所述消息管理器节点具有用于存储和分发消息的装置,一种用于在节点故障以及网络划分期间确保操作的方法,所述方法包括:
-在每个运行着的消息管理器节点中,维护一个集群状态数据集,该集群状态数据集包括有关存在于所述集群中的节点的信息,
-在所述消息管理器节点中每一运行着的节点中,重复地评估一个视图状态数据集,该视图状态数据集包括有关能够与所述消息管理器节点进行通信的服务器节点的信息,
-将所述集群状态数据集与所述视图状态数据集进行比较,并且评估是否所有的消息管理器都能够与所述消息管理器节点通信,
-如果不是所有的消息管理器都能够与所述消息管理器节点进行通信,那么从至少两个不同的状态中确定一个用于点到点式传送消息的操作状态,其中
所述至少两个不同的状态中的第一个状态是用于正常操作的非受限状态,允许正处于所述非受限状态中的消息管理器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前以及从其改变以来所发送的消息,以及
所述两个不同状态的第二个状态是受限状态,不允许正处于受限状态中的消息管理器分派在当前网络的视图状态上次改变之前发送的点到点消息,
并且其中以这样一种方式来确定操作状态,在该种方式中,负责分派相同点到点消息的任何两个消息管理器节点相互之间不能进行通信,最多其中一个可以处于非受限的操作状态中。
2.如权利要求1所述的方法,进一步包括:如果不是所有的消息管理器都能够与所述消息管理器节点通信,那么从至少两个不同的状态中确定一种用于发布/预订式传送消息的操作状态,其中
所述至少两个不同状态中的第一个状态是用于正常操作的不保留状态,只要消息管理器已经确定所有合格的预订者都已经接收那些消息的副本,就允许正处于所述不保留状态中的消息管理器删除发布/预订消息,并且
所述两个不同状态中的第二个状态是保留状态,在个别消息满期之前,或者在消息管理器转换为不保留状态并且确定所有合格的预订者都已经接收那些消息的副本之前,不允许正处于所述保留状态中的消息管理器删除发布/预订消息,
并且其中以这样一种方式来确定操作状态,在该种方式中,负责分派相同发布/预订消息的任何两个消息管理器节点相互之间都不能进行通信,并且这两个节点必须都处于保留状态中。
3.如权利要求2所述的方法,其中所述服务器集群还包括一组客户端管理器节点,所述客户端管理器节点与所述消息管理器节点被不同地编程,并且其中
每个消息管理器节点始终属于至少三个不同的分区状态(A、C、D)中的一个分区状态,
其中如果所述消息管理器能与负责分配相同消息的所有其它消息管理器通信,那么它属于第一分区状态(A),其中如果不能与负责分派相同消息的所有其它消息管理器通信,但是如果它能与大多数客户端管理器节点通信,那么它属于另一个分区状态(C),否则的话,它属于又一个分区状态(D),
并且其中如果所述消息管理器处于第一或者另一个分区状态(A、C),那么可以确定它处于非受限操作状态,否则可以确定它处于受限操作状态,并且其中如果消息管理器处于第一分区状态(A),那么可以确定它处于不保留操作状态,否则可以确定它处于保留操作状态。
4.如权利要求2所述的方法,其中所述服务器集群还包括一组客户端管理器节点,所述客户端管理器节点在功能上与所述消息管理器节点不同,并且其中
每个消息管理器节点始终属于至少四个不同的分区状态(A、B、C、D)中的一个分区状态,
其中如果所述消息管理器能与负责分配相同消息组的集群的所有其他消息管理器节点通信,那么它属于第一分区状态(A),
其中如果它也不能与负责分派同类消息的另一消息管理器通信,而能够与大多数客户端管理器通信,或者其分区状态在上次视图状态改变之前处于第二分区状态,并且它仍无法与负责分发相同消息的任一其他消息管理器通信,但它能够与至少一个客户端管理器通信,那么它属于第二分区状态(B),
其中如果它没有处于第一分区状态(A)或者第二分区状态(B),并且其中负责分派相同组消息的集群的至少一个其他消息管理器节点也能与它通信,并且它能够与大多数客户端管理器节点通信,那么它属于第三分区状态(C),
并且其中如果它不属于第一、第二或者第三分区状态,那么它属于第四分区状态(D),
附加限制是,当在视图状态上次改变之前,它曾处于第四状态(D)时,它不属于第二状态(B)或者第三状态(C),
并且其中如果所述消息管理器处于第一、第二或者第三分区状态(A、B、C),那么可以确定它处于非受限操作状态,否则可以确定它处于受限操作状态,并且其中如果消息管理器处于第一分区状态(A),那么可以确定它处于不保留操作状态,否则可以确定它处于保留操作状态。
5.如权利要求1所述的方法,其中当所述服务器系统运行着,所述消息管理器节点始终属于用于点到点传送消息的操作状态。
6.如权利要求2所述的方法,其中当所述服务器系统运行着,所述消息管理器节点始终属于用于发布/预订传送消息的操作状态。
7.对于在消息客户端之间以消息的形式传送数据的消息系统,所述消息系统包括一个服务器集群,该服务器集群包含一组消息管理器节点,且所述消息管理器节点具有用于存储和分发消息的装置,一种用于在节点故障以及网络划分期间确保操作的方法,所述方法包括:
-在每个运行着的消息管理器节点中,维护一个集群状态数据集,该集群状态数据集包括有关存在于所述集群中的节点的信息,
-在所述消息管理器节点中每一运行着的节点中,重复地评估一个视图状态数据集,该视图状态数据集包括有关能够与所述消息管理器节点进行通信的服务器节点的信息,
-将所述集群状态数据集与所述视图状态数据集进行比较,并且评估是否所有的消息管理器都能够与所述消息管理器节点通信,
-如果不是所有的消息管理器都能够与所述消息管理器节点通信,那么从至少两个不同的状态中确定一种用于发布/预订式传送消息的操作状态,其中
所述至少两个不同状态中的第一个状态是不保留状态,只要消息管理器已经确定所有合格的预订者都已经接收那些消息的副本,就允许正处于所述不保留状态中的消息管理器删除发布/预订消息,并且
所述两个不同状态中的第二个状态是保留状态,在个别消息满期之前,或者消息管理器改变为不保留状态并且确定所有合格的预订者都已经接收到那些消息的副本时,不允许正处于所述保留状态中的消息管理器删除发布/预订消息,
并且其中以这样一种方式来确定操作状态,在该种方式中,负责分派相同发布/预订消息的任何两个消息管理器节点相互之间都不能进行通信,并且这两个节点都必须处于保留状态中。
8.对于在消息客户端之间以消息的形式传送数据的消息系统,所述消息系统包括被划分为子集群的服务器集群,所述子集群包含一组具有用于存储和分发消息的装置的消息管理器节点,一种用于在节点故障以及网络划分期间确保操作的方法,所述方法包括:
-在每个运行着的消息管理器服务器中,维护一个子集群状态数据集,该子集群状态数据集包括有关存在于所述集群的服务器的信息,
-在所述消息管理器节点中每一运行着的节点中,重复地评估一个视图状态数据集,该视图状态数据集包括有关能够与所述消息管理器节点进行通信的服务器节点的信息,
-将所述子集群状态数据集与所述视图状态数据集进行比较,并且评估是否子集群的所有消息管理器都能够与所述消息管理器节点通信,
-如果不是子集群的所有消息管理器都能够与所述消息管理器节点通信,那么可以从至少两个不同状态中确定一点到点操作状态,其中
所述至少两个不同状态中的第一个状态是非受限状态,允许正处于所述非受限状态中的消息服务器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前以及自从其改变之后所发送的消息,以及
所述至少两个不同状态中的第二个状态是受限状态,不允许正处于所述受限状态中的消息服务器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前发送的消息,
并且其中以这样的方式来确定操作状态,其中相同子集群的两个消息管理器节点相互之间不能进行通信,最多有一个可以处于非受限状态。
9.如权利要求8所述的方法,进一步包括,如果不是子集群的所有消息管理器都能够与所述消息管理器节点通信,那么从至少两个不同的状态中确定一种用于发布/预订式传送消息的操作状态,其中
所述至少两个不同状态中的第一个状态是用于正常操作的不保留状态,只要消息管理器已经确定所有合格的预订都已经接收那些消息的副本,就允许正处于所述不保留状态中的消息管理器删除发布/预订消息,并且
所述两个不同状态中的第二个状态是保留状态,在个别消息满期之前,或者在消息管理器改变为不保留状态并且确定所有的合格的预订者都已经接收那些消息的副本之前,不允许正处于所述保留状态中的消息管理器删除发布/预订消息,
并且其中以这样一种方式来确定操作状态,在该种方式中,相同子集群中的任何两个消息管理器节点相互之间不能进行通信,并且这两个节点必须都处于保留状态中。
10.对于在消息客户端之间以消息的形式传送数据的消息系统,所述消息系统包括一个服务器集群,该服务器集群包括一组消息管理器节点,并且所述消息管理器节点具有用于存储和分发消息的装置,用于在节点故障以及网络划分期间保证JMS语义的方法,所述方法包括:
-在每个运行着的消息管理器节点中,维护一个集群状态数据集,该集群状态数据集包括有关存在于所述集群中的节点的信息,
-在所述消息管理器节点中每一运行着的节点中,重复地评估一个视图状态数据集,该视图状态数据集包括有关能够与所述消息管理器节点进行通信的服务器节点的信息,
-将所述集群状态数据集与所述视图状态数据集进行比较,并且评估是否所有的消息管理器都能够与所述消息管理器节点通信,
-如果不是所有的消息管理器都能够与所述消息管理器节点通信,那么从至少两个不同的状态中确定一个用于点到点式传送消息的操作状态,其中
所述至少两个不同的状态中的第一个状态是:用于正常操作的非受限状态,允许正处于所述非受限状态中的消息管理器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前以及从其改变以来所发送的消息,以及
所述至少两个不同状态中的第二个状态是受限状态,不允许正处于所述受限状态中的消息管理器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前发送的消息,
并且其中以这样一种方式来确定操作状态,在该种方式中,负责分派相同点到点消息的任何两个消息管理器节点相互之间不能进行通信,最多一个可以处于非受限的操作状态中,
并且还包括,如果不是所有的消息管理器都能够与所述消息管理器节点通信,那么从至少两个不同的状态中确定一种用于发布/预订式传送消息的操作状态,其中
所述至少两个不同状态中的第一个状态是用于正常操作的不保留状态,只要消息管理器已经确定所有合格的预订都已经接收那些消息的副本,就允许正处于所述不保留状态中的消息管理器删除发布/预订消息,并且
所述两个不同状态中的第二个状态是保留状态,在个别消息满期之前,或者在消息管理器改变为不保留状态并且确定所有的合格的预订者都已经接收那些消息的副本之前,不允许正处于所述保留状态中的消息管理器删除发布/预订消息,
并且其中以这样一种方式来确定操作状态,在该种方式中,负责分派相同发布/预订消息的任何两个消息管理器节点相互之间都不能进行通信,并且这两个节点必须都处于保留状态中。
11.一种用于在消息客户端之间以消息的形式传送数据的消息系统,所述消息系统包括一个服务器集群,该服务器集群包含一组消息管理器节点,并且所述消息管理器节点具有用于存储和分发消息的装置,一种在节点故障以及网络划分期间确保操作的方法,其中每个消息管理器节点包括以下装置,以用于:
-在每个运行着的消息管理器节点中,维护一个集群状态数据集,该集群状态数据集包括有关存在于所述集群中的节点的信息,
-在所述消息管理器节点中每一运行着的节点中,重复地评估一个视图状态数据集,该视图状态数据集包括有关能够与所述消息管理器节点进行通信的服务器节点的信息,
-将所述集群状态数据集与所述视图状态数据集进行比较,并且评估是否所有的消息管理器都能够与所述消息管理器节点通信,
-如果不是所有的消息管理器都能够与所述消息管理器节点通信,那么从至少两个不同的状态中确定一个用于点到点式传送消息的操作状态,其中
所述至少两个不同的状态中的第一个状态是:用于正常操作的非受限状态,允许正处于所述非受限状态中的消息管理器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前以及从其改变以来所发送的消息,以及
所述至少两个不同状态中的第二个状态是受限状态,不允许正处于所述受限状态中的消息管理器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前发送的消息,
并且其中用于从至少两个状态中确定一操作状态的所述装置以这样一种方式来配置,在该种方式中,负责分派相同点到点消息的两个消息管理器节点相互之间不能通信,最多一个可以处于非受限操作状态中。
12.如权利要求11所述的系统,还包括如下装置,该装置用于在不是所有的消息管理器都能够与所述消息管理器节点进行通信的请况下,从至少两个不同的状态中确定一种用于发布/预订式传送消息的操作状态,其中
所述至少两个不同状态中的第一个状态是用于正常操作的不保留状态,只要消息管理器已经确定所有合格的预订都已经接收那些消息的副本,就允许正处于所述不保留状态中的消息管理器删除发布/预订消息,并且
所述两个不同状态中的第二个状态是保留状态,在个别消息满期之前,或者在消息管理器改变为不保留状态并且确定所有的合格的预订者都已经接收那些消息的副本之前,不允许正处于所述保留状态中的消息管理器删除发布/预订消息,
并且将用于确定操作状态的装置以这样一种方式进行编程,在该种方式中,负责分派相同发布/预订消息的任何两个消息管理器节点相互之间都不能进行通信,并且这两个节点必须都处于保留状态中。
13.一种计算机程序产品,包括具有计算机可读程序代码装置的计算机可用介质,在所述计算机可读程序代码装置中具体使计算机能作为服务器集群中的消息管理器,所述程序产品包括计算机可读代码装置,以用于使计算机能够
-在每个运行着的消息管理器节点中,维护一个集群状态数据集,该集群状态数据集包括有关存在于所述集群中的节点的信息,
-在所述消息管理器节点中每一运行着的节点中,重复地评估一个视图状态数据集,该视图状态数据集包括有关能够与所述消息管理器节点进行通信的服务器节点的信息,
-将所述集群状态数据集与所述视图状态数据集进行比较,并且评估是否所有的消息管理器都能够与所述消息管理器节点通信,
-如果不是所有的消息管理器都能够与所述消息管理器节点通信,那么从至少两个不同的状态中确定一个用于点到点式传送消息的操作状态,其中
所述至少两个不同的状态中的第一个状态是:用于正常操作的非受限状态,允许正处于所述非受限状态中的消息管理器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前以及从其改变以来所发送的消息,以及
所述至少两个不同状态中的第二个状态是受限状态,不允许正处于所述受限状态中的消息管理器分派点到点消息,所述点到点消息是在当前网络的视图状态上次改变之前发送的消息,
并且其中将用于确定操作状态的装置以这样一种方式进行编程,在该种方式中,负责分派相同点到点消息的任何两个消息管理器节点相互之间不能通信,并且最多一个可以处于非受限操作状态中。
14.如权利要求13所述的计算机程序产品,其中所述计算机可读代码装置包括如下装置,该装置应用以Java语言编写的库并且符合Java消息服务API的装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/899,662 US6877107B2 (en) | 2001-07-05 | 2001-07-05 | Method for ensuring operation during node failures and network partitions in a clustered message passing server |
US09/899,662 | 2001-07-05 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1552020A true CN1552020A (zh) | 2004-12-01 |
Family
ID=25411353
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA028174275A Pending CN1552020A (zh) | 2001-07-05 | 2002-06-10 | 用于在集群式消息传递服务器中在节点故障以及网络划分期间确保操作的方法 |
Country Status (6)
Country | Link |
---|---|
US (1) | US6877107B2 (zh) |
EP (1) | EP1402363B1 (zh) |
CN (1) | CN1552020A (zh) |
AT (1) | ATE309571T1 (zh) |
DE (1) | DE60207251T2 (zh) |
WO (1) | WO2003005194A2 (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102137032A (zh) * | 2011-03-24 | 2011-07-27 | 上海云高软件科技有限公司 | 一种云消息系统及云消息发送和接收方法 |
CN101681163B (zh) * | 2007-04-13 | 2015-02-25 | 西门子公司 | 使用模式规则的机器状态监控 |
CN104994168A (zh) * | 2015-07-14 | 2015-10-21 | 苏州科达科技股份有限公司 | 分布式存储方法及分布式存储系统 |
CN111708668A (zh) * | 2020-05-29 | 2020-09-25 | 北京金山云网络技术有限公司 | 集群故障的处理方法、装置及电子设备 |
CN115379401A (zh) * | 2022-08-05 | 2022-11-22 | 中国银行股份有限公司 | 一种异步银行消息的处理方法和装置 |
Families Citing this family (121)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7177917B2 (en) | 2000-12-27 | 2007-02-13 | Softwired Ag | Scaleable message system |
US7305450B2 (en) * | 2001-03-29 | 2007-12-04 | Nokia Corporation | Method and apparatus for clustered SSL accelerator |
US7146524B2 (en) * | 2001-08-03 | 2006-12-05 | Isilon Systems, Inc. | Systems and methods for providing a distributed file system incorporating a virtual hot spare |
US7685126B2 (en) * | 2001-08-03 | 2010-03-23 | Isilon Systems, Inc. | System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system |
US7113980B2 (en) * | 2001-09-06 | 2006-09-26 | Bea Systems, Inc. | Exactly once JMS communication |
US20030088659A1 (en) * | 2001-11-08 | 2003-05-08 | Susarla Hanumantha Rao | System and method for distributed state management |
US20030115366A1 (en) * | 2001-12-18 | 2003-06-19 | Robinson Brian R. | Asynchronous message delivery system and method |
US7181489B2 (en) * | 2002-01-10 | 2007-02-20 | International Business Machines Corporation | Method, apparatus, and program for distributing a document object model in a web server cluster |
US7369808B2 (en) | 2002-02-07 | 2008-05-06 | Sap Aktiengesellschaft | Instructional architecture for collaborative e-learning |
US20030157470A1 (en) * | 2002-02-11 | 2003-08-21 | Michael Altenhofen | E-learning station and interface |
US20030152905A1 (en) * | 2002-02-11 | 2003-08-14 | Michael Altenhofen | E-learning system |
WO2003073311A1 (en) * | 2002-02-21 | 2003-09-04 | Bea Systems, Inc. | System and method for message driven bean service migration |
US7155438B2 (en) * | 2002-05-01 | 2006-12-26 | Bea Systems, Inc. | High availability for event forwarding |
US7222148B2 (en) * | 2002-05-02 | 2007-05-22 | Bea Systems, Inc. | System and method for providing highly available processing of asynchronous service requests |
US20040044892A1 (en) * | 2002-09-03 | 2004-03-04 | Elmar Dorner | Content based messaging for e-learning |
AU2003291014A1 (en) | 2002-11-14 | 2004-06-15 | Isilon Systems, Inc. | Systems and methods for restriping files in a distributed file system |
US20040205770A1 (en) * | 2003-02-11 | 2004-10-14 | International Business Machines Corporation | Duplicate message elimination system for a message broker |
US7676580B2 (en) | 2003-03-27 | 2010-03-09 | Microsoft Corporation | Message delivery with configurable assurances and features between two endpoints |
US7702729B2 (en) * | 2003-04-08 | 2010-04-20 | Johanson Bradley E | Event heap: a coordination infrastructure for dynamic heterogeneous application interactions in ubiquitous computing environments |
US7526549B2 (en) * | 2003-07-24 | 2009-04-28 | International Business Machines Corporation | Cluster data port services for clustered computer system |
US7739541B1 (en) * | 2003-07-25 | 2010-06-15 | Symantec Operating Corporation | System and method for resolving cluster partitions in out-of-band storage virtualization environments |
US7644118B2 (en) | 2003-09-11 | 2010-01-05 | International Business Machines Corporation | Methods, systems, and media to enhance persistence of a message |
US20050071848A1 (en) * | 2003-09-29 | 2005-03-31 | Ellen Kempin | Automatic registration and deregistration of message queues |
US20050097343A1 (en) * | 2003-10-31 | 2005-05-05 | Michael Altenhofen | Secure user-specific application versions |
US7287066B2 (en) * | 2003-10-31 | 2007-10-23 | Sap Aktiengesellschaft | Publish-subscribe system having a reliability mechanism |
US7478400B1 (en) * | 2003-12-31 | 2009-01-13 | Symantec Operating Corporation | Efficient distributed transaction protocol for a distributed file sharing system |
US20050210152A1 (en) * | 2004-03-17 | 2005-09-22 | Microsoft Corporation | Providing availability information using a distributed cache arrangement and updating the caches using peer-to-peer synchronization strategies |
US7272634B2 (en) * | 2004-03-18 | 2007-09-18 | Sony Corporation | System and method for integrating multiple messaging systems |
US20050216506A1 (en) * | 2004-03-25 | 2005-09-29 | Wolfgang Theilmann | Versioning electronic learning objects using project objects |
CN1331042C (zh) * | 2004-03-29 | 2007-08-08 | 联想(北京)有限公司 | 用于机群监控系统控制台的消息服务装置及其方法 |
US7664818B2 (en) * | 2004-04-21 | 2010-02-16 | Sap (Ag) | Message-oriented middleware provider having multiple server instances integrated into a clustered application server infrastructure |
US7512668B2 (en) * | 2004-04-21 | 2009-03-31 | Sap Ag | Message-oriented middleware server instance failover |
US7634550B2 (en) * | 2004-04-21 | 2009-12-15 | Sap Ag | Message-oriented middleware provider having multiple server instances |
US7983173B2 (en) * | 2004-05-10 | 2011-07-19 | Cisco Technology, Inc. | System and method for detecting link failures |
US7334154B2 (en) * | 2004-06-18 | 2008-02-19 | Microsoft Corporation | Efficient changing of replica sets in distributed fault-tolerant computing system |
US20060008789A1 (en) * | 2004-07-07 | 2006-01-12 | Wolfgang Gerteis | E-learning course extractor |
US8898246B2 (en) * | 2004-07-29 | 2014-11-25 | Hewlett-Packard Development Company, L.P. | Communication among partitioned devices |
WO2006035266A1 (en) * | 2004-09-29 | 2006-04-06 | Telefonaktiebolaget L M Ericsson (Publ) | Installing a new view of a cluster membership |
US20080201403A1 (en) * | 2004-09-29 | 2008-08-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Maintaning a View of a Cluster's Membership |
US8238350B2 (en) | 2004-10-29 | 2012-08-07 | Emc Corporation | Message batching with checkpoints systems and methods |
US8055711B2 (en) * | 2004-10-29 | 2011-11-08 | Emc Corporation | Non-blocking commit protocol systems and methods |
US8051425B2 (en) * | 2004-10-29 | 2011-11-01 | Emc Corporation | Distributed system with asynchronous execution systems and methods |
US7689655B2 (en) * | 2004-12-06 | 2010-03-30 | Aol Inc. | Managing and collaborating with digital content using a dynamic user interface |
JP2006260325A (ja) * | 2005-03-18 | 2006-09-28 | Fujitsu Ltd | 障害の伝達方法 |
US8191078B1 (en) * | 2005-03-22 | 2012-05-29 | Progress Software Corporation | Fault-tolerant messaging system and methods |
US7747894B2 (en) * | 2005-06-06 | 2010-06-29 | Microsoft Corporation | Transport-neutral in-order delivery in a distributed system |
US8046780B1 (en) | 2005-09-20 | 2011-10-25 | Savi Technology, Inc. | Efficient processing of assets with multiple data feeds |
US8200563B2 (en) * | 2005-09-23 | 2012-06-12 | Chicago Mercantile Exchange Inc. | Publish and subscribe system including buffer |
US7551572B2 (en) * | 2005-10-21 | 2009-06-23 | Isilon Systems, Inc. | Systems and methods for providing variable protection |
US7917474B2 (en) | 2005-10-21 | 2011-03-29 | Isilon Systems, Inc. | Systems and methods for accessing and updating distributed data |
US7797283B2 (en) | 2005-10-21 | 2010-09-14 | Isilon Systems, Inc. | Systems and methods for maintaining distributed data |
US7788303B2 (en) | 2005-10-21 | 2010-08-31 | Isilon Systems, Inc. | Systems and methods for distributed system scanning |
US8077699B2 (en) * | 2005-11-07 | 2011-12-13 | Microsoft Corporation | Independent message stores and message transport agents |
US7512408B2 (en) * | 2006-02-16 | 2009-03-31 | Softwired Ag | Scalable wireless messaging system |
US7739391B2 (en) * | 2006-02-16 | 2010-06-15 | Softwired Ag | Gateway for wireless mobile clients |
US7848261B2 (en) * | 2006-02-17 | 2010-12-07 | Isilon Systems, Inc. | Systems and methods for providing a quiescing protocol |
JP5068023B2 (ja) * | 2006-03-29 | 2012-11-07 | 株式会社日立製作所 | 計算機システム及び論理パス切替方法 |
US7756898B2 (en) | 2006-03-31 | 2010-07-13 | Isilon Systems, Inc. | Systems and methods for notifying listeners of events |
US8745503B2 (en) * | 2006-04-20 | 2014-06-03 | Hewlett-Packard Development Company, L.P. | Graphical interface for managing server environment |
GB0609997D0 (en) * | 2006-05-19 | 2006-06-28 | Ibm | Method, apparatus and computer program for controlling retention of data messages |
US20080005291A1 (en) * | 2006-06-01 | 2008-01-03 | International Business Machines Corporation | Coordinated information dispersion in a distributed computing system |
US7526543B2 (en) * | 2006-07-24 | 2009-04-28 | Raytheon Company | Method of synchronizing execution of state transition commands in a cluster of message oriented middleware servers |
US7953704B2 (en) | 2006-08-18 | 2011-05-31 | Emc Corporation | Systems and methods for a snapshot of data |
US7590652B2 (en) * | 2006-08-18 | 2009-09-15 | Isilon Systems, Inc. | Systems and methods of reverse lookup |
US7899800B2 (en) * | 2006-08-18 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7822932B2 (en) * | 2006-08-18 | 2010-10-26 | Isilon Systems, Inc. | Systems and methods for providing nonlinear journaling |
US7680842B2 (en) * | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7882071B2 (en) * | 2006-08-18 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7680836B2 (en) * | 2006-08-18 | 2010-03-16 | Isilon Systems, Inc. | Systems and methods for a snapshot of data |
US7770063B2 (en) * | 2006-08-26 | 2010-08-03 | International Business Machines Corporation | Simulation of failure recovery within clustered systems |
US8286029B2 (en) | 2006-12-21 | 2012-10-09 | Emc Corporation | Systems and methods for managing unavailable storage devices |
US7593938B2 (en) * | 2006-12-22 | 2009-09-22 | Isilon Systems, Inc. | Systems and methods of directory entry encodings |
US7509448B2 (en) * | 2007-01-05 | 2009-03-24 | Isilon Systems, Inc. | Systems and methods for managing semantic locks |
US7779048B2 (en) | 2007-04-13 | 2010-08-17 | Isilon Systems, Inc. | Systems and methods of providing possible value ranges |
US7900015B2 (en) | 2007-04-13 | 2011-03-01 | Isilon Systems, Inc. | Systems and methods of quota accounting |
US8966080B2 (en) | 2007-04-13 | 2015-02-24 | Emc Corporation | Systems and methods of managing resource utilization on a threaded computer system |
US8094669B2 (en) * | 2007-04-24 | 2012-01-10 | Oracle International Corporation | System and method for store and forward routing for distributed destinations |
US7877553B2 (en) * | 2007-08-06 | 2011-01-25 | Microsoft Corporation | Sharing volume data via shadow copies using differential areas |
US7966289B2 (en) | 2007-08-21 | 2011-06-21 | Emc Corporation | Systems and methods for reading objects in a file system |
US7949692B2 (en) * | 2007-08-21 | 2011-05-24 | Emc Corporation | Systems and methods for portals into snapshot data |
US7882068B2 (en) | 2007-08-21 | 2011-02-01 | Isilon Systems, Inc. | Systems and methods for adaptive copy on write |
US7856573B2 (en) * | 2007-08-31 | 2010-12-21 | International Business Machines Corporation | WPAR halted attack introspection stack execution detection |
US8954562B2 (en) * | 2007-09-28 | 2015-02-10 | Intel Corporation | Entropy-based (self-organizing) stability management |
US7996510B2 (en) * | 2007-09-28 | 2011-08-09 | Intel Corporation | Virtual clustering for scalable network control and management |
US8214847B2 (en) * | 2007-11-16 | 2012-07-03 | Microsoft Corporation | Distributed messaging system with configurable assurances |
US8200836B2 (en) * | 2007-11-16 | 2012-06-12 | Microsoft Corporation | Durable exactly once message delivery at scale |
US7984324B2 (en) * | 2008-03-27 | 2011-07-19 | Emc Corporation | Systems and methods for managing stalled storage devices |
US7949636B2 (en) | 2008-03-27 | 2011-05-24 | Emc Corporation | Systems and methods for a read only mode for a portion of a storage system |
US7870345B2 (en) | 2008-03-27 | 2011-01-11 | Isilon Systems, Inc. | Systems and methods for managing stalled storage devices |
US7953709B2 (en) * | 2008-03-27 | 2011-05-31 | Emc Corporation | Systems and methods for a read only mode for a portion of a storage system |
US9483911B2 (en) | 2008-04-30 | 2016-11-01 | Bally Gaming, Inc. | Information distribution in gaming networks |
US7543046B1 (en) * | 2008-05-30 | 2009-06-02 | International Business Machines Corporation | Method for managing cluster node-specific quorum roles |
US8412768B2 (en) * | 2008-07-11 | 2013-04-02 | Ball Gaming, Inc. | Integration gateway |
CN101668031B (zh) * | 2008-09-02 | 2013-10-16 | 阿里巴巴集团控股有限公司 | 一种消息处理方法及系统 |
US8060773B1 (en) * | 2009-12-16 | 2011-11-15 | Symantec Corporation | Systems and methods for managing sub-clusters within a multi-cluster computing system subsequent to a network-partition event |
US8671306B2 (en) * | 2010-12-21 | 2014-03-11 | Microsoft Corporation | Scaling out a messaging system |
JP5579650B2 (ja) * | 2011-04-28 | 2014-08-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 監視対象プロセスを実行する装置及び方法 |
CN103178984B (zh) * | 2011-12-26 | 2016-03-23 | 中国电信股份有限公司 | 一种通信设备及其异常处理方法 |
US8974305B2 (en) | 2012-01-18 | 2015-03-10 | Bally Gaming, Inc. | Network gaming architecture, gaming systems, and related methods |
EP2837158A4 (en) * | 2012-04-13 | 2015-12-16 | Goldman Sachs & Co | Systems and methods for scalable structured data distribution |
US8990375B2 (en) * | 2012-08-31 | 2015-03-24 | Facebook, Inc. | Subscription groups in publish-subscribe system |
EP2722345B1 (en) | 2012-10-18 | 2018-12-05 | Borealis AG | Catalyst for the polymerisation of olefins |
EP2722344B1 (en) | 2012-10-18 | 2017-03-22 | Borealis AG | Polymerisation process |
EP2722346A1 (en) | 2012-10-18 | 2014-04-23 | Borealis AG | Polymerisation process and catalyst |
US9189510B2 (en) | 2013-02-26 | 2015-11-17 | Facebook, Inc. | System and method for implementing cache consistent regional clusters |
US9419854B1 (en) * | 2013-06-27 | 2016-08-16 | The Boeing Company | Methods and systems for shared awareness through local observations and global state consistency in distributed and decentralized systems |
EP2829556B1 (en) | 2013-07-24 | 2016-11-16 | Borealis AG | Process |
EP2829558B1 (en) | 2013-07-24 | 2016-12-14 | Borealis AG | Process |
US9450992B2 (en) * | 2013-10-23 | 2016-09-20 | Facebook, Inc. | Node properties in a social-networking system |
US10044835B1 (en) | 2013-12-11 | 2018-08-07 | Symantec Corporation | Reducing redundant transmissions by polling clients |
FR3029643B1 (fr) * | 2014-12-09 | 2017-01-13 | ISKn | Procede de localisation d'au moins un objet magnetique mobile, et systeme associe |
CN105243012A (zh) * | 2015-09-11 | 2016-01-13 | 浪潮电子信息产业股份有限公司 | 一种基于linux的集群网络性能评估方法 |
US9860311B1 (en) * | 2015-09-17 | 2018-01-02 | EMC IP Holding Company LLC | Cluster management of distributed applications |
US10210027B1 (en) | 2015-09-17 | 2019-02-19 | EMC IP Holding Company LLC | Cluster management |
US11157517B2 (en) * | 2016-04-18 | 2021-10-26 | Amazon Technologies, Inc. | Versioned hierarchical data structures in a distributed data store |
US10671639B1 (en) | 2017-03-30 | 2020-06-02 | Amazon Technologies, Inc. | Selectively replicating changes to hierarchial data structures |
CN111757896B (zh) | 2017-12-21 | 2023-10-13 | 博里利斯股份公司 | 制备固体催化剂的方法 |
US11753486B2 (en) | 2017-12-28 | 2023-09-12 | Borealis Ag | Catalyst and preparation thereof |
CN110502342B (zh) * | 2019-08-16 | 2023-07-18 | 中科边缘智慧信息科技(苏州)有限公司 | 一种间歇网络环境下机动边缘信息服务网络 |
US10901820B1 (en) | 2020-01-07 | 2021-01-26 | International Business Machines Corporation | Error state message management |
CN112598052A (zh) * | 2020-12-21 | 2021-04-02 | 中建八局第二建设有限公司 | 一种基于K-Means的机械姿态分析方法及系统 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5913061A (en) | 1997-01-08 | 1999-06-15 | Crossroads Software, Inc. | Modular application collaboration |
US6449734B1 (en) * | 1998-04-17 | 2002-09-10 | Microsoft Corporation | Method and system for discarding locally committed transactions to ensure consistency in a server cluster |
US6785678B2 (en) * | 2000-12-21 | 2004-08-31 | Emc Corporation | Method of improving the availability of a computer clustering system through the use of a network medium link state function |
-
2001
- 2001-07-05 US US09/899,662 patent/US6877107B2/en not_active Expired - Lifetime
-
2002
- 2002-06-10 EP EP02732305A patent/EP1402363B1/en not_active Expired - Lifetime
- 2002-06-10 WO PCT/CH2002/000304 patent/WO2003005194A2/en not_active Application Discontinuation
- 2002-06-10 DE DE60207251T patent/DE60207251T2/de not_active Expired - Fee Related
- 2002-06-10 CN CNA028174275A patent/CN1552020A/zh active Pending
- 2002-06-10 AT AT02732305T patent/ATE309571T1/de not_active IP Right Cessation
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101681163B (zh) * | 2007-04-13 | 2015-02-25 | 西门子公司 | 使用模式规则的机器状态监控 |
CN102137032A (zh) * | 2011-03-24 | 2011-07-27 | 上海云高软件科技有限公司 | 一种云消息系统及云消息发送和接收方法 |
CN102137032B (zh) * | 2011-03-24 | 2015-03-11 | 上海云高软件科技有限公司 | 一种云消息系统及云消息发送和接收方法 |
CN104994168A (zh) * | 2015-07-14 | 2015-10-21 | 苏州科达科技股份有限公司 | 分布式存储方法及分布式存储系统 |
CN104994168B (zh) * | 2015-07-14 | 2018-05-01 | 苏州科达科技股份有限公司 | 分布式存储方法及分布式存储系统 |
CN111708668A (zh) * | 2020-05-29 | 2020-09-25 | 北京金山云网络技术有限公司 | 集群故障的处理方法、装置及电子设备 |
CN115379401A (zh) * | 2022-08-05 | 2022-11-22 | 中国银行股份有限公司 | 一种异步银行消息的处理方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
ATE309571T1 (de) | 2005-11-15 |
US6877107B2 (en) | 2005-04-05 |
WO2003005194A2 (en) | 2003-01-16 |
WO2003005194A3 (en) | 2003-12-11 |
DE60207251T2 (de) | 2007-05-16 |
EP1402363A2 (en) | 2004-03-31 |
US20030009511A1 (en) | 2003-01-09 |
DE60207251D1 (de) | 2005-12-15 |
EP1402363B1 (en) | 2005-11-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1552020A (zh) | 用于在集群式消息传递服务器中在节点故障以及网络划分期间确保操作的方法 | |
US7457236B2 (en) | Method for providing fault-tolerant application cluster service | |
US6651242B1 (en) | High performance computing system for distributed applications over a computer | |
US8055735B2 (en) | Method and system for forming a cluster of networked nodes | |
JP5254547B2 (ja) | ウェブ・アプリケーション・ミドルウェアのための非集中型のアプリケーション配置方法、並びにそのシステム及びコンピュータ・プログラム | |
US8225129B2 (en) | Methods and apparatus for effective on-line backup selection for failure recovery in distributed stream processing systems | |
US20060153068A1 (en) | Systems and methods providing high availability for distributed systems | |
CN1207674C (zh) | 在分布式计算环境中进行拓扑传播的方法和系统 | |
EP1810447B1 (en) | Method, system and program product for automated topology formation in dynamic distributed environments | |
CN101535977B (zh) | 联盟基础结构内的一致性 | |
US20100333094A1 (en) | Job-processing nodes synchronizing job databases | |
CN111314125A (zh) | 用于容错通信的系统和方法 | |
CN104205756A (zh) | 并发进程执行 | |
CN101309167A (zh) | 基于集群备份的容灾系统及方法 | |
JP2004519024A (ja) | 多数のノードを含むクラスタを管理するためのシステム及び方法 | |
CN102783094A (zh) | 用于基于会话发起协议的通信系统的弹性路由 | |
CN102946405A (zh) | Smb2扩展 | |
CN102932164A (zh) | 群集客户端故障转移 | |
JPH1040222A (ja) | 分散コンピューティング環境におけるプロセッサ・グループへの加入を管理するための方法 | |
CN111711526B (zh) | 一种区块链节点的共识方法及系统 | |
JPH1040229A (ja) | 分散コンピューティング環境におけるプロセッサ・グループへの加入を管理するためのシステム | |
JP2015138405A (ja) | 印刷システム、クラスタ環境における印刷制御方法および印刷制御用プログラム | |
CN112910937A (zh) | 容器集群中的对象调度方法、装置、服务器和容器集群 | |
CN111064672A (zh) | 云平台通信系统、选举方法及资源调度管理方法 | |
Rahman et al. | Modified bully algorithm using election commission |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
AD01 | Patent right deemed abandoned | ||
C20 | Patent right or utility model deemed to be abandoned or is abandoned |