CN103685034A

CN103685034A - 路由管理的方法和节点

Info

Publication number: CN103685034A
Application number: CN201210341766.7A
Authority: CN
Inventors: 王铁英
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2012-09-14
Filing date: 2012-09-14
Publication date: 2014-03-26
Anticipated expiration: 2032-09-14
Also published as: CN103685034B; WO2014040409A1

Abstract

本发明涉及通信技术领域，提供了一种路由管理的方法和节点，其中，路由管理的方法包括：第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息；第一节点确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目；第一节点将不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目。通过本发明，任意节点均可对路由信息进行更新，减轻了管理节点的负担，进而增加了***性能。

Description

路由管理的方法和节点

技术领域

本发明涉及通信技术领域，尤其涉及路由管理的方法和节点。

背景技术

HBase是一个分布式的、面向列的开源数据库，HBase***中可以包括：管理节点、区域节点、终端。其中，管理节点可以用于监控区域节点的状态、区域的负载均衡、划分路由区间、将终端定向到相应的区域节点等；区域节点可以用于处理终端的请求（读、写、浏览等）。

路由表指的是路由器或者其他网络设备上存储的表，该表中可以存有到达特定终端的路径，在某些情况下，还有一些与这些路径相关的度量。

在HBase***中，各区域节点中的路由表由管理节点进行维护和更新，使得各区域节点根据路由表处理相应终端的请求，并进行数据传输。

在实现上述路由管理的过程中，发明人发现现有技术中至少存在如下问题：由于，各节点中的路由表由管理节点进行维护和更新，因此，增加了管理节点的负担，导致管理节点不能及时进行其他操作，降低了***的性能。

发明内容

本发明的实施例提供一种路由管理的方法和节点，解决了管理节点不能及时进行其他操作，降低了***的性能的问题。

为达到上述目的，本发明的实施例采用如下技术方案：

一种路由管理的方法，包括：

第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息；

第一节点确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目；

第一节点将所述不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据所述不一致的路由条目的信息更新各自的路由条目。

一种节点，包括：

发送器，用于向第二节点发送更新请求；还用于将本地路由条目版本信息与接收器接收的第二节点的路由条目版本信息不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据所述不一致的路由条目的信息更新各自的路由条目；

所述接收器，用于接收第二节点发送的第二节点的路由条目版本信息；

处理器，用于确定所述不一致的路由条目。

本发明实施例提供的路由管理的方法和节点，采用上述方法后，第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息；第一节点确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目；第一节点将不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目。使得不仅仅只依赖管理节点对其他节点进行路由表更新，任意节点均可对路由表进行更新，减轻了管理节点的负担，进而增加了***性能。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本实施例应用的***架构示意图；

图2为本实施例提供的管理节点ManagerNode心跳处理流程图；

图3为本实施例提供的集群节点ClusterNode处理终端请求流程图；

图4为本实施例提供的一个路由区间Range中路由处理的逻辑图；

图5为本实施例提供的一种路由管理的方法流程图；

图6为本实施例提供的另一种路由管理的方法流程图；

图7为本实施例提供的路由条目、和路由条目版本信息结构示意图；

图8为本实施例提供的再一种路由管理的方法流程图；

图9为本实施例提供的一种节点结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了更清楚的描述以下实施例，首先，对实施例的***架构及处理终端的处理请求的方法做简单介绍。

如图1所示，该***中可以包含：ManagerNode（管理节点）、和至少一个ClusterNode（集群节点）。

其中，ManagerNode是***的管理节点，用于维护各个集群节点和管理节点的心跳，记录着各个区域节点的状态，根据这些记录，ManagerNode判定各节点在线还是不可达，其中，不可达可以为不能正常的进行数据传输，但节点不一定不在线。

ClusterNode是为终端提供服务的集群节点，所有请求将会被路由到相应的ClusterNode上进行处理。

图1中，Rack_1（节点集群名称）和Rack_2（节点集群名称）表示在两个节点机柜上，所有的节点组成了节点集群。A/B/C、1/2/3表示在不同机柜上的集群节点，网络Partition（分区）可能造成Rack_1中所有ClusterNode与ManagerNode之间、和Rack_1中所有ClusterNode与Rack_2中的所有节点之间不可达，但是Rack_2中的所有ClusterNode与ManagerNode保持正常的连接。

ManagerNode的功能可以包括但不限于：每个ClusterNode探测到存在某节点不可达时，需要向ManageNode进行确认；每个ClusterNode可以周期性向ManagerNode发送心跳请求（包含与ManagerNode的连接状态），以便ManagerNode根据心跳请求判断并记录ClusterNode在线还是不可达；

ManagerNode中可以存储有LivingNode（在线节点）列表记录了在线节点信息的列表、不可达节点信息列表。

如图2所示，为ManagerNode心跳处理流程图，具体步骤可以包括：

201、ClusterNode向ManagerNode发送心跳请求。

202、ManagerNode接收ClusterNode发送的心跳请求，并在LivingNode列表中记录ClusterNode的时间戳；如果为第一次的心跳请求，则返回响应，响应中可以包含ManagerNode记录的LivingNode列表、***中接入节点标识信息，以便该ClusterNode从接入节点中获取路由表信息；如果心跳请求中包含其它节点与ManagerNode的连接状态为false（失败连接），则返回响应，用于根据响应修改路由表；如果心跳请求不包含连接状态为false，则不返回响应。

203、ClusterNode接收ManagerNode发送的上述响应。

204、ClusterNode收到响应后，设置与ManagerNode的连接状态为True（成功连接或可达）。其中，ManagerNode收到ClusterNode的心跳请求或其他请求，都记录该ClusterNode的状态为在线，并记录时间戳。

ManagerNode被动的判断集群节点不可达，即ManagerNode接收ClusterNode发送的不可达报告请求后，根据该不可达报告请求中包含的被汇报不可达节点上次的心跳记录（时间戳），判断被汇报不可达节点是否掉线，并向发送不可达报告请求的ClusterNode返回信息。其中，不可达报告请求还可以包含但不限于不可达节点的标识信息等。

如图3所示，为一个Range（路由区间）中路由处理的逻辑图，其中，任意Range中可以包括至少一个ClusterNode，且每个ClusterNode在任意Range中可以为Master(主节点)或Slave（备份节点）。每个Range中包含的Master、和Slave中存储的信息相同，Master可以处理写和读操作请求，Slave可以处理读操作请求。

其中，若处理请求不为接入节点处理，则首先将路由请求路由到路由请求中包含的标识Key所在Range的Master中，如果Master不可达，且如果处理请求为写请求，则返回处理失败响应；如果处理请求为读请求，则根据路由表可以将处理请求继续路由到该Range的Slave中。

路由表中可以记录了所有节点的路由信息，例如，可以记录了***各Range中包含的Master信息和Slave信息。

各ClusterNode用于处理相应终端的请求，下面以其中一个ClusterNode为例，如图4所示，ClusterNode处理终端请求的步骤可以包括：

401、接入节点接收终端发送的处理请求，该处理请求包含处理该请求的Key；

402、判断处理请求的中包含的Key所在Range是否为接入节点所在的Range，如果否，执行步骤403；如果是，转步骤404；

403、获得Key所在Range的Master信息；

4031、判断403中获取的Master是否在线；如果是，转步骤4032；如果否，转步骤406；

4032、将该处理请求发送至Master中处理；

404、判断接入节点与ManagerNode的连接是否正常；如果正常，转向4041；如果不正常，则执行步骤405；

4041、本地处理该处理请求；

405、判断是读请求还是其他请求；如果是读请求，转向4041；否则转向406；

406、返回处理失败的响应，处理结束。

下面提供一些实施例对本方案进行具体说明。

实施例一

本实施例提供一种路由管理的方法，如图5所示，可以包括以下步骤：

501、第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息。

502、第一节点确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目。

503、第一节点将不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目。

采用上述方法后，第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息；第一节点确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目；第一节点将不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目。使得不仅仅只依赖管理节点对其他节点进行路由表更新，任意节点均可对路由表进行更新，减轻了管理节点的负担，进而增加了***性能。

实施例二

作为改进，本实施例提供另一种路由管理的方法，该方法是对图5所示的方法的进一步扩展，其中，不一致的路由条目的信息包括第一路由条目以及第一路由条目对应的第一路由条目版本信息，如图6所示，可以包括以下步骤：

601、判断第一节点与管理节点之间是否不可达。若可达，则执行步骤602；若不可达，则流程结束。

若可达，则第一节点与管理节点连接正常，若不可达，则第一节点与管理节点连接不正常。

第一节点和第二节点可以为同一路由区间中的或不同路由区间中的Slave或Master，以下均以第一节点和第二节点为同一路由区间中的Slave或Master为例进行说明。

路由条目可以包含但不限于：该路由条目对应的Range、该Range节点列表，节点列表可以包含但不限于Master信息、和Slave信息。

作为本实施例的一种实施方式，节点的路由表中可以包含但不限于：路由条目列表、和路由条目版本信息列表，且路由条目列表可以包含至少一个路由条目，路由条目版本信息列表可以包含对应的至少一个路由条目版本信息。

本实施例对判断节点是否不可达的方法不作限定，可以根据实际需要进行设定，在此不再赘述。

602、第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息。

更新请求可以用于但不限于指示第一节点和第二节点将各自的路由表更新为最新的路由表，最新的路由表可以包含但不限于第一节点和第二节点中最新的路由条目及最新的路由条目版本信息等。

作为本实施例的一种实施方式，第一节点向第二节点发送更新请求的触发条件可以为但不限于：第一节点在更新完本地的路由表后主动触发的；或者，第一节点周期性向第二节点发送更新请求。

节点包含的路由表可能会根据实际情况进行相应变化，则此时，路由表中相应的路由条目及路由条目版本信息均需要进行同步更新，更新后路由条目版本信息的版本号可能发生变化。

进一步的，如图7所示，为路由条目包含的信息列表、和路由条目版本信息包含的信息列表。

其中，路由条目记录了当前***的不同路由条目的信息，主要用于进行请求路由的查询、判断、转发，每个路由条目可以包含Range信息71、ReplicaNodeList（节点列表）72记录了该Range数据在集群节点的分布状况，即该路由条目中包含的Master信息73、和Slave信息74（可以包括但不限于：Slave_1（741）、Slave_2（742）等），每一个ReplicaNodeList72中，不能存在两个相同的节点，但是，同一个节点可以位于不同的路由条目中。

Range可以表示路由区间，如可以表示为但不限于（0x0000，0xFFFF]等。

各个路由条目之间不存在重合的Range，即各Range之间不存在交集，所有Range的并集是一个全集，通常的，可以将Range作为区别路由条目和路由条目版本信息的标识信息；每个ClusterNode接收到请求，根据请求中的Key，从路由条目列表中判断该Key对应的Range，并获得该Range对应的ReplicaNodeList中的处理该请求的节点，通常情况下由Range对应的Master进行处理。

路由条目版本信息记录了路由条目的变化和状态，还记载了历史上出现过的路由条目状态。路由条目版本信息用于维护***各个节点路由条目的一致性。

路由条目版本信息可以包括：Range信息75、Range_State（状态信息）76用于描述相应路由条目的状态，可以包括但不限于三个状态：Add（添加）、Delete（删除）、Modify（修改）。

其中，路由条目版本信息中的Range值75，与相应的路由条目中的Range值71相同。例如，路由条目1版本信息中的Range值，与路由条目1中的Range值相同。

本实施例对路由条目版本状态不作限定，可以根据实际需要进行设定，在此不再赘述。

Range_Version（版本号）77记录了路由条目变化后，每个路由条目的版本号。通常情况下，初始值设定为0，每对相应的路由条目进行修改，版本号进行单调的变化。

例如，可以将版本号加/减预设数值，另外，相同路由条目中，版本号最大/最小的路由条目可能为最新的路由条目。

本实施例对预设数值不作限定，可以根据实际需要进行设定，例如，可以为：1、或2等，在此不再赘述。

进一步的，可以但不限于根据版本号判断第一节点与第二节点之间相对应的路由条目和路由条目版本信息是否一致。

下面对路由表变化进行举例说明：

若所属某一路由条目中的Slave向Master发送信息后超出预设时间后还未获取相应反馈信息，则Slave判断该路由条目中的Master是否不可达；具体的判断方法可以为但不限于：Slave向Manager发送不可达报告请求，并根据Manager反馈的信息进行判断。若Slave与Manager之间可达，且Master与Manager之间不可达，则此时，可以将Slave修改为该路由条目中的Master，因此，Slave存储的路由表中相应的路由条目也需要进行相应的修改。并且，修改后的路由条目对应的路由条目版本信息的版本号被加1。这种情况下，可能导致各路由表中相应的路由条目对应的版本号不同。修改后的路由条目版本信息包括的路由条目的状态可以为Modify。

作为本实施例的一种实施方式，第二节点在接收到第一节点发送的更新请求后，判断第一节点的路由条目版本信息与第二节点的路由条目版本信息是否相同，若不相同，则第二节点向第一节点发送第二节点的路由条目版本信息；若相同，则流程结束。

作为本实施例的一种实施方式，第二节点判断第一节点的路由条目版本信息与第二节点的路由条目版本信息是否相同的方法可以为但不限于：第二节点计算用于描述第二节点的路由条目版本信息内容的第二内容标识；然后，比较第一内容标识与第二内容标识是否相同，其中，第一内容标识是第一节点计算的并向第二节点发送的用于描述第一节点的路由条目版本信息内容的标识。

若第一内容标识与第二内容标识不相同，说明第一节点的路由条目版本信息与第二节点的路由条目版本信息不同。

作为本实施例的一种实施方式，第一内容标识与第二内容标识可以为但不限于Hash_Value（某一数值的名称），则此时，计算第一内容标识与第二内容标识的方法可以为：对第一节点的路由条目版本信息与第二节点的路由条目版本信息分别作Ha sh处理，得到第一内容标识与第二内容标识。

603、第一节点确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目。

本实施例对确定不一致的路由条目的方法不作限定，可以根据实际需要进行设定，在此不再赘述。

例如，可以根据版本号确定不一致的路由条目，即获取版本号不一致的路由条目版本信息，再获取不一致的路由条目版本信息对应的路由条目。

进一步的，当对路由表中的某一路由条目和相应的路由条目版本信息进行修改后，若将该路由条目版本信息的版本号加预设值，则版本号最大的路由条目版本信息即为最新的路由条目版本信息；若将版本号减预设值，则版本号最小的路由条目版本信息即为最新的路由条目版本信息。不一致的路由条目也可以包括但不限于第一节点与第二节点中最新的路由条目版本信息对应的路由条目。

例如，以版本号最大的路由条目版本信息为最新的路由条目版本信息为例进行说明（以下实施例均以此为例进行说明），第二节点的路由表包含：路由条目1版本信息、路由条目2版本信息、路由条目3版本信息的版本号分别可以为：1、2、5，第一节点的路由表包含：路由条目1版本信息、路由条目2版本信息、路由条目3版本信息的版本号分别可以为：2、3、3，则最新的路由表可以包含：版本号为2的路由条目1版本信息及其对应的路由条目、版本号为3的路由条目2版本信息及其对应的路由条目、版本号为5的路由条目3版本信息及其对应的路由条目。

604、第一节点将不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目。

进一步的，不一致的路由条目的信息可以包括第一路由条目以及第一路由条目对应的第一路由条目版本信息，第一路由条目包括第一节点中路由条目版本较新的路由条目，第一路由条目版本信息包括第一路由条目对应的路由条目版本信息。

此时，如步骤603所列举的例子，第一路由条目可以包含：版本号为2的路由条目1版本信息对应的路由条目、版本号为3的路由条目2版本信息对应的路由条目。第一路由条目版本信息可以包含：版本号为2的路由条目1版本信息、版本号为3的路由条目2版本信息。

605、第二节点根据第一路由条目和第一路由条目版本信息更新第二节点的路由条目和对应的路由条目版本信息。

作为本实施例的一种实施方式，第二节点可以将第二节点的且标识信息与第一路由条目的标识信息相同的路由条目更新为第一路由条目，同时，将第二节点的且标识信息与第一路由条目版本信息的标识信息相同的路由条目版本信息更新为第一路由条目版本信息。

具体的，第二节点可以将路由条目1更新为版本号为2的路由条目1版本信息对应的路由条目；并可以将路由条目2更新为版本号为3的路由条目2版本信息对应的路由条目。

本实施例对路由条目标识信息和路由条目版本信息的标识信息不作限定，可以根据实际需要进行设定，例如，可以为Range，在此不再赘述。

实施例三

本实施例提供另一种路由管理的方法，该方法是对图5所示的方法的进一步扩展，其中，不一致的路由条目的信息包括第二节点中路由条目版本较新的路由条目版本信息。

值得说明的是，实施例三与实施例二的区别在于：不一致的路由条目的信息中包括的内容不相同，使得第一节点与第二节点执行的相应操作不同，实施例三与实施例二不仅可以分开执行，也可以合并在一起执行，即不一致的路由条目的信息可以包括：第二节点中路由条目版本较新的路由条目版本信息、第一路由条目以及第一路由条目对应的第一路由条目版本信息中至少一项。

如图8所示，可以包括以下步骤：

801、判断第一节点与管理节点之间是否不可达。若可达，则执行步骤702；若不可达，则流程结束。

802、第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息。

803、第一节点确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目。

804、第一节点将不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目。

进一步的，不一致的路由条目的信息包括第二节点中路由条目版本较新的路由条目版本信息，同时，指示第二节点向第一节点发送第二路由条目，第二路由条目可以为第二节点中路由条目版本较新的路由条目版本信息对应的路由条目。

805、第一节点接收第二节点发送的第二路由条目。

806、第一节点根据第二路由条目更新本地路由条目和对应的路由条目版本信息。

作为本实施例的一种实施方式，第一节点可以将第一节点的且标识信息与第二路由条目的标识信息相同的路由条目更新为第二路由条目；然后，从第二节点的路由条目版本信息中获取第二路由条目对应的第二路由条目版本信息；将第一节点的且标识信息与第二路由条目版本信息的标识信息相同的路由条目版本信息更新为第二路由条目版本信息。

本实施例中的各步骤的具体实施方式与实施例二中的实施方式类似，在此不再赘述。

实施例四

本实施例提供一种节点，如图9所示，可以包括：

发送器91，用于向第二节点发送更新请求；将本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目；

接收器92，用于接收第二节点发送的第二节点的路由条目版本信息；

处理器93，用于确定不一致的路由条目。

进一步的，发送器91发送的不一致的路由条目的信息包括第一路由条目，第一路由条目包括第一节点中路由条目版本较新的路由条目。

进一步的，发送器91发送的不一致的路由条目的信息包括第二节点中路由条目版本较新的路由条目版本信息；

接收器92，还用于接收第二节点发送的第二路由条目，第二路由条目为第二节点中路由条目版本较新的路由条目版本信息对应的路由条目；

处理器93，还用于根据第二路由条目更新本地路由条目和对应的路由条目版本信息。

进一步的，处理器93，该用于判断第一节点与管理节点之间是否可达；

发送器91，还用于若处理器判断出第一节点与管理节点之间可达，则向第二节点发送更新请求；

接收器92，还用于接收第二节点发送的第二节点的路由条目版本信息。

进一步的，路由条目版本信息包含与对应的路由条目相同的路由区间信息、状态信息、版本号。

采用上述方法后，发送器向第二节点发送更新请求，并且接收器接收第二节点发送的第二节点的路由条目版本信息；处理器确定本地路由条目版本信息与第二节点的路由条目版本信息不一致的路由条目；发送器将不一致的路由条目的信息发送给第二节点，以便于第一节点和第二节点根据不一致的路由条目的信息更新各自的路由条目。使得不仅仅只依赖管理节点对其他节点进行路由表更新，任意节点均可对路由表进行更新，减轻了管理节点的负担，进而增加了***性能。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims

1.一种路由管理的方法，其特征在于，包括：

2.根据权利要求1所述的路由管理的方法，其特征在于，所述不一致的路由条目的信息包括第一路由条目以及第一路由条目对应的第一路由条目版本信息，所述第一路由条目包括第一节点中路由条目版本较新的路由条目，所述第一路由条目版本信息包括所述第一路由条目对应的路由条目版本信息；

所述第一节点和第二节点根据所述不一致的路由条目的信息更新各自的路由条目包括：

所述第二节点根据所述第一路由条目和所述第一路由条目版本信息更新第二节点的路由条目和对应的路由条目版本信息。

3.根据权利要求1或2所述的路由管理的方法，其特征在于，所述不一致的路由条目的信息包括第二节点中路由条目版本较新的路由条目版本信息；

所述方法还包括：

第一节点接收第二节点发送的第二路由条目，所述第二路由条目为第二节点中路由条目版本较新的路由条目版本信息对应的路由条目；

第一节点根据所述第二路由条目更新本地路由条目和对应的路由条目版本信息。

4.根据权利要求1至3中任意一项所述的路由管理的方法，其特征在于，在所述第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息之前，所述方法还包括：

判断所述第一节点与管理节点之间是否可达；

所述第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息为：

若所述第一节点与管理节点之间可达，则所述第一节点向第二节点发送更新请求，并接收第二节点发送的第二节点的路由条目版本信息。

5.根据权利要求1至4中任意一项所述的路由管理的方法，其特征在于，所述路由条目版本信息包含与对应的路由条目相同的路由区间信息、状态信息、版本号。

6.一种节点，其特征在于，包括：

处理器，用于确定所述不一致的路由条目。

7.根据权利要求6所述的节点，其特征在于，所述发送器发送的所述不一致的路由条目的信息包括第一路由条目以及第一路由条目对应的第一路由条目版本信息，所述第一路由条目包括第一节点中路由条目版本较新的路由条目，所述第一路由条目版本信息包括所述第一路由条目对应的路由条目版本信息。

8.根据权利要求6或7所述的节点，其特征在于，所述发送器发送的所述不一致的路由条目的信息包括第二节点中路由条目版本较新的路由条目版本信息；

所述接收器，还用于接收第二节点发送的第二路由条目，所述第二路由条目为第二节点中路由条目版本较新的路由条目版本信息对应的路由条目；

所述处理器，还用于根据所述第二路由条目更新本地路由条目和对应的路由条目版本信息。

9.根据权利要求6至8任意一项所述的节点，其特征在于，所述处理器，还用于判断所述第一节点与管理节点之间是否可达；

所述发送器，还用于若所述处理器判断出所述第一节点与管理节点之间可达，则向第二节点发送更新请求；

所述接收器，还用于接收第二节点发送的第二节点的路由条目版本信息。

10.根据权利要求6至9中任意一项所述的节点，其特征在于，所述路由条目版本信息包含与对应的路由条目相同的路由区间信息、状态信息、版本号。