一种实时数据容错处理方法及系统与流程

本发明涉及实时计算领域，尤其涉及一种实时数据容错处理方法及系统。

背景技术：

在金融、电信、能源、医疗等领域内，很多业务系统都有“7*24小时”业务连续性要求，任何原因造成的业务中断是不可接受的。这种行业性高容错要求催生了双活系统的诞生，即通过提供冗余系统元素确保在出现各种故障时系统维持业务连续性，确保在故障发生时确保数据完整性和系统功能的特性。当然，双活系统的资源消耗一直是该解决方案的诟病所在，在采用双活系统解决方案时，需要准备两套独立的资源，同时在业务运行中，两套独立系统分别对自己的运行单元进行部署、管理和维护。

目前业界广泛采用实时流计算平台来构建实时在线系统的架构解决方案，其中实时流计算组件又以Storm的应用最为广泛。Storm是一个免费开源、分布式、高容错的实时计算系统。Storm经常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。Storm的部署管理非常简单，且在同类的流式计算工具，Storm的性能也是非常出众的，是一般搭建实时计算系统架构的首先方案。

Storm的进程是无状态的，这样便于实现快速失败，保障Storm的健壮性。Storm不提供保存节点缓存的状态数据的功能支持，如此当某一节点宕机之后，Storm只需要拉起该节点服务，无需加载状态数据，即可实现快速失败和恢复的HA机制保护。但是，在时下各行业的业务需求中，经常出现需要保存状态数据的业务场景，在该场景中，节点不支持恢复状态数据的功能是不可接受的。它们迫切需求在故障宕机恢复之后，能够保证该节点加载故障前的状态数据，恢 复成该节点宕机前的状态，如此才能够快速的重新接入系统，响应数据处理请求，承担业务处理。

技术实现要素：

本发明实施例提供一种实时数据容错处理方法及系统，以统一管理实时数据处理，且能保证节点发生故障时，恢复该节点宕机前的状态。

第一方面，提供了一种实时数据容错处理方法，包括：

当系统中的节点处理业务的实时数据发生故障时，根据所述节点对应的物理资源确定所述节点所在的实例，其中，所述业务在所述系统中部署至少两个实例，每个实例包括具有拓扑关系的至少一个节点，每个实例分配对应的物理资源，每个实例中的所述至少一个节点与被分配的物理资源具有对应关系，每个实例中的每个节点在其它实例中具有对等节点；

在所述确定的实例中，将故障拉起节点替换发生故障的节点；

在联结信息表中更新所述发生故障的节点为所述故障拉起节点，其中，所述联结信息表包括所述至少两个实例中的对等节点信息；

根据所述对等节点信息，将所述发生故障的节点的对等节点的缓存数据发送给所述故障拉起节点，以使所述故障拉起节点根据接收到的所述缓存数据恢复所述节点的数据处理。

该系统可以统一管理实时数据处理，且能保证节点发生故障时，恢复该节点宕机前的状态，快速地重新接入系统。

结合第一方面，在第一方面的第一种可能的实现方式中，所述方法还包括：

控制每个实例中的所述至少一个节点分别处理所述实时数据。

各个实例在自己独立支配的物理资源上进行分布式部署，保证在各自实例中节点间的实时数据只能在同一个实例中进行流通。

结合第一方面，在第一方面的第二种可能的实现方式中，所述被分配的物理资源包括至少一个物理机，每个实例中的所述至少一个节点与被分配的物理资源具有对应关系，包括：每个所述物理机与所述至少一个节点对应。

结合第一方面或第一方面的第一种可能的实现方式或第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述方法还包括：

当所述系统为所述业务增加物理资源时，将增加的所述物理资源分配给所 述业务的至少两个实例。

结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，所述方法还包括：

将每个实例中负载高于设定值的物理资源对应的至少一个节点的实时数据迁移至分配给所述实例的增加的所述物理资源对应的至少一个节点；或

将每个所述实例增加的所述物理资源分配给所述故障拉起节点。

对于每个实例增加的物理资源，可以根据分配给节点的物理资源的负载进行节点的实时数据的迁移，以保证负载均衡，使物理资源得到均衡利用；也可以直接将每个实例增加的物理资源分配给新的故障拉起节点，操作简单。

结合第一方面或第一方面的第一种可能的实现方式或第一方面的第二种可能的实现方式，在第一方面的第五种可能的实现方式中，所述方法还包括：

当需要减少实例中的物理资源时，停止所述减少的物理资源对应的节点的实时数据处理；

将故障拉起节点替换所述停止处理实时数据的节点，其中所述实例中剩下的物理资源被重新分配给所述实例中正在进行实时数据处理的至少一个节点；

在所述联结信息表中更新所述停止处理实时数据的节点为所述故障拉起节点；

根据所述对等节点信息，将所述停止处理实时数据的节点的对等节点的缓存数据发送给所述故障拉起节点。

对于减少每个实例的物理资源时，必须停止减少的物理资源对应的节点的实时数据处理，并将故障拉起节点替换停止处理实时数据的节点，以保证数据处理不被物理资源的减少所中断。

第二方面，提供了一种实时数据容错处理系统，该系统具有实现上述方法中系统行为的功能。所述功能可以通过硬件执行相应的软件实现。所述软件包括一个或多个与上述功能相对应的模块。

该实时数据容错处理系统包括：

确定单元，用于当系统中的节点处理业务的实时数据发生故障时，根据所述节点对应的物理资源确定所述节点所在的实例，其中，所述业务在所述系统中部署至少两个实例，每个实例包括具有拓扑关系的至少一个节点，每个实例 分配对应的物理资源，每个实例中的所述至少一个节点与被分配的物理资源具有对应关系，每个实例中的每个节点在其它实例中具有对等节点；

替换单元，用于在所述确定的实例中，将故障拉起节点替换发生故障的节点；

更新单元，用于在联结信息表中更新所述发生故障的节点为所述故障拉起节点，其中，所述联结信息表包括所述至少两个实例中的对等节点信息；

发送单元，用于根据所述对等节点信息，将所述发生故障的节点的对等节点的缓存数据发送给所述故障拉起节点，以使所述故障拉起节点根据接收到的所述缓存数据恢复所述节点的数据处理。

实施本发明实施例提供的一种实时数据容错处理方法及系统，具有如下有益效果：

通过为业务在系统中部署至少两个实例，每个实例分配对应的物理资源，每个实例中的每个节点在其它实例中具有对等节点，当系统中的节点处理业务的实时数据发生故障时，根据节点对应的物理资源确定节点所在的实例，在确定的实例中，将故障拉起节点替换发生故障的节点，在联结信息表中更新发生故障的节点为故障拉起节点，根据联结信息表中的对等节点信息，将发生故障的节点的对等节点的缓存数据发送给故障拉起节点，以使故障拉起节点恢复数据处理，该系统可以统一管理实时数据处理，且能保证节点发生故障时，恢复该节点宕机前的状态，快速地重新接入系统。

附图说明

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

图1为本发明实施例提供的一种实时数据容错处理方法的流程示意图；

图2为示例的现有的Storm应用运行示意图；

图3为本发明实施例示例的Storm平台中的容错拓扑部署结构示意图；

图4为本发明实施例示例的Storm平台中的实现故障宕机的快速恢复示意 图；

图5为本发明实施例提供的另一种实时数据容错处理方法的流程示意图；

图6为本发明实施例提供的一种实时数据容错处理系统的结构示意图；

图7为本发明实施例提供的另一种实时数据容错处理系统的结构示意图。

具体实施方式

图1为本发明实施例提供的一种实时数据容错处理方法的流程示意图，该方法包括以下步骤：

S101，当系统中的节点处理业务的实时数据发生故障时，根据所述节点对应的物理资源确定所述节点所在的实例。

系统给每个业务部署两个或两个以上的实例，每个实例包括具有拓扑关系的一个或多个节点，这些实例具有相同数量的节点，以及节点之间具有相同的拓扑关系。每个实例分配对应的物理资源，且被分配的物理资源只能被该实例支配，每个实例中的这些节点与被分配的物理资源具有对应关系，即物理资源分配给每个实例，而分配给每个实例的物理资源又分别分配给该实例中的各个节点。且每个实例中的每个节点在其它实例中具有对等节点，对等节点即在拓扑关系具有同样位置和实现相同功能的节点。

本实施例中系统可以用于处理实时数据。当系统中的某个节点处理该业务的实时数据发生故障时，首先需要确定该节点所在的实例：由于发生故障时，首先能确定的是哪个物理资源发生了故障，因此，根据发生故障的物理资源以及节点与物理资源的对应关系，能够确定节点所在的实例。

S102，在所述确定的实例中，将故障拉起节点替换发生故障的节点。

在确定了发生故障的节点所在的实例后，在该实例中，使用一故障拉起节点替换发生故障的节点，该替换操作只在该实例中进行，不影响其它实例的正常运行。

S103，在联结信息表中更新所述发生故障的节点为所述故障拉起节点。

在系统中设置有联结信息表，该联结信息表包括系统为每个业务部署的两个或两个以上实例中的对等节点信息，例如记录实例A中节点1与实例B中的节点1’是对等节点。在将故障拉起节点替换发生故障的节点后，则需要在联结信息表中更新发生故障的节点为故障拉起节点，例如实例A中的节点1发生故 障，采用节点7替换节点1，则在联结信息表中，需要将实例A中的节点1替换为节点7。

S104，根据所述联结信息表中的对等节点信息，将所述发生故障的节点的对等节点的缓存数据发送给所述故障拉起节点，以使所述故障拉起节点根据接收到的所述缓存数据恢复所述节点的数据处理。

根据联结信息表中的对等节点信息，查询发生故障的节点的对等节点，由于在节点发生故障时，而其对等节点是正常运行的，对等节点保存有一段时间内的缓存数据，因此，可以将对等节点的缓存数据发送给该故障节点的故障拉起节点，使故障拉起节点根据接收到的缓存数据恢复节点从发生故障起的数据处理。

从上面的描述可以看出，系统为每个业务部署的两个或两个以上实例的物理资源分配、对等节点信息的记录、节点的替换等都由系统统一管理，且在某个实例的某个节点发生故障时，能获取该节点的对等节点的缓存数据，恢复发生故障的节点宕机前的状态，快速地重新接入系统。

根据本发明实施例提供的一种实时数据容错处理方法，可以使系统统一管理实时数据处理，且能保证节点发生故障时，恢复该节点宕机前的状态，快速地重新接入系统。

下面以Storm系统或平台为例详细描述本发明实施例提供的实时数据容错处理方法：

在Storm系统中包括两类节点：Spout负责在应用中发送数据流(自身产生数据流或者接收外部数据流并发送出去)，即为整个Storm应用中的数据源；Bolt中则代码实现了业务逻辑处理，它负责数据流的处理，复杂的业务逻辑实现需要多个Bolt配合。在Storm系统中，Tuple是指在Storm应用中流通的单个数据流，它是不停流通在各个节点的数据片段。拓扑(Topology)描述Spout和Bolt的连通顺序和连通关系，还可以设定应用中Spout和Bolt各个节点间数据流的发送策略和整个应用的运行配置等。

图2为示例的现有的Storm应用运行示意图，Storm应用的运行，即将Storm应用代码Jar通过命令提交到Storm集群提交运行，运行中的Storm应用会独立成一个系统服务式的Storm任务，该任务只能通过手动的命令来进行关闭，它 会一直运行在该Storm集群中，一旦有符合任务要求的数据到来，就对接收的数据进行处理并输出。

Storm内建了一套可靠性机制来保证各个组件和节点的正常运行，当某个组件/节点运行失败或者异常，Storm会自发的重启组件/节点，并初始化相关配置，加载到任务中去，保证整个Storm任务的正常运行。

数据通过Spout节点进入Storm任务，Spout继承实现了相关的业务逻辑，对流入的数据进行分析处理，发送至连通的下一个Bolt节点；Bolt节点接收到该数据并通过自身定义的业务逻辑对该数据进行处理，而后继续发送至下一个Bolt节点；多个Bolt节点可以串联和并联，也可以分离和汇总，数据流通结构遵循有向无环图的原则，可以通过多种组合构成复杂的业务逻辑模型，适应应用需求。

Storm拥有完善的宕机恢复的高可用性群集/双机集群(英文：High Available，简称：HA)机制，Storm利用同步保存、共享模块Zookeeper来保存和共享节点的配置信息，当某个节点宕机后，主控制节点利用心跳机制检测到节点的故障，尝试拉起该故障节点，拉起故障节点时从Zookeeper读取节点配置信息并加载，当节点拉起后，重新接入应用Topology中。

图3为本发明实施例示例的Storm平台中的容错拓扑部署结构示意图。本发明实施例设计一个Storm扩展的模块：容错(英文：fault tolerance，简称：FT)拓扑(Topology)模块。用户采用FT Topology创建应用和部署运行时，遵循新增模块FT Topology的实现和运作模式。采用FT Topology模块构建的Storm应用，这里表示为具备FT能力的Storm应用。

具备FT能力的Storm应用在执行部署时，先在Storm集群平台内自动生成两个相同的Storm应用实例，这里分别用FT Topology A和FT Topology B来表示。然后将Storm集群中的物理资源按照既定策略(平均分配/比例分配)给这两个实例，各个实例在自己独立支配的物理资源上进行分布式部署，保证在各自实例中节点间的数据流只能在同一个实例中进行流通。即FT Topology A实例中流通的数据流不会发送给FT Topology B实例，这两个实例在处理数据流方面是完全隔离的。本实施例中，物理资源可以是物理机，一个物理机可以支持多个节点在其上运行，如图3所示，Host1这个物理机被分配给实例A中的节点1和节点4，Host2被分配给实例A中的节点2和节点5等。

具备FT能力的Storm应用部署完成时，每个Storm应用实例拥有自己独立的物理资源分组，同一个物理资源分组中只会有同一个Storm应用实例的节点运行，无论故障宕机拉起还是其他的运行操作，两个Storm应用实例中的节点不能同时运行在同一个物理资源分组的机器中。如图3所示，即FT Topology A中的任意节点无论任何时候，不能运行在Host4、Host5、Host6三个机器中，当FT Topology A中某一节点宕机拉起时，新拉起的节点只能运行在Host1、Host2、Host3某一机器中。

图4为本发明实施例示例的Storm平台中的实现故障宕机的快速恢复示意图。具备FT能力的Storm应用部署完成后，通过联结信息表记录关联部署的两个实例(即FT Topology A实例和FT Topology B实例)之间各个Spout/Bolt节点的对等位置和功能的拓扑结构，即对等节点信息，该联结信息表可以保存在Zookeeper模块中。利用Storm的心跳模式来相互监控两个实例中对等节点(即同样位置和功能的节点)Spout/Bolt的运行状态。假如某一Spout/Bolt节点出现故障宕机，而另一个实例中同样位置和功能的Spout/Bolt节点运行正常，则运行正常的Spout/Bolt节点会将自身的缓存数据同步发送给新的故障拉起的Spout/Bolt节点，以加速故障节点的恢复。

此过程的实现是由Storm控制节点(nimbus)调用Zookeeper缓存和同步各节点信息的功能，创建和维护两个实例间同样位置和功能Spout/Bolt节点的联结信息表。当其中某一实例中某个Spout/Bolt节点故障拉起后，旧的节点联结中断，结合Zookeeper中新的故障拉起的Spout/Bolt节点创建信息，调整相应节点的联结关系。即更新调整联结信息表，将该Topology中旧的宕机节点替换成新的故障拉起节点。

节点宕机拉起恢复后，联结信息表中与之对应的另一实例中的正常运行节点将自身的缓存数据通过联结信息表发送给新节点，帮助它快速构建数据模型，恢复数据处理能力。

具备FT能力的Storm应用在Storm平台某一个节点发生故障容灾操作时，先验证故障物理资源所在的针对FT Topology实例的分组信息，只对故障的FT Topology实例进行容灾操作，不影响另一组实例的运行。

如图4所示，实例A中的节点3发生故障，采用节点7替换节点3，在联结信息表中将节点3替换为节点7，并根据联结信息表记录的对等节点信息，将 原节点3的对等节点3’的缓存数据发送给新的节点7，从而使节点7恢复从发生故障起的数据处理。

图5为本发明实施例提供的另一种实时数据容错处理方法的流程示意图，该方法包括以下步骤：

S201，控制每个实例中的至少一个节点分别处理实时数据。

系统给业务部署两个或两个以上的实例，这些实例中的节点是分别处理实时数据的，即各个实例在自己独立支配的物理资源上进行分布式部署，保证在各自实例中节点间的数据流只能在同一个实例中进行流通。

S202，当所述系统中的节点处理业务的实时数据发生故障时，根据所述节点对应的物理资源确定所述节点所在的实例。

S203，在所述确定的实例中，将故障拉起节点替换发生故障的节点。

S204，在联结信息表中更新所述发生故障的节点为所述故障拉起节点。

S205，根据所述联结信息表中的对等节点信息，将所述发生故障的节点的对等节点的缓存数据发送给所述故障拉起节点，以使所述故障拉起节点根据接收到的所述缓存数据恢复所述节点的数据处理。

S202-S205为某实例中的某节点发生故障时的数据容错处理过程，与图1所示实施例中的S101-S104相同，在此不再赘述。

S206，当所述系统为所述业务增加物理资源时，将增加的所述物理资源分配给所述业务的至少两个实例。

S207，将每个所述实例增加的所述物理资源分配给所述故障拉起节点。

S206-S207为物理资源的扩容过程，在系统给某业务增加物理资源时，将增加的物理资源分配给系统为该业务部署的两个或两个以上实例，一般是平均分配。分配给每个实例的增加的物理资源可以直接分配给故障拉起节点，因为故障拉起节点是新的节点，尚未分配物理资源，此时如果有增加的物理资源，则直接分配给故障拉起节点，可以简化操作；也可以首先判断每个实例中哪些物理资源对应的一个或多个节点的负载高于设定值，并确定增加的物理资源分配给了哪些节点，将负载高于设定值的节点的实时数据流迁移至被分配了增加的物理资源的节点继续进行处理，从而可以使节点间的负载均衡，且合理利用了物理资源。需要说明的是，在对物理资源扩容时，无需针对各节点正在处理的 操作。

S208，当需要减少实例中的物理资源时，停止所述减少的物理资源对应的节点的实时数据处理。

S209，将故障拉起节点替换所述停止处理实时数据的节点。

S210，在所述联结信息表中更新所述停止处理实时数据的节点为所述故障拉起节点。

S211，根据所述对等节点信息，将所述停止处理实时数据的节点的对等节点的缓存数据发送给所述故障拉起节点。

S208-S211为减少实例中的物理资源的过程。实例中的物理资源被减少，减少的可以只是部分节点对应的物理资源，被减少物理资源的节点需要停止当前的数据处理，采用故障拉起节点替换停止处理的节点，在将实例中剩下的物理资源分配给故障拉起节点和其它未被停止的节点后，采用与图1所示实施例相同的操作，使故障拉起节点恢复停止处理节点被停止开始时的数据处理。所述实例中剩下的物理资源被重新分配给所述实例中正在进行实时数据处理的至少一个节点。

需要说明的是，具备FT能力的Storm应用在Storm平台发生扩容、减容时，只对需要调整的Topology实例进行重新部署，而不需要调整的Topology实例继续运行。

根据本发明实施例提供的一种实时数据容错处理方法，可以使系统统一管理实时数据处理，且能保证节点发生故障时，恢复该节点宕机前的状态，快速地重新接入系统；对于每个实例增加的物理资源，可以直接将每个实例增加的物理资源分配给新的故障拉起节点，操作简单；对于减少每个实例的物理资源时，必须停止减少的物理资源对应的节点的实时数据处理，并将故障拉起节点替换停止处理实时数据的节点，以保证数据处理不被物理资源的减少所中断。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为根据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

图6为本发明实施例提供的一种实时数据容错处理系统的结构示意图，该系统1000包括：

确定单元11，用于当系统中的节点处理业务的实时数据发生故障时，根据所述节点对应的物理资源确定所述节点所在的实例。

系统给每个业务部署两个或两个以上的实例，每个实例包括具有拓扑关系的一个或多个节点，这些实例具有相同数量的节点，以及节点之间具有相同的拓扑关系。每个实例分配对应的物理资源，且被分配的物理资源只能被该实例支配，每个实例中的这些节点与被分配的物理资源具有对应关系，即物理资源分配给每个实例，而分配给每个实例的物理资源又分别分配给该实例中的各个节点。且每个实例中的每个节点在其它实例中具有对等节点，对等节点即在拓扑关系具有同样位置和实现相同功能的节点。

本实施例中系统可以用于处理实时数据。当系统中的某个节点处理该业务的实时数据发生故障时，确定单元11首先需要确定该节点所在的实例：由于发生故障时，首先能确定的是哪个物理资源发生了故障，因此，根据发生故障的物理资源以及节点与物理资源的对应关系，能够确定节点所在的实例。

替换单元12，用于在所述确定的实例中，将故障拉起节点替换发生故障的节点。

在确定了发生故障的节点所在的实例后，在该实例中，替换单元12使用一故障拉起节点替换发生故障的节点，该替换操作只在该实例中进行，不影响其它实例的正常运行。

更新单元13，用于在联结信息表中更新所述发生故障的节点为所述故障拉起节点。

在系统中设置有联结信息表，该联结信息表包括系统为每个业务部署的两个或两个以上实例中的对等节点信息，例如记录实例A中节点1与实例B中的节点1’是对等节点。在将故障拉起节点替换发生故障的节点后，则更新单元13需要在联结信息表中更新发生故障的节点为故障拉起节点，例如实例A中的节点1发生故障，采用节点7替换节点1，则在联结信息表中，需要将实例A中的节点1替换为节点7。

发送单元14，用于根据所述联结信息表中的对等节点信息，将所述发生故障的节点的对等节点的缓存数据发送给所述故障拉起节点，以使所述故障拉起 节点根据接收到的所述缓存数据恢复所述节点的数据处理。

根据联结信息表中的对等节点信息，查询发生故障的节点的对等节点，由于在节点发生故障时，而其对等节点是正常运行的，对等节点保存有一段时间内的缓存数据，因此，发送单元14可以将对等节点的缓存数据发送给该故障节点的故障拉起节点，使故障拉起节点根据接收到的缓存数据恢复节点从发生故障起的数据处理。

从上面的描述可以看出，系统为每个业务部署的两个或两个以上实例的物理资源分配、对等节点信息的记录、节点的替换等都由系统统一管理，且在某个实例的某个节点发生故障时，能获取该节点的对等节点的缓存数据，恢复发生故障的节点宕机前的状态，快速地重新接入系统。

根据本发明实施例提供的一种实时数据容错处理系统，可以使系统统一管理实时数据处理，且能保证节点发生故障时，恢复该节点宕机前的状态，快速地重新接入系统。

图7为本发明实施例提供的另一种实时数据容错处理系统的结构示意图，该系统2000包括：

处理单元21，用于控制每个实例中的至少一个节点分别处理实时数据。

系统给业务部署两个或两个以上的实例，这些实例中的节点是分别处理实时数据的，即各个实例在自己独立支配的物理资源上进行分布式部署，保证在各自实例中节点间的数据流只能在同一个实例中进行流通。

确定单元22，用于当所述系统中的节点处理业务的实时数据发生故障时，根据所述节点对应的物理资源确定所述节点所在的实例。

替换单元23，用于在所述确定的实例中，将故障拉起节点替换发生故障的节点。

更新单元24，用于在联结信息表中更新所述发生故障的节点为所述故障拉起节点。

发送单元25，用于根据所述联结信息表中的对等节点信息，将所述发生故障的节点的对等节点的缓存数据发送给所述故障拉起节点，以使所述故障拉起节点根据接收到的所述缓存数据恢复所述节点的数据处理。

以上为某实例中的某节点发生故障时的数据容错处理过程，与图6所示实施例中的相应单元功能相同，在此不再赘述。

分配单元26，用于当所述系统为所述业务增加物理资源时，将增加的所述物理资源分配给所述业务的至少两个实例。

分配单元26还用于将每个所述实例增加的所述物理资源分配给所述故障拉起节点。

以上为物理资源的扩容过程，在系统给某业务增加物理资源时，将增加的物理资源分配给系统为该业务部署的两个或两个以上实例，一般是平均分配。分配给每个实例的增加的物理资源可以直接分配给故障拉起节点，因为故障拉起节点是新的节点，尚未分配物理资源，此时如果有增加的物理资源，则直接分配给故障拉起节点，可以简化操作；也可以首先判断每个实例中哪些物理资源对应的一个或多个节点的负载高于设定值，并确定增加的物理资源分配给了哪些节点，将负载高于设定值的节点的实时数据流迁移至被分配了增加的物理资源的节点继续进行处理，从而可以使节点间的负载均衡，且合理利用了物理资源。需要说明的是，在对物理资源扩容时，无需针对各节点正在处理的操作。

处理单元21还用于当需要减少实例中的物理资源时，停止所述减少的物理资源对应的节点的实时数据处理。

替换单元23还用于将故障拉起节点替换所述停止处理实时数据的节点。

更新单元24还用于在所述联结信息表中更新所述停止处理实时数据的节点为所述故障拉起节点。

发送单元25还用于根据所述对等节点信息，将所述停止处理实时数据的节点的对等节点的缓存数据发送给所述故障拉起节点。

以上为减少实例中的物理资源的过程。实例中的物理资源被减少，减少的可以只是部分节点对应的物理资源，被减少物理资源的节点需要停止当前的数据处理，采用故障拉起节点替换停止处理的节点，在将实例中剩下的物理资源分配给故障拉起节点和其它未被停止的节点后，采用与图1所示实施例相同的操作，使故障拉起节点恢复停止处理节点被停止开始时的数据处理。所述实例中剩下的物理资源被重新分配给所述实例中正在进行实时数据处理的至少一个节点。

需要说明的是，具备FT能力的Storm应用在Storm平台发生扩容、减容时，只对需要调整的Topology实例进行重新部署，而不需要调整的Topology实例继续运行。

根据本发明实施例提供的一种实时数据容错处理系统，可以使系统统一管理实时数据处理，且能保证节点发生故障时，恢复该节点宕机前的状态，快速地重新接入系统；对于每个实例增加的物理资源，可以直接将每个实例增加的物理资源分配给新的故障拉起节点，操作简单；对于减少每个实例的物理资源时，必须停止减少的物理资源对应的节点的实时数据处理，并将故障拉起节点替换停止处理实时数据的节点，以保证数据处理不被物理资源的减少所中断。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可以用硬件实现，或固件实现，或它们的组合方式来实现。当使用软件实现时，可以将上述功能存储在计算机可读介质中或作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是计算机能够存取的任何可用介质。以此为例但不限于：计算机可读介质可以包括随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-Only Memory，ROM)、电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质。此外。任何连接可以适当的成为计算机可读介质。例如，如果软件是使用同轴电缆、光纤光缆、双绞线、数字用户线(Digital Subscriber Line，DSL)或者诸如红外线、无线电和微波之类的无线技术从网站、服务器或者其他远程源传输的，那么同轴电缆、光纤光缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在所属介质的定影中。如本发明所使用的，盘(Disk)和碟(disc)包括压缩光碟(CD)、激光碟、光碟、数字通用光碟(DVD)、软盘和蓝光光碟，其中盘通常磁性的复制数据，而碟则用激光来光学的复制数据。上面的组合也应当包括在计算机可读介质的保护范围之内。

总之，以上所述仅为本发明技术方案的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。