CN110351122A - 容灾方法、装置、***与电子设备 - Google Patents

容灾方法、装置、***与电子设备 Download PDF

Info

Publication number
CN110351122A
CN110351122A CN201910521769.0A CN201910521769A CN110351122A CN 110351122 A CN110351122 A CN 110351122A CN 201910521769 A CN201910521769 A CN 201910521769A CN 110351122 A CN110351122 A CN 110351122A
Authority
CN
China
Prior art keywords
node
information
service
service node
new demand
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.)
Granted
Application number
CN201910521769.0A
Other languages
English (en)
Other versions
CN110351122B (zh
Inventor
侯焯明
刘林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201910521769.0A priority Critical patent/CN110351122B/zh
Publication of CN110351122A publication Critical patent/CN110351122A/zh
Application granted granted Critical
Publication of CN110351122B publication Critical patent/CN110351122B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1456Hardware arrangements for backup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

本公开提供一种容灾方法、装置及电子设备,涉及计算机技术领域。该容灾方法包括:将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数;接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的正整数;将所述M个第二信息中的一个发送给所述客户端。本公开提供的容灾方法可以提高客户端和服务器之间数据传递的可靠性,提高容灾能力。

Description

容灾方法、装置、***与电子设备
技术领域
本公开涉及计算机技术领域,具体而言,涉及一种容灾方法、装置、***与电子设备。
背景技术
容灾是为了在遭遇灾害时保证信息***正常运行、实现业务连续性而设计的一种运营方案。在相关技术中,通常使用主备服务节点切换方法来实现容灾,即在主服务节点出现故障时,将备份服务节点升级为新的主服务节点,接替原主服务节点的工作。主备切换方法一般通过人工或第三方服务实现。
在人工切换主服务节点和备份服务节点的过程中,各服务节点处于不可用状态,由于人工效率较低,服务节点处于不可用状态的时间较长,弊端较大。
基于第三方服务的主备切换方法需要把业务节点注册到第三方服务中,由第三方服务选出主服务节点或在主服务节点故障时选举出新的主服务节点,业务节点监听主服务节点的状态变化信息,并在备份服务节点升级为主服务节点时恢复相应的状态信息。这种方法需要在服务节点的代码上增加主服务节点切换事件的监听逻辑和主服务节点切换时业务状态的恢复逻辑,对于原有业务的代码入侵较大,增加了运维风险;当有服务节点中新业务加入时,还需要增加恢复服务节点状态过程中新业务的状态恢复代码,不利于维护***稳定。同时,该方法需要维护一个第三方服务,增加运维成本。最后,与人工方式相同,在主备节点切换过程中存在服务不可用状态,而且对于有状态的服务节点,在切换服务节点时,还需要将主服务节点的状态信息同步至该备份服务节点,数据可靠性较低。
需要说明的是,在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本公开实施例提供一种容灾方法、装置、***与电子设备,用于至少在一定程度上克服由于相关技术的限制和缺陷而导致的容灾方案存在服务不可用状态、可靠性不高等问题。
根据本公开的一个方面,提供一种容灾方法,由设置于服务器中的服务集群执行,所述服务集群包括主管理节点和一个以上备份管理节点,所述主管理节点用于执行所述容灾方法,所述备份管理节点用于在所述主管理节点出现故障时作为新的主管理节点的候选对象,所述容灾方法包括:
将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数;
接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的整数;
将所述M个第二信息中的一个发送给所述客户端。
在本公开的一种示例性实施例中,所述将所述M个第二信息中的一个发送给所述客户端包括:
将到达时间最早的所述第二信息发送给所述客户端。
在本公开的一种示例性实施例中,所述将所述M个第二信息中的一个发送给所述客户端还包括:
如果到达时间在后的第二信息与所述到达时间最早的第二信息相同,则丢弃所述到达时间在后的第二信息;
如果到达时间在后的第二信息与所述到达时间最早的第二信息不同,则通知所述到达时间在后的第二信息对应的服务节点关闭。
在本公开的一种示例性实施例中,所述将来自客户端的第一信息发送给N个对等的服务节点包括:将所述第一信息发送给全部所述备份管理节点;所述将所述M个第二信息中的一个发送给所述客户端还包括:将所述M个第二信息中的一个发送给全部所述备份管理节点。
在本公开的一种示例性实施例中,还包括:
响应服务节点注册请求确定待注册的新服务节点的识别符,所述服务节点注册请求包括所述新服务节点的执行文件加密值;
如果不存在与所述识别符对应的已注册服务节点,对所述新服务节点启动孤立节点注册流程;
如果存在与所述识别符对应的已注册服务节点,对比所述新服务节点的执行文件加密值与所述已注册服务节点的执行文件加密值是否一致;
如果一致,对所述新服务节点启动冗余节点注册流程;
如果不一致,拒绝所述服务节点注册请求。
在本公开的一种示例性实施例中,所述孤立节点注册流程包括:
确定所述新服务节点的最大已执行指令序号n1与缓存中对应于所述新服务节点的识别符的最大已接收指令序号n2的序号差的绝对值x;
如果x等于零,注册所述新服务节点;
如果x小于等于第一预设值,从缓存中调用序号为n1至n2的x个第一信息发送给所述新服务节点,在所述新服务节点执行完所述x个第一信息后,注册所述新服务节点;
如果x大于所述第一预设值,拒绝所述服务节点注册请求,其中n1、n2均为正整数。
在本公开的一种示例性实施例中,所述冗余节点注册流程包括:
确定所述新服务节点的最大已执行指令序号n1与所述已注册服务节点的最大已执行指令序号n3的序号差的绝对值y;
如果y等于零,注册所述新服务节点;
如果y小于等于第二预设值,从缓存中调用序号为n1至n3的y个第一信息发送给所述新服务节点,在所述新服务节点执行完所述y个第一信息后,注册所述新服务节点;
如果y大于所述第二预设值,从所述已注册服务节点中拷贝状态信息发送给所述新服务节点后,注册所述新服务节点,其中n1、n3均为正整数。
在本公开的一种示例性实施例中,所述注册所述新服务节点包括:
对所述新服务节点下发初始化信息,所述初始化信息包括随机种子和自驱动逻辑,所述自驱动逻辑包括所述管理节点的时间戳。
在本公开的一种示例性实施例中,所述将来自客户端的第一信息发送给N个对等的服务节点包括:
确定所述第一信息对应的服务节点的识别符;
根据所述识别符将所述第一信息发送给所述N个对等的服务节点。
在本公开的一种示例性实施例中,所述第二信息包括所述服务节点发送的第二信息的序号,所述接收来自所述N个对等的服务节点的M个第二信息包括:
在来自于服务节点的多个信息中,根据所述服务节点发送的第二信息的序号确定对应于所述第一信息的第二信息。
在本公开的一种示例性实施例中,所述N个对等的服务节点使用共享内存,每个所述服务节点在所述共享内存中具有独立的存储空间。
在本公开的一种示例性实施例中,在新服务节点为被关闭后重启的服务节点时,所述新服务节点重新启动时继续使用被关闭前在所述共享内存中使用的存储空间。
根据本公开的另一个方面,包括:
信息分发模块,设置为将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数;
信息接收模块,设置为接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的正整数;
信息发送模块,设置为将所述M个第二信息中的一个发送给所述客户端。
根据本公开的再一个方面,提供一种容灾***,包括:
至少一个客户端;
服务器集群,耦接于所述客户端,设置有服务集群,所述服务集群包括主管理节点和一个以上备份管理节点,所述备份管理节点用于在所述主管理节点出现故障时作为新的主管理节点的候选对象,所述主管理节点用于执行如上任一项所述的容灾方法。
根据本公开的又一个方面,提供一种电子设备,包括:
存储器;以及
耦合到所述存储器的处理器,所述处理器被配置为基于存储在所述存储器中的指令,执行如上述任意一项所述的容灾方法。
本公开实施例通过部署多个对等的服务节点,将待处理的第一信息同时分发给多个对等的服务节点,并根据各服务节点的处理结果确定反馈的第二信息,可以在一或多个服务节点出现故障时,利用正常的服务节点保障业务的正常处理,消除相关主备切换容灾方法存在的服务不可用状态。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。显而易见地,下面描述中的附图仅仅是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本公开示例性实施例中容灾***的示意图。
图2是本公开示例性实施例中容灾方法的流程图。
图3是本公开一个实施例中确定第一信息的反馈信息的流程图。
图4是本公开一个实施例中通过服务集群来实现容灾方法的示意图。
图5是本公开一个实施例中基于Paxos协议实现的服务集群的示意图。
图6是本公开一个实施例中服务节点的注册流程图。
图7A是本公开一个实施例中服务节点具有状态时的孤立节点注册流程的流程图。
图7B是本公开一个实施例中服务节点具有状态时的冗余节点注册流程的流程图。
图8是本公开一个实施例中服务节点注册过程中的交互示意图。
图9是本公开一个实施例中节点注册的示意图。
图10是本公开一个实施例中对服务节点进行初始化的示意图。
图11是本公开一个实施例中主管理节点(Master Gdriver)对上行数据包进行管理的示意图。
图12是本公开一个实施例中主管理节点(Master Gdriver)对下行数据包进行管理的示意图。
图13是本公开一个应用场景的示意图。
图14是本公开一个示例性实施例中一种容灾装置的方框图。
图15是本公开一个示例性实施例中一种电子设备的方框图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本公开将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中,提供许多具体细节从而给出对本公开的实施方式的充分理解。然而,本领域技术人员将意识到,可以实践本公开的技术方案而省略所述特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
此外,附图仅为本公开的示意性图解,图中对等的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体,不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
图1是本公开实施例中容灾***100的示意图。本公开实施例的容灾方法或容灾装置可以应用于容灾***100.
参考图1,容灾***100可以包括:
至少一个客户端A;
服务器集群B,耦接于客户端A,设置有服务集群,服务集群包括主管理节点和一个以上备份管理节点,备份管理节点用于在主管理节点出现故障时作为新的主管理节点的候选对象,主管理节点用于执行下述实施例的容灾方法。
如图1所示,客户端A例如可以为具有显示屏的各种电子设备,包括但不限于智能手机、平板电脑、便携式计算机和台式计算机等等。客户端A和服务器集群B之间可以使用网络提供通信链路的介质进行耦接,使客户端A能够向服务器集群B发送第一信息或接收服务器集群B发送的第二信息。网络可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
应该理解,图1中的客户端A、网络和服务器集群B的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端、网络和服务器。
服务器集群B中可以设置有多个对等的服务节点,这些服务节点例如可以为应用程序的进程,多个服务节点设置在一或多台服务器中。
本公开实施例所提供的容灾方法可以由服务器集群B执行,相应地,容灾装置可以设置于服务器集群B中。
下面结合附图对本公开示例实施方式进行详细说明。
图2是本公开示例性实施例中容灾方法的流程图。参考图2,容灾方法200可以包括:
步骤S1,将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数。
步骤S2,接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的正整数。
步骤S3,将所述M个第二信息中的一个发送给所述客户端。
在本公开实施例中,第一信息、第二信息的形式例如可以为消息/数据包,当第一信息、第二信息为数据包时,第一信息可被称为上行数据包,第二信息可被称为下行数据包。
本公开实施例通过部署多个对等的服务节点,将待处理信息同时分发给多个对等的服务节点,根据多个对等的服务节点发送的冗余信息确定对客户端发送的信息,可以在部分服务节点出现故障时,通过其余正常的服务节点保障业务的正常处理,消除相关主备切换容灾方法存在的服务不可用状态;而且,由于仅对信息的输入输出进行管理,对于业务代码的入侵较少;由于多个服务节点处理的信息相同,在一或多个服务节点出现故障时也可以保持业务处理及状态更新,可以避免由于服务节点故障、服务状态丢失而引起的***不可用灾难。
下面,对图2所示实施例的各步骤进行详细说明。
在步骤S1,将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数。
在本公开实施例中,对等的服务节点指的是拥有一致的执行逻辑和一致的初始化条件的服务节点。在一些实施例中,N个对等的服务节点可以部署在一台或多台服务器上。
当服务节点是一个应用程序的进程时,启动一个应用程序则对应启动一个服务节点。同一时间内服务器上可能存在对应于多个应用程序的多个服务节点。此时,可以首先确定第一信息对应的服务节点的识别符(例如应用程序的编号或名称),再将第一信息发送给该识别符对应的N个对等的服务节点。
在步骤S2,接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的正整数。
在本公开实施例中,第二信息既可以是服务节点主动发送给客户端的信息,也可以是服务节点响应第一信息发送给客户端的反馈信息,本公开不以此为限。
在示例性实施例中,第二信息包括发送第二信息的服务节点的识别符和服务节点发送的第二信息的序号,可以在来自于服务节点的多个信息中,根据服务节点发送的第二信息的序号确定对应于该第一信息的第二信息。
例如,服务节点1、2、3、……、N分别发送的第二信息中,分别包括服务节点发送的第二信息的序号99、99、99、……、99,其中99指该第二信息是服务节点1发送的第99条信息,其他服务节点相同。以上数值仅为示例,本公开不以此为限。
在步骤S3,将所述M个第二信息中的一个发送给所述客户端。
在本公开实施例中,可以将最早到达的第二信息中发送给客户端,如果到达时间在后的第二信息与到达时间最早的第二信息相同,丢弃到达时间在后的第二信息,否则通知到达时间在后的第二信息对应的服务节点关闭。
由于服务节点对等,如果各服务节点均正常运行,第二信息(下行数据包)应该全部相同,此时剔除冗余,取第一个到达的第二信息发送给客户端;如果部分服务节点出现故障,例如发送错误的第二信息或不发送第二信息,则以第一个到达的第二信息为标准对到达时间在后的第二信息进行检验,只要到达时间在后的第二信息与到达时间最早的第二信息不相同,则判断到达时间在后的第二信息为错误信息,通知到达时间在后的第二信息对应的服务节点关闭。
图3是本公开一个实施例中确定第一信息的反馈信息的流程图。
参考图3,步骤S3可以包括:
步骤S31,将到达时间最早的第二信息发送给客户端。
步骤S32,判断到达时间在后的第二信息与到达时间最早的第二信息是否相同,如果相同进入步骤S33;否则进入步骤S34。
步骤S33,丢弃到达时间在后的第二信息。
步骤S34,通知到达时间在后的第二信息对应的服务节点关闭。
其中,可以根据第二信息中包括的服务节点的识别符通知到达时间在后的第二信息对应的服务节点关闭。
如果第二信息是服务节点对第一信息的反馈信息,由于服务节点对等、输入信息相同,各对等的服务节点输出的第二信息应该相同;如果第二信息是服务节点主动向客户端发送的信息,各对等的服务节点输出的第二信息也应该相同。
但是在一些情况中,有可能存在服务节点故障导致的信息接收错误、信息处理错误、信息发送错误等种种错误情况,进而导致故障服务节点发送的第二信息与其他正常服务节点发送的第二信息不同,此时需要通过错误的第二信息将故障服务节点识别出来,并通知故障服务节点关闭。
通知故障服务节点关闭可以提高下一次识别第二信息的效率,通知的方式例如可以为通知该服务节点下线,或者清除该服务节点的注册信息等。在其他一些实施例中,还可以为通知错误信息对应的服务节点重新启动等,本领域技术人员可以根据实际情况自行设置。
在上述实施例提供的方法中,由于第二信息冗余,只要不是全部服务节点均出现故障,就不会影响反馈信息的正常传递。即使各服务节点是有状态的节点,由于对等的服务节点具有相同的输入,各对等的服务节点的状态变化过程和最新状态也相同,即使部分服务节点故障,也不会导致其他服务节点的状态丢失或不同步。因此,相比于相关技术中切换主备服务节点所造成的服务不可用缺陷,或者无法在服务节点出现故障时准确无误地同步服务节点的状态,本公开实施例提供的技术方案具有更高的可靠性和更好的用户体验。
在本公开一个实施例中,容灾方法200可以由设置于服务器中的服务集群执行。
图4是本公开一个实施例中通过服务集群400来实现容灾方法200的示意图。
参考图4,服务集群400包括一个主管理节点41和一或多个备份管理节点42,主管理节点41用于执行容灾方法200,备份管理节点42用于在主管理节点41出现故障时作为新的主管理节点的候选对象。
服务集群400可以设置在一台或多台服务器上,各管理节点可以设置在相同或不同服务器上。当各管理节点设置在不同服务器上时,服务集群400可以设置各服务器之间的通讯渠道,以便实现多个管理节点的数据同步。
在工作时,服务集群400首先在多个管理节点中选取一个管理节点作为主管理节点41,并将其他管理节点设置为备份管理节点42。为了备份管理节点42能够在主管理节点41故障时及时接替工作、同步数据,主管理节点41在接收到客户端1或服务节点2发来的信息时,可以通过服务集群协议对全部备份管理节点同步。
如图4所示,客户端1和服务节点2只与主管理节点41交互。主管理节点41对客户端1和服务节点2输出信息、接收客户端1和服务节点2发送的信息。同时,主管理节点41将客户端1和服务节点2的输入信息和输出信息通过服务集群协议提交到服务集群400,例如主管理节点41可以将客户端1和服务节点2的输入信息和输出信息经Paxos协议提交到服务集群400以便将第一信息或第二信息同步至全部备份管理节点。在一些实施例中,主管理节点41收到第一信息时,可以首先将第一信息同步至全部备份管理节点,在接收到备份管理节点的响应后,将第一信息分发给N个对等的服务节点2;主管理节点41收到第二信息时,可以首先将第二信息同步至全部备份管理节点,在接收到备份管理节点的响应后,将第二信息发送给客户端1。或者,上述将发送数据至客户端/服务节点的过程和将数据同步至备份管理节点的过程也可以同时进行。
服务集群400实时监控主管理节点41的工作状态,当主管理节点41出现故障时,立即在多个备份管理节点42中选取一个新的主管理节点,并自动将客户端1和服务节点2的路由地址切换到新的主管理节点。
由于服务集群400本身也支持容灾,为***的可靠性提供了进一步的保障。此外,由于添加服务集群400仅需修改信息收发逻辑,代码修改量小,对于原业务逻辑入侵较小,能够有效避免相关技术中存在的代码修改量大、增加***故障风险等问题。
在一些实施例中,服务集群400可以基于Paxos协议实现,各管理节点例如可以通过Gdriver节点实现。
图5是一个实施例中基于Paxos协议实现的服务集群的示意图。
参考图5,Paxos集群500选举一个Gdriver节点作为主管理节点51(MasterGdriver),将客户端和服务进程的路由地址设置为主管理节点(Master Gdriver)的地址。主管理节点51接收来自客户端1的第一信息(Log,既是Paxos的binLog也是业务消息)并分发至多个对等的服务节点20(服务节点),将服务节点20发送的多个第二信息(Log)中的一个发送给客户端10。主管理节点51和备份管理节点52之间通过Paxos协议同步数据,主管理节点51将接收至客户端10的第一信息、接收至服务节点20的第二信息中的一个同步给全部备份管理节点52。
每个管理节点拥有一个本地Log池,Log池中的信息序号严格递增,Paxos集群保证所有管理节点的Log池完全一致。
为了确保多个对等的服务节点完全相同,在本公开实施例中,服务集群还用于管理各服务节点的同步、注册、驱动。
服务节点启动后,可以向服务集群注册,从而服务集群在接收到对应于该服务节点的识别符的第一信息时,可以将该第一信息发送给所有已注册的服务节点。为了保障同一识别符对应的已注册服务节点完全一致,在服务节点的注册过程中,可以对服务节点进行校验。
图6是本公开一个实施例中服务节点的注册流程图。
参考图6,服务节点的注册过程可以包括:
步骤S61,响应服务节点注册请求确定待注册的新服务节点的识别符,服务节点注册请求包括新服务节点的执行文件加密值;
步骤S62,判断是否存在与识别符对应的已注册服务节点,如果不存在,进入步骤S63对新服务节点启动孤立节点注册流程,否则进入步骤S64;
步骤S64,对比新服务节点的执行文件加密值与已注册服务节点的执行文件加密值是否一致,如果一致,进入步骤S65,否则进入步骤S66;
步骤S65,对新服务节点启动冗余节点注册流程;
步骤S66,拒绝服务节点注册请求。
上述执行文件加密值例如可以为MD5(Message-Digest Algorithm,消息摘要算法)值,本公开对此不作特殊限定。
执行图6所示流程可以剔除所有执行文件与已注册节点不同的节点,初步保证了新服务节点与已注册服务节点的一致性。在服务节点不具有状态时,步骤S63中的孤立节点注册流程和步骤S65中的冗余节点注册流程可以为直接注册新服务节点,但是在服务节点具有状态时,还需要对新服务节点的状态进行调整。
图7A是服务节点具有状态时的孤立节点注册流程的流程图。
参考图7A,在服务节点具有状态时,孤立节点注册流程可以包括:
步骤S71,确定所述新服务节点的最大已执行指令序号n1与缓存中对应于所述新服务节点的识别符的最大已接收指令序号n2的序号差的绝对值x;
步骤S72,如果x等于零,注册所述新服务节点;
步骤S73,如果x小于等于第一预设值,从缓存中调用序号为n1至n2的x个第一信息发送给所述新服务节点,在所述新服务节点执行完所述x个第一信息后,注册所述新服务节点;
步骤S74,如果x大于所述第一预设值,拒绝所述服务节点注册请求。
不论新服务节点是冷启动(已执行指令记录为零)还是热启动(关闭后重新启动,加载关闭前的已执行指令记录),在注册新服务节点之前,都需要根据主管理节点已接收到的对新服务节点对应的第一信息(指令)来调整新服务节点的状态,从而确保新服务节点成功注册后状态正常,能对新的第一信息给出正确的反馈。
为了方便管理与记录各服务节点在重启前后的状态,在本公开一个实施例中可以设置供多个服务节点共同使用的共享内存,在共享内存中为每个服务节点设置独立的存储空间。由此,当服务节点重新启动时可以继续使用被关闭前在共享内存中使用的存储空间,有利于重启的服务节点及时恢复状态。
主管理节点对已接收的第一信息编号,存储在缓存(Log缓存池)中,服务节点对已处理的第一信息编号,存储在共享内存中,重启时读取最大已执行指令序号,根据共享内存中的记录恢复状态至关闭前。
如果新服务节点的最大已执行指令序号与缓存中最大已接收指令序号相同,说明在新服务节点关闭重启过程中或者在新服务节点冷启动之前主管理节点并未接收到新的第一信息,此时可以直接注册新服务节点。
如果新服务节点的最大已执行指令序号与缓存中最大已接收指令序号相差较小(x小于等于第一预设值),说明在新服务节点关闭重启过程中或者在新服务节点冷启动之前主管理节点接收到少量新的第一信息,此时可以从缓存中读取这些新的第一信息(x个),并按顺序将其发送给新服务节点,供新服务节点按序处理后获得最新状态,然后注册该新服务节点。其中,第一预设值可以由本领域技术人员自行设置,例如为缓存中能存储的第一信息数量的最大值。
如果新服务节点的最大已执行指令序号与缓存中最大已接收指令序号相差较大(x大于第一预设值),说明在新服务节点关闭重启过程中或者在新服务节点冷启动之前主管理节点接收到了大量新的第一信息,由于缓存存储容量有限,无法获得全部这些新的第一信息,即无法恢复新服务节点的状态至最新状态,此时只能拒绝新服务节点的注册。
图7B是服务节点具有状态时的冗余节点注册流程的流程图。
参考图7B,在服务节点具有状态时,冗余节点注册流程可以包括:
步骤S75,确定所述新服务节点的最大已执行指令序号n1与所述已注册服务节点的最大已执行指令序号n3的序号差的绝对值y;
步骤S76,如果y等于零,注册所述新服务节点;
步骤S77,如果y小于等于第二预设值,从缓存中调用序号为n1至n3的y个第一信息发送给所述新服务节点,在所述新服务节点执行完所述y个第一信息后,注册所述新服务节点;
步骤S78,如果y大于所述第二预设值,从所述已注册服务节点中拷贝状态信息发送给所述新服务节点后,注册所述新服务节点。
当已注册服务节点已经处理了一些第一信息时,各已注册服务节点的状态已经发生了改变,此时需要使新服务节点同样执行已注册服务节点已处理的第一信息,及时调整新服务节点的状态和已注册服务节点一致,注册新服务节点,才能保持所有已注册的服务节点完全相同。
在一些情况下,新服务节点是被关闭后重启的服务节点,此时新服务节点可以读取关闭前的节点状态等数据,根据这些数据将状态恢复到被关闭前。在另一些情况下,新服务节点的启动状态可以为冷启动,没有信息执行记录(即n1=0)。
在计算新服务节点的最大已执行指令序号n1与已注册服务节点的最大已执行指令序号n3的序号差的绝对值y时,如果该新服务节点在关闭重启过程中或冷启动时其他对等的服务节点并未处理新的第一信息时,新服务节点已处理的最大已执行指令序号n1有可能与已注册服务节点的最大已执行指令序号n3相同,即y=0。此时可以直接注册该新服务节点。
在另一些情况下,如果该新服务节点在关闭重启过程中或冷启动时其他对等的服务节点仅处理了少量新的第一信息,例如少于等于第二预设值个,可以从缓存中读取这些新的第一信息(y个),并按顺序将其发送给新服务节点,供新服务节点按序处理后获得与已处理节点一致的状态,然后注册该新服务节点。
由于缓存能够存储的数据量较少,当该新服务节点在关闭重启过程中或冷启动时其他对等的服务节点处理了较多新的第一信息,例如多于第二预设值个时,可以从已注册服务节点中拷贝状态信息并复制到新服务节点中,以实现新服务节点的和已注册服务节点的状态的快速同步。
在一些实施例中,第二预设值既可以与第一预设值相同,也可以不同。第二预设值可以由本领域技术人员自行设置,例如可以为缓存中能存储的第一信息数量的最大值,或者,也可以根据缓存中能存储的第一信息数量的最大值、从缓存中读取第一信息并同步至新服务节点的时间T1和从已注册服务节点中拷贝状态信息并复制到新服务节点的时间T2的临界值来确定。
图8是本公开一个实施例中服务节点注册过程中的交互示意图。
参考图8,服务节点注册过程中,首先由新服务节点向主管理节点发送服务节点注册请求,该服务节点注册请求包括新服务节点的识别符(ID,Identity document)和执行文件加密值(MD5)。
主管理节点判断该ID是否对应已注册节点,如果否,判断新服务节点的最大已执行指令序号n1与缓存中对应于新服务节点的识别符的最大已接收指令序号n2的序号差的绝对值x是否等于零,如果等于零,注册该新服务节点并对新服务节点发送服务节点注册消息;如果不等于零,判断x是否小于等于第一预设值,如果否,对服务节点发送服务节点注册拒绝消息,如果是,从缓存中读取最近x个第一信息并发送给新服务节点,在新服务节点执行完该第一信息并发送第一信息执行完毕消息后,注册新服务节点并对新服务节点发送服务节点注册消息。
如果该ID对应已注册节点,判断新服务节点与已注册服务节点的MD5值是否一致,如果不一致,对新服务节点发送服务节点注册拒绝消息;如果一致,判断新服务节点的最大已执行指令序号n1与已注册服务节点的最大已执行指令序号n3的序号差的绝对值y是否等于零,如果等于零,注册该新服务节点并对新服务节点发送服务节点注册消息,如果不等于零,判断y是否小于第二预设值。如果y小于等于第二预设值,从缓存中读取最近y个第一信息并发送给新服务节点,在新服务节点执行完该第一信息并发送第一信息执行完毕消息后,注册新服务节点并对新服务节点发送服务节点注册消息;如果y大于第二预设值,向已注册服务节点发送状态信息拷贝指令,在已注册服务节点拷贝状态信息并发送给新服务节点、新服务节点填充状态信息并发送状态信息填充完毕反馈后,注册新服务节点并对新服务节点发送服务节点注册消息。
图9是本公开一个实施例中节点注册的示意图。
参考图9,节点注册过程中服务节点92可以向主管理节点91(Gdriver)传输可执行文件加密值(MD5值)和最大已执行指令序号,供主管理节点91检验该服务节点是否与已注册节点完全相同。
确定注册新服务节点后,为了保持识别符对等的服务节点的完全一致,服务集群可以对新服务节点下发初始化信息,初始化信息包括随机种子和自驱动逻辑,自驱动逻辑包括管理节点的时间戳。
举例来说,服务节点(Application Node,应用程序节点)作为一个业务节点,内部会有一个自驱动的逻辑(Tick操作)以及一些时间判断的逻辑,为了保证每个服务节点的状态一致,需要统一每个服务节点的时间和Tick逻辑,在本公开的一个实施例中将这两个操作统一放到服务集群中进行管理,由主管理节点(Master Gdriver)驱动服务节点的Tick操作并下发时间戳。
图10是本公开一个实施例中对服务节点进行初始化的示意图。
参考图10,主管理节点101(Master Gdriver)通过上行Log循环缓冲池将Tick请求发送给服务节点102,每个Tick请求中包含服务集群的时间戳。Tick请求的时间间隔例如可以配置为10ms一次。服务节点102使用主管理节点101(Master Gdriver)发送的时间来取代***时间函数(hook time/gettimeofday),如图中的“管理设置时间”是主管理节点101下发的时间(精确到毫秒)。
初始化完成后,各服务节点完全相同。结合上述实施例,每个服务节点均成为了一个独立的“状态机”,每个状态机拥有一致的初始化、一致的执行逻辑,只要保证一致的输入,就可以得到一致的响应和数据,从而实现有状态服务的容灾。
图11是本公开一个实施例中主管理节点(Master Gdriver)对上行数据包进行管理的示意图。
参考图11,客户端111本地可以设置一个较小的Log循环缓冲池(主要用于重发,一般是管理节点切换的时候才会用到)。客户端111产生的Log(一个第一信息对应一条Log)被发送到服务器后,会被主管理节点112(Master Gdriver)打上递增的第一序号,由此主管理节点112(Master Gdriver)可以记录每个客户端111发送的信息的最大第一序号,根据一个客户端发送的Log的第一序号与已记录的其最大第一序号是否连续来检测是否漏包,如果第一序号不连续则判断漏包,通知客户端重发Log。在一些实施例中,主管理节点对于客户端的漏包是可以跳过的,因此客户端内部Log队列的容量可以较小且非必须。
需要注意的是,在主管理节点的缓存中,每个客户端均拥有一个第一序号,每个服务节点的识别符均拥有一个最大已接收指令序号,这两个序号对应的对象不同。
主管理节点112(Master Gdriver)将所有客户端发送的Log汇集到上行Log队列中发送,并对每个Log打上新的递增的第二序号。服务节点113记录已经执行的Log的最大第二序号,对主管理节点112发送的Log检查是否漏包,如果漏包则通知主管理节点112重发。服务节点113对漏包零容忍,不能跳过任何一个数据包,由于要缓存所有客户端最近的请求包,且各管理节点与主管理节点的Log缓冲池容量、内容一致,因此各管理节点的Log缓冲池可以设置为较大。
图12是本公开一个实施例中主管理节点(Master Gdriver)对下行数据包进行管理的示意图。
参考图12,各服务节点121均在本地设置有一个本地Log循环缓冲池(用于重发下行Log,容量可以设置为较小,非必须)。各服务节点121在本地对下行数据包(第二信息)打上递增的第三序号,主管理节点122(Master Gdriver)根据第三序号相同来确定这些下行数据包为对同一个上行数据包(第一信息)的响应或者来自状态相同的服务节点121的主动发送。
对具有同一个第三序号的多个下行数据包,主管理节点122(Master Gdriver)可以只取最先到达的下行数据包下发给客户端123,将后到达的下行数据包与第一个同序号的数据包进行对比(方式例如为使用memcmp函数比较),如果后达到的下行数据包与第一个同序号的下行数据包不一致,则认为在后下行数据包对应的服务节点的状态出现问题,可以通知在后下行数据包对应的服务节点下线。客户端123可以在本地记录已收到的下行数据包的最大第三序号,进而通过第三序号是否连续来检测漏包,如果漏包则通知主管理节点(Master Gdriver)重发(可跳包)。
图13是本公开一个应用场景的示意图。
参考图13,在一个应用场景中,本公开实施例可以应用于***的服务集群11。服务集群11通过多台服务器13实现,服务集群11通过服务器13连接多个客户端12,客户端12例如可以为手机、平板电脑等移动终端。在图12所示实施例中,每台服务器13上例如设置有服务集群11中的一个管理节点(主管理节点111或备份管理节点112)和一个服务节点131。
服务集群11中的主管理节点111接收客户端12发送的第一信息,将其分发给位于多台服务器13中的多个对等的服务节点131;主管理节点111将多个对等的服务节点131发送的多个第二信息中的一个发送给客户端12,从而,在部分服务器或服务节点出现故障时,可以保障客户端12的指令能被正确执行且能收到正确反馈,或者,保障服务节点对客户端12传送消息的正常执行。
此外,主管理节点111在接收第一信息或第二信息时将第一信息和第二信息同步给全部备份管理节点112,从而服务集群11可以在监控到主管理节点111出现故障时,在多个备份管理节点112中选举出新的主管理节点,使备份管理节点能够及时进入工作状态。通过服务节点和管理节点的双重冗余设计,提高了容灾能力,增加了***的可靠性。
在***架构设计中小区部分进程往往是有状态的,并且无法去除状态,在整个***运行的过程中,这些有状态的进程作为单点存在,当其中一个进程故障的时候,会导致部分服务不可用,严重时会导致小区停服。
使用本公开实施例提供的容灾方法管理客户端与服务器之间的通讯时,服务集群11将客户端12发送的消息分发给多个完全对等的活动服务节点131,根据这些服务节点131发送的多个信息对客户端12发送信息,即使部分服务节点或服务器出现故障,服务器集群11同样可以通过剩余活动服务节点的反馈选出正确的反馈信息,不会导致服务不可用或者服务节点的状态丢失,不影响玩家正常体验游戏,即可以在不去除状态的情况下实现对有状态的服务进程的容灾,提高***的可用性。另外,本方法也适用于其他存在有状态服务是单点的问题的业务。
综上所述,本公开实施例提供的方法可以实现有状态服务的容灾,解决有状态服务单点故障导致***故障的问题,提高了整个***的可用性。
对应于上述方法实施例,本公开还提供一种容灾装置,可以用于执行上述方法实施例。
图14是本公开一个示例性实施例中一种容灾装置的方框图。
参考图14,本公开实施例提供的容灾装置1400可以包括:信息分发模块1402,可以设置为将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数;信息接收模块1404,可以设置为接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的正整数;信息发送模块1406,可以设置为将所述M个第二信息中的一个发送给所述客户端。
在示例性实施例中,容灾装置1400设置于服务集群中,所述服务集群包括主管理节点和一个以上备份管理节点,所述主管理节点用于执行所述容灾方法,所述备份管理节点用于在所述主管理节点出现故障时作为新的主管理节点的候选对象。
在示例性实施例中,信息分发模块1402设置为:确定所述第一信息对应的服务节点的识别符,根据所述识别符将所述第一信息发送给所述N个对等的服务节点。
在示例性实施例中,所述第二信息包括所述服务节点发送的第二信息的序号,信息接收模块1404设置为:在来自于服务节点的多个信息中,根据所述服务节点发送的第二信息的序号确定对应于所述第一信息的第二信息。
在示例性实施例中,信息发送模块1406设置为:将到达时间最早的所述第二信息发送给所述客户端。
在示例性实施例中,信息发送模块1406设置为:如果到达时间在后的第二信息与所述到达时间最早的第二信息相同,丢弃所述到达时间在后的第二信息,否则通知所述到达时间在后的第二信息对应的服务节点关闭。
在示例性实施例中,容灾装置1400还包括节点注册模块1408,节点注册模块1408设置为:响应服务节点注册请求确定待注册的新服务节点的识别符,所述服务节点注册请求包括所述新服务节点的执行文件加密值;如果不存在与所述识别符对应的已注册服务节点,对所述新服务节点启动孤立节点注册流程;否则,对比所述新服务节点的执行文件加密值与所述已注册服务节点的执行文件加密值是否一致;如果一致,对所述新服务节点启动冗余节点注册流程;如果不一致,拒绝所述服务节点注册请求。
在示例性实施例中,孤立节点注册流程包括:确定新服务节点的最大已执行指令序号n1与缓存中对应于新服务节点的识别符的最大已接收指令序号n2的序号差的绝对值x;如果x等于零,注册新服务节点;如果x小于等于预设值,从缓存中调用序号为n1至n2的x个第一信息发送给新服务节点,在新服务节点执行完x个第一信息后,注册新服务节点;如果x大于预设值,拒绝服务节点注册请求。
在示例性实施例中,冗余节点注册流程包括:确定新服务节点的最大已执行指令序号n1与已注册服务节点的最大已执行指令序号n3的序号差的绝对值y;如果y等于零,注册新服务节点;如果y小于等于预设值,从缓存中调用序号为n1至n3的y个第一信息发送给新服务节点,在新服务节点执行完y个第一信息后,注册新服务节点;如果y大于预设值,从已注册服务节点中拷贝状态信息发送给新服务节点后,注册新服务节点。
在示例性实施例中,节点注册模块1408设置为:对所述新服务节点下发初始化信息,所述初始化信息包括随机种子和自驱动逻辑,所述自驱动逻辑包括所述管理节点的时间戳。
在示例性实施例中,信息分发模块1402设置为:将所述第一信息发送给全部所述备份管理节点;信息发送模块1406设置为:将所述M个第二信息中的一个发送给全部所述备份管理节点。
在示例性实施例中,所述N个对等的服务节点使用共享内存,每个所述服务节点在所述共享内存中具有独立的存储空间。
在示例性实施例中,在新服务节点为被关闭后重启的服务节点时,所述新服务节点重新启动时继续使用被关闭前在所述共享内存中使用的存储空间。
由于装置1400的各功能已在其对应的方法实施例中予以详细说明,本公开于此不再赘述。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
在本公开的示例性实施例中,还提供了一种能够实现上述方法的电子设备。
所属技术领域的技术人员能够理解,本发明的各个方面可以实现为***、方法或程序产品。因此,本发明的各个方面可以具体实现为以下形式,即:完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等),或硬件和软件方面结合的实施方式,这里可以统称为“电路”、“模块”或“***”。
下面参照图15来描述根据本发明的这种实施方式的电子设备1500。图15显示的电子设备1500仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。
如图15所示,电子设备1500以通用计算设备的形式表现。电子设备1500的组件可以包括但不限于:上述至少一个处理单元1510、上述至少一个存储单元1520、连接不同***组件(包括存储单元1520和处理单元1510)的总线1530。
其中,所述存储单元存储有程序代码,所述程序代码可以被所述处理单元1510执行,使得所述处理单元1510执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如,所述处理单元1510可以执行如图2中所示的步骤。
存储单元1520可以包括易失性存储单元形式的可读介质,例如随机存取存储单元(RAM)15201和/或高速缓存存储单元15202,还可以进一步包括只读存储单元(ROM)15203。
存储单元1520还可以包括具有一组(至少一个)程序模块15205的程序/实用工具15204,这样的程序模块15205包括但不限于:操作***、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。
总线1530可以为表示几类总线结构中的一种或多种,包括存储单元总线或者存储单元控制器、***总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
电子设备1500也可以与一个或多个外部设备1600(例如键盘、指向设备、蓝牙设备等)通信,还可与一个或者多个使得用户能与该电子设备1500交互的设备通信,和/或与使得该电子设备1500能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1550进行。并且,电子设备1500还可以通过网络适配器1560与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。如图所示,网络适配器1560通过总线1530与电子设备1500的其它模块通信。应当明白,尽管图中未示出,可以结合电子设备1500使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本公开实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。
上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明,而不是限制目的。易于理解,上述附图所示的处理并不表明或限制这些处理的时间顺序。另外,也易于理解,这些处理可以是例如在多个模块中同步或异步执行的。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的真正范围和构思由权利要求指出。

Claims (15)

1.一种容灾方法,其特征在于,由设置于服务器中的服务集群执行,所述服务集群包括主管理节点和一个以上备份管理节点,所述主管理节点用于执行所述容灾方法,所述备份管理节点用于在所述主管理节点出现故障时作为新的主管理节点的候选对象,所述容灾方法包括:
将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数;
接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的正整数;
将所述M个第二信息中的一个发送给所述客户端。
2.如权利要求1所述的容灾方法,其特征在于,所述将来自客户端的第一信息发送给N个对等的服务节点包括:将所述第一信息发送给全部所述备份管理节点;所述将所述M个第二信息中的一个发送给所述客户端还包括:将所述M个第二信息中的一个发送给全部所述备份管理节点。
3.如权利要求1所述的容灾方法,其特征在于,所述将所述M个第二信息中的一个发送给所述客户端包括:
将到达时间最早的所述第二信息发送给所述客户端。
4.如权利要求3所述的容灾方法,其特征在于,所述将所述M个第二信息中的一个发送给所述客户端还包括:
如果到达时间在后的第二信息与所述到达时间最早的第二信息相同,则丢弃所述到达时间在后的第二信息;
如果到达时间在后的第二信息与所述到达时间最早的第二信息不同,则通知所述到达时间在后的第二信息对应的服务节点关闭。
5.如权利要求1所述的容灾方法,其特征在于,还包括:
响应服务节点注册请求确定待注册的新服务节点的识别符,所述服务节点注册请求包括所述新服务节点的执行文件加密值;
如果不存在与所述识别符对应的已注册服务节点,对所述新服务节点启动孤立节点注册流程;
如果存在与所述识别符对应的已注册服务节点,对比所述新服务节点的执行文件加密值与所述已注册服务节点的执行文件加密值是否一致;
如果一致,对所述新服务节点启动冗余节点注册流程;
如果不一致,拒绝所述服务节点注册请求。
6.如权利要求5所述的容灾方法,其特征在于,所述孤立节点注册流程包括:
确定所述新服务节点的最大已执行指令序号n1与缓存中对应于所述新服务节点的识别符的最大已接收指令序号n2的序号差的绝对值x;
如果x等于零,注册所述新服务节点;
如果x小于等于第一预设值,从缓存中调用序号为n1至n2的x个第一信息发送给所述新服务节点,在所述新服务节点执行完所述x个第一信息后,注册所述新服务节点;
如果x大于所述第一预设值,拒绝所述服务节点注册请求,其中n1、n2均为正整数。
7.如权利要求5所述的容灾方法,其特征在于,所述冗余节点注册流程包括:
确定所述新服务节点的最大已执行指令序号n1与所述已注册服务节点的最大已执行指令序号n3的序号差的绝对值y;
如果y等于零,注册所述新服务节点;
如果y小于等于第二预设值,从缓存中调用序号为n1至n3的y个第一信息发送给所述新服务节点,在所述新服务节点执行完所述y个第一信息后,注册所述新服务节点;
如果y大于所述第二预设值,从所述已注册服务节点中拷贝状态信息发送给所述新服务节点后,注册所述新服务节点,其中n1、n3均为正整数。
8.如权利要求5~7任一项所述的容灾方法,其特征在于,所述注册所述新服务节点包括:
对所述新服务节点下发初始化信息,所述初始化信息包括随机种子和自驱动逻辑,所述自驱动逻辑包括所述管理节点的时间戳。
9.如权利要求1所述的容灾方法,其特征在于,所述将来自客户端的第一信息发送给N个对等的服务节点包括:
确定所述第一信息对应的服务节点的识别符;
根据所述识别符将所述第一信息发送给所述N个对等的服务节点。
10.如权利要求1所述的容灾方法,其特征在于,所述第二信息包括所述服务节点发送的第二信息的序号,所述接收来自所述N个对等的服务节点的M个第二信息包括:
在来自于服务节点的多个信息中,根据所述服务节点发送的第二信息的序号确定对应于所述第一信息的第二信息。
11.如权利要求1所述的容灾方法,其特征在于,所述N个对等的服务节点使用共享内存,每个所述服务节点在所述共享内存中具有独立的存储空间。
12.如权利要求11所述的容灾方法,其特征在于,在新服务节点为被关闭后重启的服务节点时,所述新服务节点重新启动时继续使用被关闭前在所述共享内存中使用的存储空间。
13.一种容灾装置,其特征在于,包括:
信息分发模块,设置为将来自客户端的第一信息发送给N个对等的服务节点,N为大于等于2的整数;
信息接收模块,设置为接收来自所述N个对等的服务节点的M个第二信息,M为小于等于N的正整数;
信息发送模块,设置为将所述M个第二信息中的一个发送给所述客户端。
14.一种容灾***,其特征在于,包括:
至少一个客户端;
服务器集群,耦接于所述客户端,设置有服务集群,所述服务集群包括主管理节点和一个以上备份管理节点,所述备份管理节点用于在所述主管理节点出现故障时作为新的主管理节点的候选对象,所述主管理节点用于执行如权利要求1-12任一项所述的容灾方法。
15.一种电子设备,其特征在于,包括:
存储器;以及
耦合到所述存储器的处理器,所述处理器被配置为基于存储在所述存储器中的指令,执行如权利要求1-12任一项所述的容灾方法。
CN201910521769.0A 2019-06-17 2019-06-17 容灾方法、装置、***与电子设备 Active CN110351122B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910521769.0A CN110351122B (zh) 2019-06-17 2019-06-17 容灾方法、装置、***与电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910521769.0A CN110351122B (zh) 2019-06-17 2019-06-17 容灾方法、装置、***与电子设备

Publications (2)

Publication Number Publication Date
CN110351122A true CN110351122A (zh) 2019-10-18
CN110351122B CN110351122B (zh) 2022-02-25

Family

ID=68182216

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910521769.0A Active CN110351122B (zh) 2019-06-17 2019-06-17 容灾方法、装置、***与电子设备

Country Status (1)

Country Link
CN (1) CN110351122B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110740045A (zh) * 2019-10-28 2020-01-31 支付宝(杭州)信息技术有限公司 指令的组播方法及其***
CN111147567A (zh) * 2019-12-23 2020-05-12 ***股份有限公司 服务调用方法、装置、设备及介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102394807A (zh) * 2011-08-23 2012-03-28 北京京北方信息技术有限公司 一种分散调度自治的流程引擎负载均衡集群***及方法
CN102938778A (zh) * 2012-10-19 2013-02-20 浪潮电子信息产业股份有限公司 一种在云存储中实现多节点容灾的方法
CN103580902A (zh) * 2012-08-07 2014-02-12 腾讯科技(深圳)有限公司 一种计算机信息***及其动态容灾方法
US20150169414A1 (en) * 2013-12-14 2015-06-18 Netapp, Inc. Techniques for lif placement in san storage cluster synchronous disaster recovery
CN106874142A (zh) * 2015-12-11 2017-06-20 华为技术有限公司 一种实时数据容错处理方法及***
CN109194718A (zh) * 2018-08-09 2019-01-11 玄章技术有限公司 一种区块链网络及其任务调度方法
CN109656911A (zh) * 2018-12-11 2019-04-19 江苏瑞中数据股份有限公司 分布式并行处理数据库***及其数据处理方法
CN109739685A (zh) * 2018-11-22 2019-05-10 广州市保伦电子有限公司 一种主从热备份数据同步方法和存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102394807A (zh) * 2011-08-23 2012-03-28 北京京北方信息技术有限公司 一种分散调度自治的流程引擎负载均衡集群***及方法
CN103580902A (zh) * 2012-08-07 2014-02-12 腾讯科技(深圳)有限公司 一种计算机信息***及其动态容灾方法
CN102938778A (zh) * 2012-10-19 2013-02-20 浪潮电子信息产业股份有限公司 一种在云存储中实现多节点容灾的方法
US20150169414A1 (en) * 2013-12-14 2015-06-18 Netapp, Inc. Techniques for lif placement in san storage cluster synchronous disaster recovery
CN106874142A (zh) * 2015-12-11 2017-06-20 华为技术有限公司 一种实时数据容错处理方法及***
CN109194718A (zh) * 2018-08-09 2019-01-11 玄章技术有限公司 一种区块链网络及其任务调度方法
CN109739685A (zh) * 2018-11-22 2019-05-10 广州市保伦电子有限公司 一种主从热备份数据同步方法和存储介质
CN109656911A (zh) * 2018-12-11 2019-04-19 江苏瑞中数据股份有限公司 分布式并行处理数据库***及其数据处理方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110740045A (zh) * 2019-10-28 2020-01-31 支付宝(杭州)信息技术有限公司 指令的组播方法及其***
CN111147567A (zh) * 2019-12-23 2020-05-12 ***股份有限公司 服务调用方法、装置、设备及介质

Also Published As

Publication number Publication date
CN110351122B (zh) 2022-02-25

Similar Documents

Publication Publication Date Title
US7225356B2 (en) System for managing operational failure occurrences in processing devices
CN109951331B (zh) 用于发送信息的方法、装置和计算集群
CN100591031C (zh) 实现高可用性光纤信道交换机的方法和装置
US9934242B2 (en) Replication of data between mirrored data sites
CN111338773B (zh) 一种分布式定时任务调度方法、调度***及服务器集群
CN109151045B (zh) 一种分布式云***及监控方法
CN113641511B (zh) 一种消息通信方法和装置
CN109743358A (zh) 异步消息接口熔断控制方法、装置、计算机设备及存储介质
US20080244552A1 (en) Upgrading services associated with high availability systems
EP2224341B1 (en) Node system, server switching method, server device, and data transfer method
CN102394914A (zh) 集群脑裂处理方法和装置
CN110099084B (zh) 一种保证存储服务可用性的方法、***及计算机可读介质
WO2012097588A1 (zh) 数据存储方法、设备和***
CN104158707A (zh) 一种检测并处理集群脑裂的方法和装置
CN108958984A (zh) 基于ceph的双活同步在线热备方法
CN108063813A (zh) 一种集群环境下密码服务网络并行化的方法与***
CN110351122A (zh) 容灾方法、装置、***与电子设备
CN110895469A (zh) 双机热备***的升级方法、装置及电子设备和存储介质
CN107357800A (zh) 一种数据库高可用零丢失解决方法
CN108512753B (zh) 一种集群文件***中消息传输的方法及装置
JP4806382B2 (ja) 冗長化システム
JP5716460B2 (ja) クラスタシステムおよびその制御方法
CN112306755B (zh) 一种基于微前端架构的高可用性实现方法和***
CN115086203A (zh) 数据发送方法、装置、电子设备及计算机可读存储介质
CN109240608B (zh) 一种配置信息同步方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant