精华内容
下载资源
问答
  • Hadoop容错机制

    千次阅读 2018-08-24 10:03:39
    简单介绍一下Hadoop中数据存储的可靠性和完整性,其中包括HDFS的容错机制、NameNode(元数据结点)的单点失效解决机制、Block数据块的多副本存储机制、 NameNode与DataNode之间的心跳检测机制、数据存储等。 (一)...

    简单介绍一下Hadoop中数据存储的可靠性和完整性,其中包括HDFS的容错机制、NameNode(元数据结点)的单点失效解决机制、Block数据块的多副本存储机制、

    NameNode与DataNode之间的心跳检测机制、数据存储等。

    (一)HDFS中NameNode单点问题

    HDFS这种分布式的存储系统,存在中心结点,那么这个中心结点的可靠性就是整个集群的可靠性的关键,对于版本0.20.x的hadoop来说,主要是有一个叫做SecondaryNameNode的机制来解决,这个结点周期性的从NameNode 结点上下载磁盘镜像和日志文件,在本地将日志合并到镜像中,产生新的镜像,上传到NameNode,当NameNode结点重启时就会加载此最新的镜像文件,这个过程叫做CheckPoint,那么SecondaryNameNode会周期性的做CheckPoint,但是这种机制对于单点问题来说不是很理想,因为你做CheckPoint只能保存上次的元数据,那么CheckPoint之后的元数据在NameNode 失效后是会丢失的。

    FaceBook提出了Avatar机制来解决NameNode 的单点问题,这里多设置了一个叫做 Standby NameNode 的结点,原来的NameNode 叫做 PrimaryNameNode, 另外还有一个结点 NFS 用来存储 Primary NameNode 的日志和镜像文件。这里跟前面的解决机制不同的是 Standby NameNode 这个结点是 热备结点, 它不仅具有前面的CheckPoint的功能,还会周期性的读取 NFS结点上的 PrimaryNameNode 的日志来保持命名空间的同步,此外 DataNode 会同时向 Standby NameNode 和 PrimaryNameNode 发送心跳信息和数据块信息,这样,这两个结点的元数据信息是一致的,因此这也是为什么是热备结点的原因了。

    注: 镜像文件存储的是NameNode 的命名空间即目录树,就是将内存中的命名空间持久化到镜像文件中。

    CheckPoint的流程如下图:

    image

    1. SecondaryNameNode 通知 NameNode 开始做CheckPoint,,并且通过远程RPC调用NameNode的rollEditLog()方法建立临时日志文件

    2. SecondaryNameNode从NameNode 上下载镜像和日志文件。

    3. SecondaryNameNode将下载的镜像文件和日志文件合并。

    4. SecondaryNameNode将合并后的镜像上传到NameNode上。

    5. SecondaryNameNode通过远程RPC调用NameNode的rollFsImage()方法,用新的镜像和日志文件代替旧的文件,通知NameNode 结束CheckPoint。

    (二)HDFS数据块副本机制

    在HDFS中一个文件可能有许多的数据块(Block)组成,每个数据块的副本的默认数量是3,其中两个放在同一个机架中,两一个放在其他机架,对于大数据存储来说,这种机制会造成数据的存储空间翻倍,因此需要一定的机制来节省磁盘空间,比如基于历史统计记录的动态副本策略,和FaceBook 的 RAID机制。

    (三)HDFS负载均衡

    NameNode 根据 DataNode发送的心跳信息和数据块信息来掌握 DataNode 的当前状态,HDFS有一个 balancer 工具 , 可以由管理员启动,用来迁移DataNode 之间的数据块,当集群负载较高的时候不宜采用,因为可能会造成网络阻塞,造成客户端延迟过大。

    (四)MapReduce容错

    运行JobTracker 的结点为主结点,用于调度作业和调度MAP 和 Reduce 任务到 TaskTracker 上, 同样TaskTracker也会周期性的向JobTracker 发送心跳信息,保护任务执行的状况,如果在指定时间内没有收到心跳信号,那么认为此结点已经宕机,重新分配 Map 或者 Reduce 任务到其他的结点上。当TaskTracker没有宕机,但是在其上运行的任务失败次数达到一个阈值的时候,JobTracker 会认为其处于高负载状态,将不会再分配任务给此结点,列入黑名单。

    最后关于Avatar机制:

    其实就是应用在hadoop-0.20.2上的补丁程序, 现在很多大型的IT 厂商的集群都将其作为NameNode的单点解决方案。

    该机制主要是提供了一个 Standby NameNode 结点作为 热备 ,这两个NameNode 结点的元数据会保持一致,在PrimaryNameNode 宕机时,Standby NameNode 切换为 PrimaryNameNode 的时间很短。

     

    展开全文
  • 009 微服务容错机制

    2019-03-04 13:46:00
    一 概述 在微服务的调用过程之中,可能会出现下面的问题: [1]当一个微服务调用另外一个微服务的时候,如果被调用的微服务出现问题,就会导致调用者出现问题,如果调用的关系是级联的,就会出现级联...[1]超时机制:如果...

    一 概述

    在微服务的调用过程之中,可能会出现下面的问题:

    [1]当一个微服务调用另外一个微服务的时候,如果被调用的微服务出现问题,就会导致调用者出现问题,如果调用的关系是级联的,就会出现级联错误,发生服务雪崩.

    [2]微服务如果出现共享线程池的情况,一个微服务出现问题,就会影响在此线程池之中的另外线程.

    解决方法:

    在整个微服务架构之中,通常存在下面的三种解决方式

    [1]超时机制:如果一个方法调用出现延迟的情况,立马发生超时错误,放置微服务的调用堆积,造成系统资源耗尽.

    [2]线程隔离:不同的微服务之间使用不同的线程池,防止一个线程池的原因,导致多个微服务出现资源的问题.

    [3]熔断器模式:本质上说,熔断器是一个快速失败的机制,当出现调用问题的时候,立马结束调用,这里面可以使用超时机制进行规避.

       当多次错误发生的时候,就认为这个服务不可用,进行快速失败.熔断器会一个检测的功能,当发现微服务可用,就打开熔断器,进行正常的微服务的调用.

    在springcloud之中,使用hystrix组件帮助我们实现微服务的容错机制.

    从本质上,熔断器就是一个使用快速失败解决资源分配的问题.

     

    二 .Hystrix提供的功能

    [1]failback机制:一旦发生微服务的调用失败,直接进行fallback机制.默认情况下,histrix使用异常机制实现,当然我们也可以使用fallback方法进行容错返回.

    [2]超时机制:一旦方法调用出现超时,立马认为微服务失败,直接进入fallback机制.

    [3]线程隔离:不同的方法调用进入到不同的线程之中,这样彼此的微服务相互的影响降到最低.

    [4]熔断器:一旦微服务多次失败,直接进入到fallback机制,不再做无谓的尝试.同时Hystrix提供半开模式,允许进行一些微服务的调用的尝试,当成功的几率符合设置,熔断器就关闭,进行正常的方法调用.

    转载于:https://www.cnblogs.com/trekxu/p/10470236.html

    展开全文
  • 浅谈Hadoop容错机制

    千次阅读 2013-11-22 14:26:44
    简单介绍一下Hadoop中数据存储的可靠性和完整性,其中包括HDFS的容错机制、NameNode(元数据结点)的单点失效解决机制、Block数据块的多副本存储机制、 NameNode与DataNode之间的心跳检测机制、数据存储等。 (一)...

    简单介绍一下Hadoop中数据存储的可靠性和完整性,其中包括HDFS的容错机制、NameNode(元数据结点)的单点失效解决机制、Block数据块的多副本存储机制、

    NameNode与DataNode之间的心跳检测机制、数据存储等。

    (一)HDFS中NameNode单点问题

    HDFS这种分布式的存储系统,存在中心结点,那么这个中心结点的可靠性就是整个集群的可靠性的关键,对于版本0.20.x的hadoop来说,主要是有一个叫做SecondaryNameNode的机制来解决,这个结点周期性的从NameNode 结点上下载磁盘镜像和日志文件,在本地将日志合并到镜像中,产生新的镜像,上传到NameNode,当NameNode结点重启时就会加载此最新的镜像文件,这个过程叫做CheckPoint,那么SecondaryNameNode会周期性的做CheckPoint,但是这种机制对于单点问题来说不是很理想,因为你做CheckPoint只能保存上次的元数据,那么CheckPoint之后的元数据在NameNode 失效后是会丢失的。

        FaceBook提出了Avatar机制来解决NameNode 的单点问题,这里多设置了一个叫做 Standby NameNode 的结点,原来的NameNode  叫做 PrimaryNameNode, 另外还有一个结点 NFS 用来存储 Primary NameNode 的日志和镜像文件。这里跟前面的解决机制不同的是 Standby NameNode 这个结点是 热备结点, 它不仅具有前面的CheckPoint的功能,还会周期性的读取 NFS结点上的 PrimaryNameNode 的日志来保持命名空间的同步,此外 DataNode 会同时向 Standby NameNode 和 PrimaryNameNode 发送心跳信息和数据块信息,这样,这两个结点的元数据信息是一致的,因此这也是为什么是热备结点的原因了。


    注: 镜像文件存储的是NameNode 的命名空间即目录树,就是将内存中的命名空间持久化到镜像文件中。

    CheckPoint的流程如下图:

    1. SecondaryNameNode 通知 NameNode 开始做CheckPoint,,并且通过远程RPC调用NameNode的rollEditLog()方法建立临时日志文件

    2. SecondaryNameNode从NameNode 上下载镜像和日志文件。

    3. SecondaryNameNode将下载的镜像文件和日志文件合并。

    4. SecondaryNameNode将合并后的镜像上传到NameNode上。

    5. SecondaryNameNode通过远程RPC调用NameNode的rollFsImage()方法,用新的镜像和日志文件代替旧的文件,通知NameNode 结束CheckPoint。

    (二)HDFS数据块副本机制

        在HDFS中一个文件可能有许多的数据块(Block)组成,每个数据块的副本的默认数量是3,其中两个放在同一个机架中,两一个放在其他机架,对于大数据存储来说,这种机制会造成数据的存储空间翻倍,因此需要一定的机制来节省磁盘空间,比如基于历史统计记录的动态副本策略,和FaceBook 的 RAID机制。

    (三)HDFS负载均衡

        NameNode 根据 DataNode发送的心跳信息和数据块信息来掌握 DataNode 的当前状态,HDFS有一个 balancer 工具 , 可以由管理员启动,用来迁移DataNode 之间的数据块,当集群负载较高的时候不宜采用,因为可能会造成网络阻塞,造成客户端延迟过大。

    (四)MapReduce容错

        运行JobTracker 的结点为主结点,用于调度作业和调度MAP 和 Reduce 任务到 TaskTracker 上, 同样TaskTracker也会周期性的向JobTracker 发送心跳信息,保护任务执行的状况,如果在指定时间内没有收到心跳信号,那么认为此结点已经宕机,重新分配 Map 或者 Reduce 任务到其他的结点上。当TaskTracker没有宕机,但是在其上运行的任务失败次数达到一个阈值的时候,JobTracker 会认为其处于高负载状态,将不会再分配任务给此结点,列入黑名单。

    最后关于Avatar机制:

        其实就是应用在hadoop-0.20.2上的补丁程序, 现在很多大型的IT 厂商的集群都将其作为NameNode的单点解决方案。

    该机制主要是提供了一个 Standby NameNode 结点作为 热备 ,这两个NameNode 结点的元数据会保持一致,在PrimaryNameNode 宕机时,Standby NameNode 切换为 PrimaryNameNode 的时间很短。

    参考文献:《实战hadoop》 刘鹏


    展开全文
  • Hadoop2容错机制

    2018-02-09 00:15:47
    在Hadoop1中HDFS和MapReduce均采用了master/slave结构,这种结构虽然具有设计非常简单的优点,但是同时存在master单点故障的问题,所有长时间Hadoop处于仅用于离线存储和计算。Hadoop2中HDFS同样面临着单点故障问题...

            在Hadoop1中HDFS和MapReduce均采用了master/slave结构,这种结构虽然具有设计非常简单的优点,但是同时存在master单点故障的问题,所有长时间Hadoop处于仅用于离线存储和计算。Hadoop2中HDFS同样面临着单点故障问题,但由于每个MapReduce作业拥有自己的作业管理组件(ApplicationMaster),因此不再存在单点问题,但新引入的资源管理系统YARN也采用了Master/slave结构,同样出现了单点故障问题。

            作为一个分布式系统,YARN必须具有一个特点就是高容错性,因此YARN需要考虑ApplicationMaster、NodeManager、Container和ResourceManager等服务或组件容错性、这些服务或组件的容错性机制如下:

        ApplicationMaster容错:不同类型的应用程序拥有不同的ApplicationMaster,而ResouceManager负责监控ApplicationMaster的运行状态,一旦发现它运行失败或者超时,会为其重新分配资源并启动它,至于启动之后ApplicationMaster内部的状态如何恢复需要由自己保证,比如MRAppMaster在作业运行过程中将状态信息动态记录到HDFS上,一旦出现故障重启后,它能够从HDFS读取并恢复之前的运行状态,以减少重新计算带来的开销

        NodeManager容错:如果NodeManager在一定时间内未向ResouceManager汇报心跳信息,则ResouceManager认为它已经死掉了,会将它上面所有正在运行的Container状态置为失败,并告诉对应的ApplicationMaster,以决定如何处理这些Container中运行的任务

        Container容错:如果ApplicationMaster在一定时间内未启动分配到的Container,则ResouceManager会将该Container状态置为失败并回收它,如果一个Container在运行过程中,因为外界原因导致运行失败,则ResouceManager会转告给对应的ApplicationMaster,由它决定如何处理

    Hadoop HA基本框架
            在Master/slave架构中,为了解决Master的单点故障问题通常采用热备方案,即集群中存在一个对外服务的active Master和若干个处于就绪状态的Standby Master,一旦Active Master出现故障,立即采用一定的策略选取某个Standby Master转换为Active Master以正常对外提供服务,同样Hadoop2也是采用这种方案解决各系统的单点故障问题。
            Hadoop2中的HDFS和YARN均采用了基于共享存储的HA解决方案,即Active Master不断将信息写入一个共享存储系统,而Standby Master则不断读取这些信息,以与Active Master的内存信息保持同步,当需要主备切换时,选中的Standby Master需先保证信息完全同步后,再将自己的角色切换至Active Master,目前而言,常用的共享存储系统有以下几个
         Zookeeper: Zookeeper是一个针对大型分布式系统的可靠协调系统,提供的功能包括统一命名服务、配置管理、集群管理、共享锁和队列管理等,需要注意的是,Zookeeper设计目的并不是数据存储,但它的确可以安全可靠的存储少量数据来解决分布式环境下多个服务之间的数据共享问题。

         NFS(Network File System): NFS是一种非常经典的数据共享方式,它可以透过网络,让不同的机器和不同的操作系统之间彼此共享文件
         HDFS: Hadoop自带的分布式文件系统,由于它本身存在单点故障问题,因此Hadoop的单点问题不能够通过他解决
         BookKeeper:由Zookeeper项目产生的一个分支项目,主要用于可靠地记录日志流,它采用的是分布式多副本解决方案
         QJM(Qurom Journal Manager): QJM的基本原理就是用2N+1个节点存储数据,每次有多数据(大于等于N+1)节点成功写入数据即认为该次写成功,并能保证数据高可用,该算法最多容忍N台机器挂掉,如果多于N台挂掉,则这个算法就会失败。
            在Hadoop2中,YARN HA采用了基于zookeeper的方案,而HDFS HA则提供了基于NFS、BookKeeper和QJM的三套实现方案,由于引入了共享存储系统,Hadoop中各个系统实际上是“share nothing but NameNode”,尽管几个系统采用的共享存储不同,但它们的HA架构是相同的,均分为手动模式和自动模式,其中,手动模式是指由管理员通过命令进行主备切换,这通常用于服务升级,自动模式可降低运维成本,但存在潜在危险,手动模式架构如下图,该模式中,Master自身需实现HAServiceProtocol协议,或者由一个实现该协议的服务控制,而管理员可通过一个HAServiceProtocol协议客户端控制各个Master状态。
            手动模式基本架构

    自动模式主要由以下组件构成:

    1. MasterHADaemon:与Master服务运行在同一个进程中,可接收外部RPC命令,以控制Master服务的启动和停止
    2. SharedStorage:共享存储系统,Active Master将信息写入共享存储系统,而Standby Master则读取该信息以保持与Active Master的同步
    3. ZKFailoverController:基于Zookeeper实现的切换控制器,主要由ActiveStandbyElector和HealthMonitor两个核心组件构成,其中ActiveStandbyElector负责与Zookeeper集群交互,通过尝试获取全局锁,以判断所管理的Master是进入Active还是进入Standby状态,HealthMonitor负责监控各个活动Master的状态,以根据他们状态进行状态切换
    4. Zookeeper:核心功能是通过维护一把全局锁控制整个集群有且仅有一个Active Master,当然如果SharedStorge采用了Zookeeper,则还会记录一些其他状态和运行时信息。
              Hadoop HA自动模式框架

    要解决HA问题需考虑以下几个问题
    1、脑裂(brain-split)
    脑裂是指在主备切换时,由于切换不彻底或其他原因,导致客户端和slave误以为出现两个Active Master,最终使得整个集群处于混乱状态,通常采用隔离(Fencing)机制解决脑裂问题,解决脑裂问题需从以下三个方面考虑:

    • 共享存储隔离:确保只有一个Master往共享存储中写数据
    • 客户端隔离:确保只有一个Master可以响应客户端的请求
    • Slave隔离:确保只有一个Master可以向Slave下发命令

    Hadoop公共库中对外提供了两种隔离实现,分别是sshfence和shellfence。其中sshfence是指通过SSH登录目标Master节点上,使用命令fuser将进程杀死;shellfence是指执行一个用户事先定义的shell命令完成隔离
    2、切换对外透明
    为了保证整个切换是对外透明的,Hadoop应保证所有客户端和slave能自动重定向到新的Active Master上,这通常是通过若干次尝试连接就Master不成功后,在重新尝试连接新Master完成的,整个工程有一定延迟,这个可以自行设置RPC客户端尝试机制,尝试次数和尝试超时时间等参数

    展开全文
  • 为解决水声传感器网络的数据传输负载不均衡、容错能力低等问题,刻画水声传感器网络传播动力学特性,分析复杂海洋环境中传感器节点失效原因,建立了簇结构网络演化模型,提出了一种随机游走容错机制,以提高水声...
  • 租约被提议为一种基于时间的机制,可提供对分布式系统中缓存数据的有效一致访问。非拜占庭式故障会影响性能,而不是正确性,并通过短期租约将其影响降到最低。 缓存引入了确保缓存数据与其主要存储位置之间一致性的...
  • 基于评分机制的实用拜占庭容错共识算法,李景然,亓峰,针对区块链的实用拜占庭容错(PBFT)共识算法中存在的网络节点扩展性差和主节点选取不合理等问题,通过引入评分机制,提出了基于评分
  • 和其他分布式系统一样,微服务在网络、硬件和应用层上都会存在更多的问题。由于服务之间是互相依赖,因此任何组件都可能出错导致用户不能访问。为尽可能减少部分中断带来的影响,我们需要构建容错能力强的服务,以...
  • 数据库读写分离,主从同步反查机制引发的问题数据不存在问题 1)、Mysql的主从同步就是当master(主库)发生数据变化的时候,会实时同步到slave(从库)。 2)、主从复制可以水平扩展数据库的负载能力,容错,高可用,...
  • 针对异构并行系统中存在的fail-stop硬件故障,设计并实现了内存检查点的应用容错机制。支持计算恢复后对产生变化的CPU/GPU资源配置进行自适应负载调整。通过在高性能计算机Mole8.5上的实验和分析,验证了异构容错...
  • 容错机制 如果服务提供者相应非常缓慢,那么消费者对提供者的请求就会被强制等待,知道提供者相应超时。在高负载场景下,如果不作任何处理,此类问题可能会导致服务消费者的资源耗尽甚至整个系统崩溃。 雪崩效应 ...
  • 在微服务架构中,一个服务可能会调用很多的其他微服务应用,虽然做了多集群部署,但可能还会存在诸如网络原因或者服务提供者自身处理的原因,或多或少都会出现请求失败或者请求延迟问题,若服务提供者长期未对请求...
  • 容错机制 如果服务提供者相应非常缓慢,那么消费者对提供者的请求就会被强制等待,知道提供者相应超时。在高负载场景下,如果不作任何处理,此类问题可能会导致服务消费者的资源耗尽甚至整个系统崩溃。 雪崩效应 ...
  • 分布式应用中存在错综复杂的相互依赖。 1.1 微服务面临的问题 当系统中某个服务出现延迟或者不可用时,那么整个用户请求都被阻塞,最终导致该用户功能不可用。依赖的服务越多,那么不可用的风险就越大。 高请求量...
  • 在微服务架构中,存在着那么多的单元,若一个单元初夏故障,就很容易因依赖关系而引发故障的蔓延,最终导致整个系统的瘫痪,这样的架构相较传统架构更加不稳定,为了解决这样的问题,产生了断路器等一系列的服务保护机制 ...
  • 代码例子下载:...为了解决这样的问题,产生了断路器等一系列的服务保护机制。在分布式架构中,断路器模式的作用也是类似的,当某个服务单元发生故障之后通过断...
  • 针对带有推进器故障的船舶动力定位系统的鲁棒容错控制问题展开研究.首先,建立更一般且统一的推进器故障模型,该模型能全面描述推进器失效、卡死、中断3种故障情形;然后,设计一种不依赖故障检测模块(FDI)和故障信息...
  •  在微服务架构中,通常会存在多个服务层调用的情况,如果基础服务出现故障可能会发生级联传递,导致整个服务链上的服务不可用为了解决服务级联失败这种问题,在分布式架构中产生了断路器等一系列的服务保护机制。...
  • Hadoop判断的失败有不同级别类型,针对不同级别的失败有不同的处理对策,这就是MapReduce的容错机制。下面是几个不同级别失败的分类: 一、任务失败 分为3种情况:Task失败、子进程JVM退出、超时检测被关闭。 1....
  • 共识算法是区块链技术的核心要素,也是近年来分布式系统研究的热点。共识(Consensus)和一致性(Consistency)虽然近似,但还是有一些差别... 大多不考虑拜占庭容错问题,即假设不存在恶意篡改和伪造数据的拜占庭节点 ...
  • 服务容错保护 在微服务的架构中,存在着那么多单元服务,若一个单元出现故障,就很...为了解决这个问题,产生了断路器等一系列的服务保护机制。 spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能...
  • redis主从复制中的哨兵机制 1.上述配置存在问题 如果master宕机则不能及时处理,影响整体的“可用性”...redis-sentinel,哨兵机制是主从复制架构的容错机制。 1)如何配置哨兵 # cp /usr/local/redis-3.2.11/sent...
  • 为了解决这个问题,产生了断路器等一系列的服务保护机制。 spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能。它也是基于Netflix的开源框架Hystrix实现的。,该框架的目标在于通过控制那...
  • 为了解决这样的问题, 产生了断路器等一系列的服务保护机制  Spring Cloud Hystrix实现了断路器、 线程隔离等一系列服务保护功能。它也是基于Netflix的开源框架Hystrix实现的, 该框架的目标在于通过控制那些...
  • 在微服务架构中,存在着很多的服务单元,若一个单元出现故障,就很容易因依赖关系而引发故障的蔓延,最终导致整个系统的瘫痪,为了解决这样的问题,产生了断路器等一系列的服务保护机制 当某个服务单元发生故障之后...
  • 存在着多个服务单元,若一个单元出现故障,就很容易因依赖关系而出现故障的蔓延,最终导致整个系统的瘫痪,这样的架构相较传统的架构更加不稳定,为了解决这样的问题,产生了断路器等一系列的服务保护机制。...
  • Redis复制机制

    2019-03-31 17:16:49
    在生产环境中,单个数据库实例常常存在诸如系统崩溃、网络连接闪断或突然断电等单点故障问题。与其他大多数数据库系统一样,Redis也提供了一个复制机制,使得数据能够从一个Redis服务器(master, 主实例)复制到一个...
  • 在微服务架构中,我们将系统...为了解决这一系列的问题,断路器等一系列服务保护机制出现了。  在微服务架构中,存在很多单元,若其中一个单元出现故障,容易因为依赖关系而引发故障的蔓延,最终导致系统瘫痪,为了...
  • 那么当服务端存在多个节点的集群时,zookeeper 上会维护不同集群节点,对于客户端而言,他需要一种负载均衡机制来实现目标服务的请求负载。 通过负载均衡,可以让每个服务器节点获得适合自己处理能力的负载 负载...

空空如也

空空如也

1 2 3 4 5 6
收藏数 102
精华内容 40
关键字:

容错机制存在问题