容错纠错机制（共4篇）
容错纠错机制 篇1
多核处理器和多核集群已经成为市场的主流,但串行编程无法从多核架构中直接获益,并行编程成为必然的选择。传统的openMP和MPI是被广泛使用的并行编程接口,分别对应共享存储和分布式系统,但这两者的抽象度依然不高,没有从根本上将用户从并行实现的细节中解放出来。同时,熟练掌握并应用复杂的编译制导命令与消息传递接口所耗精力与时间也使得并行编程效率不能满足应用增长的需求。
MapReduce是Google开发的一种简洁抽象的分布式计算模型,其目标是使那些没有多少并行编程经验的程序员能够尽可能快地开发并行应用。在MapReduce框架中,每一次计算请求,被称为作业。在分布式计算Map/Reduce框架中,为了完成这个作业,它进行两步走的战略,首先是将其拆分成若干个Map任务,分配到不同的机器上去执行,每一个Map任务拿输入文件的一部分作为自己的输入,经过一些计算,生成某种格式的中间文件,这种格式必须与最终所需的文件格式完全一致,但是仅仅包含一部分数据。等到所有Map任务完成后,它会进入下一个步骤,用以合并这些中间文件获得最后的输出文件。此时,系统会生成若干个Reduce任务,同样也是分配到不同的机器去执行,它的目标就是将若干个Map任务生成的中间文件汇总到最后的输出文件中去。经过如上步骤,所需的目标文件生成。整个算法的关键,就在于增加了一个中间文件生成的流程,大大提高了灵活性,使其分布式扩展性得到了保证。
1. 基本框架
与分布式文件系统类似,Map/Reduce的集群同样由三类服务器构成。其中作业服务器负责管理运行在此框架下所有作业。与HDFS的主控服务器类似,它也是作为单点存在,从而简化了负责的同步流程。具体的负责执行用户定义操作的是任务服务器,每一个作业被拆分成很多的任务,包括Map任务和Reduce任务等,任务是具体执行的基本单元,它们都需要分配到合适任务服务器上去执行,任务服务器一边执行一边向作业服务器汇报各个任务的状态,以此来帮助作业服务器了解作业执行的整体情况,分配新的任务等。
除了作业的管理者执行者,还需要有一个任务的提交者,这就是客户端。与分布式文件系统一样,客户端也不是一个单独的进程,而是一组API,用户需要自定义好自己需要的内容,经由客户端相关的代码,将作业及其相关内容和配置,提交到作业服务器去,并时刻监控执行的状况。
与HDFS的通信机制相同,Map/Reduce也是用了协议接口来进行服务器间的交流。实现者作为RPC服务器,调用者经由RPC的代理进行调用,如此,完成大部分的通信,具体服务器的架构,和其中运行的各个协议状况,参见上图。
从图中可以看到,与HDFS相比,相关的协议减少,客户端与任务服务器,任务服务器之间,都不再有直接通信关系。这并不意味着客户端就不需要了解具体任务的执行状况,也不意味着任务服务器之间不需要了解别家任务执行的情形,而是由于整个集群各机器的联系比HDFS复杂得多,直接通信难以维系,所以都统一由作业服务器整理转发。
2. MapReduce编程模型调度机制
(1) master选择空闲的worker,然后分配给他们每个一个map任务或者一个reduce任务。
(2) map阶段:map worker从输入数据中解析key/value对,传给用户定义的Map函数产生中间key/value对,然后将中间key/value对写入本地磁盘并将其散布在由分割函数指定的R个区域中,最后将这些缓存对在局部磁盘的具体位置传回给master。
(3) reduce阶段:reduce worker先从master得到中间key/value对在map worker局部磁盘上的位置信息,并使用远程过程调用从map worker的局部磁盘中读取数据。读取完所有数据之后,reduceworker按照中间key进行排序,reduce worker遍历排好序的中间数据,将把key和与它对应的中间value传给用户提供的Reduce函数,最后将Reduce函数的输出写到与这个reduce对应的最终输出文件中。
(4)当所有的map和reduce任务被完成之后,master唤醒用户程序,MapReduce调用返回到用户代码。
3. MapReduce采用的容错机制
MapReduce模型具有很强的容错性,当worker节点出现错误时,只需要将该worker节点屏蔽在系统外等待修复,并将该worker上执行的程序迁移到其他worker上重新执行,同时将该迁移信息通过Master发送给需要该节点处理结果的节点。MapReduce使用检查点的方式来处理Master出错失败的问题,当Master出现错误时,可以根据最近的一个检查点重新选择一个节点作为Master并由此检查点位置继续运行。
Master周期性的ping各个worker,检测worker的状态。当一段时间之后没有响应,master将认为worker已经出现故障。在该worker上正在处理的map或reduce任务将被设置为空闲状态,以便重新调度。完成的map任务需要重新执行,那是因为它们的输出是存储在出现故障机器上的本地磁盘,而导致不可访问。完成的reduce任务输出结果是存储在全局文件系统而不存在这个问题。
4. 结束语
MapReduce作为一种较为流行的云计算编程模型,在云计算系统中应用广阔。但是基于它的开发工具Hadoop并不完善。特别是其调度算法过于简单,判断需要进行推测执行的任务的算法造成过多任务需要推测执行,降低了整个系统的性能。改进Map2Reduce的开发工具,包括任务调度器、底层数据存储系统、输入数据切分、监控“云”系统等方面是将来一段时间的主要发展方向。另外,将MapReduce的思想运用在云计算以外的其他方面也是一个流行的研究方向。
容错纠错机制 篇2
近年来，陇西县立足县情实际和干部队伍成长规律，积极探索建立鼓励创新、宽容失误、容错纠错的政策机制，强化正向激励和监督约束，旗帜鲜明地为敢于担当的干部担当、为敢于负责的干部负责，着力营造干部干事创业的浓郁氛围。
一、提升干部“想为”的思想意识是建立容错纠错机制的前提
党的以来，随着全面从严治党不断走向深入，党员干部队伍中出现了工作畏难、不敢担当、求稳怕乱、活力减退等“为官不为”、“为官怕为”的现象。要着力解决干部“不想为”的思想问题，首先要强化思想引导，提升干部“想为”的觉悟。要积极开展中国特色社会主义理论、理想信念、党章党规、党的宗旨等教育，严格规范党内政治生活，教育引导广大公务员增强政治意识、宗旨意识、大局意识和责任意识。近年来，陇西县认真落实县委会、县委中心组、四大家联席会定期学习制度，修订完善全县理论学习“六个一”制度，充分发挥各级领导干部的示范表率作用，坚持“四个带头”，定期组织领导干部参加“富民兴陇”讲座，邀请省市知名专家开展现场教学，扎实开展“合格党员我先行”集中志愿服务、“主题党日”活动、“三讲四送五评”等活动，着力构建共同学习、同步提升的良好格局。实践证明，思想是行动的先导，只有各级干部的思想认识提高了，才能把思想自觉转化为工作自觉。其次要端正用人导向，树立干部“想为”的标杆，倡导注重实绩、群众公认，容许干部在改革创新、干事创业、主动作为中出现失误和错误，鼓励干部敢于担当，敢于创新，激发干部干事创业、拼搏进取的积极性，为其他干部干事创业提供看得见、摸得着的“标杆”。陇西县委坚持在基层扶贫第一线，重大项目最前沿识别、培养和选拔干部，先后对488名精准扶贫一线成效突出、大胆创新、敢于担当的优秀干部提拔重用，切实把“想为”的思想意识最大限度凝聚起来，把“想为”的鲜明导向正确树立起来。实践证明，只有真正树立科学的用人导向，才能按照好干部标准和“三严三实”要求，选准干部配强班子，才能把各级干部心思、智慧和力量凝聚到推动工作上来。
容错纠错机制 篇3
机载雷达作为航空电子设备的关键组成部分, 需要满足高可靠性的要求。将系统错误产生的影响降至最低、实现容错的运行机制至关重要。构建容错系统最基本的思想是设置冗余。目前诸多的容错技术通过硬件冗余、软件冗余、信息冗余中的一种或几种来实现错误的检测恢复[1⁃2]。其中一些容错方法具有通用性。如检查点回卷恢复容错方法能够处理绝大多数软硬件暂时性失效导致的错误, 硬件多机冗余方法能解决硬件永久失效的问题[3]。
机载雷达的用途和应用环境决定了其应满足实时性高和体积小的要求, 因此机载雷达系统多构建在分布嵌入式环境下。分布嵌入式环境复杂的软硬件结构使得机载雷达产生的错误具有多样性, 各类错误出现的位置、对系统功能的影响以及影响的严重性各不相同。尽管一些容错方法适用于较多类型的错误处理。然而对出现在不同位置、不同种类的错误采用同一种容错方法是不适当的。因为通用的容错方法的开销相对较大, 对于某些类型的错误不是最优的容错选择, 会增加不必要的容错开销。本文针对机载雷达系统的特点提出一种多层划分的容错体系结构, 致力于减小为原系统实现容错机制所产生的开销, 对于提高雷达可靠性的同时保证雷达的工作性能具有重要意义。在多层划分的容错体系结构下, 需要实现一种能够准确诊断错误、隔离错误、进行重新配置并恢复系统预定状态的方法。为此设计了一种分布式冗余管理协议来实现错误的诊断和隔离, 在确定故障节点的情况下管理冗余接替并进行拓扑重构。考虑到硬件冗余的容错方法具有较高的成本及机载空间占用, 结合低卷回代价的检查点回卷恢复软件容错手段能够平衡系统容错在时间与空间方面的开销。
1 多层划分容错结构
机载雷达系统由天线、发射机、接收机、处理机及它们之间的接口、传输与控制总线构成。各分机功能正常运行以及分机之间协同有序的工作保证了雷达系统的正常运行。容错系统的构建可视为在原系统的基础上实现错误检测机制和一系列错误处理机制的过程。雷达系统可能发生错误的类型、位置、粒度以及对系统功能影响的严重程度多种多样, 针对同一种错误通常有多种错误处理机制能够实现针对该类型错误的容错, 然而采取不同错误处理机制的代价也是不同的。尽管一些容错技术具有通用性, 适用于较多类型的错误处理。然而通用的容错方法的开销相对较大, 对于某些类型的错误不是最优的容错选择, 会增加不必要的容错开销。本文根据容错机制实现的位置将机载雷达容错系统分为三个层次:芯片电路层、节点层和系统层。每个层次都会针对相应的软硬件环境和粒度实现相应层次的故障诊断、故障隔离、重新配置以及状态的复位或恢复。
在设计容错系统时, 首先将系统的容错需求分解到各层次;然后每个层次根据分解的容错需求汇总需处理的故障类型, 并为之设置相应的故障处理方式;最后以每层故障处理结果是否能够满足整个系统的容错需求为评价标准, 设置各层的故障处理结果信息。由于多层划分容错设计追求容错代价的最小化, 系统在实现容错目标的前提下更倾向于在较低的层次解决故障, 因此容错的过程是自底向上的。故障处理结果信息以
多层划分的容错体系结构如图1所示, 其清晰而易维护, 针对容错需求设计的故障处理方式贯穿雷达系统的每一层次。且呈现了多层划分容错系统在每一层可能处理的部分错误类型以及错误处理的结果。低层上报的未解决故障将同相邻高层检测到的故障一同被本层的预定义故障处理流程处理。这种自底向上构建容错系统的方式试图在每一层尽可能的处理相应级别的错误, 避免底层的微小错误导致高代价的故障处理方式的介入。同时这种方式能够整合层级错误类型, 实现层与层之间透明的错误传输和处理, 降低了容错处理的复杂度。
芯片电路层容错机制提供贴近硬件底层的容错措施。如缓存的奇偶校验保护、内存错误检查和纠正 (Error Correcting Codes) 以及晶体管的三重模件冗余 (Triple Modular Redundant) 技术等[4⁃5]。致力于保证构成独立功能的软件节点的容错运行。芯片电路层容错机制对于提高整个系统的可靠性非常重要, 因为越接近底层的错误越难以在高层采取有效措施对错误进行纠正, 高层针对底层错误的解决方式通常是复位或制定相应的冗余接替, 这种方式的代价是很高的。以雷达处理机中实现脉冲压缩功能的某一节点的某关键电子元件故障为例, 通常的容错方法是脉压节点的硬件冗余, 但是如果针对节点内的关键电子元件采用多个冗余元件实现低粒度容错, 即能以更小的空间代价替代节点冗余实现此类错误的容错。如果同时使用这两种方法, 则大大提高了雷达处理机的可靠性。
节点层容错机制实现在构成独立功能的软件节点上, 致力于保证软件相应功能单元的容错运行。节点层的容错机制能够处理多数芯片电路层抛出的无法解决的错误情况, 结合硬件冗余采用诸如看门狗定时器以及检查点备份等软件冗余方法能够复位或恢复节点运行状态, 或提供允许程度内的降级服务。同样以雷达处理机脉冲压缩单元为例, 脉压单元使用n个节点并行工作实现原始数据的分段脉压, 并使用一个脉压冗余节点。如果有两个脉压节点发生故障无法运行, 则节点层容错机制采取相应容错措施保证脉压单元的n-1个有效节点对外提供低速率的脉压处理降级服务。
系统层以整个系统对外提供的功能或服务为对象, 根据节点层的状态选择最优的容错方法并对外反馈错误信息及处理方式。对于非复位类型的容错方法, 系统层容错机制负责各节点间容错运行的一致性状态, 保证整个系统故障与恢复前后的状态一致。系统层容错机制使用分布式冗余管理协议来实现节点的错误诊断和错误隔离, 根据优化的容错策略重新配置以实现系统状态的复位或恢复。系统层负责冗余管理的协调和一致, 使得故障节点本身以及其他相关节点能够在故障处理后协调运行, 对外提供正确的功能和服务。
各层次的容错机制并非孤立的, 而是相互协同实现整个雷达系统的容错功能。低层次容错机制尽可能的解决出现的错误, 如果某些类型的错误无法完全解决, 则将错误抛给高层进行解决。举例来说, 假设雷达系统实现目标检测功能的某个芯片上出现了访存越界错误, 对于此类错误芯片电路层无法进行有效的恢复, 只能将错误类型通知相应的节点层容错机制, 于是节点层的访存异常处理流程将被执行, 终止相应的进程并使用冗余接替, 如果不存在冗余则试图提供降级服务保证节点提供的目标检测功能仍然有效, 最后将节点状态和错误处理方式通知系统层。系统层会根据出错节点的状态通知与之功能相关的节点如目标跟踪节点, 并控制目标跟踪节点更改算法以适应目标检测节点的变化情况。
2 分布式冗余管理协议
故障检测是实现容错系统非常重要的一环。在多层划分容错机制中, 节点间接口故障是一类特殊的故障。因为这类故障的发生会导致层次之间故障类型及故障处理结果信息传递的失败。接口的故障多与组件的电气特性有关, 往往导致大粒度的冗余接替。为此设计了分布式冗余管理协议, 不仅可以用于节点的故障判定, 并且能够在确定故障节点的情况下管理冗余接替并进行拓扑重构。分布式冗余管理协议在故障检测及隔离方面具有时间复杂度低、实现简单的特点。
协议规定在包含n个节点的系统中, 每个节点向其他k (2≤k≤n-1) 个节点发送周期性的心跳消息, 并假设这些消息能够实现无错传输被其他节点正确的接收到。协议通过消息携带的关于节点自身的运行状态信息来判断相应节点是否发生错误或失效, 并使得相关的无错节点获得系统内出错节点的信息保持一致。任意一个节点发送的心跳消息都需要被系统内其他k个节点所确认并维护, 则系统内的每个节点都负责维护k个不同节点的运行状态信息。同时每个节点自身的运行状态信息也分布在k个不同节点上。其中一定时间内无法收到来自某个节点的信息的情况被认为是节点失效。协议可以保证系统在至多有k-1个节点失效的情况下仍能准确检测到系统内任一节点的运行状态信息, k值可以根据系统设计情况和可靠性需求灵活指定。
2.1 初始化及心跳检测
(1) 对于最多包含n个节点的系统, 系统内的每个节点都维护一个大小为n的环形哈希表, 哈希表的每个位置都与各节点一一对应。定义哈希函数Hash () , 来自节点Ni (1≤i≤n) 的运行状态信息将被写入当前节点哈希表中Hash (Ni) 的位置。定义变量state表示节点的运行状态:state值为1表示节点运行状态正常;state值为0表示节点故障或失效。
(2) 系统初始化时各节点哈希表的所有位置将被置零, 每个节点将设置current指针指向其维护的哈希表中自身的位置;设置start指针指向其维护的哈希表中第k前驱的位置;并设置end指针指向其维护的哈希表中第k后继的位置。其中start= (current-k) %n, end= (current+k) %n。从当前节点出发, 逆时针方向逐个访问处于有效状态的节点直到start指针指向位置可以获得当前节点的k个前驱节点的运行状态信息。
(3) 系统内节点Ni (1≤i≤n) 每经过心跳周期τ向其k个处于有效状态的后继节点S1, S2, ⋯, Sk发送心跳消息。Ni的第i后继节点Si在接收到Ni的消息后, 将其哈希表中Hash (Ni) 的位置写入Ni的运行状态信息。节点状态正常置1, 节点故障置0。
(4) 为节点Ni的k个前驱节点P1, P2, ⋯, Pk设置接收超时时间τ1。如果当前时间t>τ+τ1, Ni仍未接收到其第i前驱节点Pi的消息, 表明节点Pi已经失效。则将Ni哈希表中Hash (Pi) 的位置写入0。
(5) 经过时间τ2 (τ2>τ1) 后, 以k为步长选择系统内任意én kù个节点, 查看这些节点哈希表中的k个前驱节点的运行状态信息, 即可获得整个系统内所有节点的运行状况。
2.2 节点失效的拓扑重构
如果协议通过心跳检测发现某一节点失效, 则需重新建立现存有效节点之间的关系。单点失效的情况将会涉及其k个前驱节点和k个后继节点的拓扑重构。如果节点Ni失效, 则将其k个前驱节点P1, P2, ⋯, Pk的哈希表中的end指针分别移动到下一位置, 即令end= (end+1) %n;并将其k个后继节点S1, S2, ⋯, Sk的哈希表中的start指针分别移动到上一位置, 即令start= (start-1) %n。
图2和图3分别反映了失效节点后继和前驱的拓扑重构操作。
3 检查点回卷恢复容错方法
考虑到机载雷达系统的应用环境和自身特点, 过多采用硬件冗余的容错策略并不合适。因为较多的硬件冗余不仅会占用宝贵的机载空间, 也会提高机载雷达的成本。另外, 在机载雷达的某个子系统故障时采用硬件冗余的容错方式只能恢复到初始状态, 这样会丢失故障前的结果和状态。而雷达系统常常需要跟踪测量多个目标, 从初始状态重新建立目标轨迹跟踪需要相当长的时间, 因此需要寻找一种具有较小回卷代价的容错方法。检查点回卷恢复容错方法为容错系统提供了一种低卷回代价的软件容错手段。
检查点回卷恢复容错方法是一种通过软件冗余实现的容错方法。各节点在雷达运行过程中以同步或异步的方式实时保存单元检查点。如果雷达运行时发生故障, 可以通过各系统备份的满足全局一致性状态的一组检查点将整个雷达软件系统恢复到之前的状态, 并保证恢复前后状态的一致性和数据的完整性。单元检查点的保存在节点层实现, 每个单元的检查点是其所在节点的嵌入式芯片中的关键结构的数据映像文件, 文件内容由各类寄存器、堆栈、只读ROM中的数据按一定格式构成。单元检查点的实现是与硬件体系结构紧密耦合的, 可以通过函数库的方式提供给高级程序调用。目前相关领域技术已比较成熟。
3.1 检查点的一致性状态
检查点的一致性状态是指:如果某一运行实体采取检查点时的状态反映接收到来自另一发送实体的消息, 那么对应的发送实体在某一检查点时的状态也反映此消息已发出, 那么两个状态处于一致性状态, 所属不同实体的两个检查点叫做一致性检查点[6]。如果全局检查点中的任意两个局部检查点都符合一致性约束, 那么全局检查点也是一致的。然而在节点故障时有两类消息会使系统处于不一致的状态, 它们分别是在途消息和孤儿消息。
令Ca, x表示进程Pa的第x个检查点, Sa, x表示检查点Ca, x时的系统状态。
∃进程Pa, Pb, 检查点对 (Ca, x, Cb, y) , 进程Pa发送给进程Pb的消息m, 使得消息已发送状态send (m) ∈Sa, x同时消息已接收状态recv (m) ∈Sb, y, 则称m为在途消息。
∃进程Pa, Pb, 检查点对 (Ca, x, Cb, y) , 进程Pa发送给进程Pb的消息m, 使得recv (m) ∈Sb, y, 同时send (m) ∉Sa, x, 则称m为孤儿消息。
3.2 基于悲观消息日志的异步检查点回卷恢复策略
通过异步方式实现全局检查点备份的方法赋予系统内各节点很高的灵活性, 这种方式允许各节点独立的保存本地检查点, 能够满足机载雷达系统的实时性要求。然而在选择满足一致性状态的全局检查点的过程中容易产生多米诺效应[7]。多米诺效应是指在回卷的过程中为了避免出现孤儿消息或在途消息导致的检查点不一致状态而产生的过度回卷的现象, 极端的情况可能使系统回卷到初始状态, 从而降低恢复的效率。
为了避免异步方式实现全局检查点可能出现的多米诺效应, 可以采取记录消息日志的辅助手段, 对于在程序运行中所遇到的任何一个不确定的消息发送动作, 系统都假设在此动作发生后系统会出现故障。于是在每个不确定的消息发送动作产生结果之前, 将能够复现此消息传输过程的关键信息能够保存到稳定的存储介质中, 然后继续程序的运行。这种策略是工程领域常用的悲观策略, 可以称之为悲观消息日志方法。借助这种手段在系统出现故障, 寻找可恢复的全局一致性状态时能够消除孤儿消息、在途消息以及多米诺效应带来的不利影响。
采用悲观消息日志方法具有以下优点:首先无需为异步实现的全局检查点设计复杂的协议保证其一致性状态, 实现简单;再者在回卷恢复时仅需从最近的全局检查点开始, 并且仅对出错的进程执行回卷操作, 恢复的代价小。
4 仿真实验
实验借助Qui KLab实时嵌入式系统测试工具进行系统的仿真、故障注入及结果分析。实验通过主机开发测试模型对被测系统的交联对象的内特性与外部环境进行仿真, 构建测试环境模型与接口驱动模型。并借助FIU自动测试故障注入箱实现实时环境下的电气故障模拟。表1描述了采用多层划分容错机制实现的系统与采用一般容错方法实现的系统在典型故障输入时的表现。
5 结论
本文针对雷达系统的结构特点提出一种多层划分的容错体系结构, 通过自底向上的方式构建容错系统并试图在每一层尽可能的处理相应级别的错误, 避免底层的微小错误导致高代价的故障处理方式的介入, 由此可以提高容错处理的效率。为容错系统设计的分布式冗余管理协议能够实现节点的错误诊断和错误隔离, 为容错系统节点级的故障检测和重新配置提供了简单有效的方法。最后利用基于悲观日志的异步检查点回卷恢复策略实现程序状态的回卷恢复, 为机载雷达系统提供了一种低卷回代价的软件容错手段。算法具有良好的时间性能和扩展性, 能够满足机载雷达系统应用环境的需求。
摘要：针对机载雷达系统的高可靠性要求, 提出了一种多层划分的容错体系结构。采用自底向上分层的方式构建容错系统并试图在每一层尽可能的处理相应级别的错误, 避免由微小错误导致高代价故障处理方式的介入。在此基础上设计分布式冗余管理协议实现节点的错误诊断、错误隔离以及重新配置, 并采用一种基于悲观消息日志的异步检查点回卷恢复策略用于程序状态的复位或恢复。最后通过系统仿真故障注入的方式验证采用多层划分容错机制设计的系统具有更高的容错效率。
关键词：机载雷达系统,容错体系,多层划分,检查点回卷恢复
参考文献
[1]AIDEMARK J.Node level fault tolerance for embedded real time systems[D].Goteborg, Sweden:Department of Computer Engineering, Chalmers University of Technology, 2004.
[2]VIJAYKUMAR T N, POMERANZ I, CHENG K.Transient fault recovery using simultaneous multithreading[C]//Proc.of the-29th International Symposium on Computer Architecture.Washington, DC, USA:IEEE Computer Society, 2002:8798.
[3]AFONSO F, SILVA C, TAVARES A, et al.Application level fault tolerance in real time embedded systems[C]//Proc.of In ternational Symposium on Industrial Embedded Systems.[S.1.]:IEEE Press, 2008:126-133.
[4]AIDEMARK J, FOLKESSON P, KARLSSON J.A framework for node level fault tolerance in distributed real time systems[C]//Proceedings of the-2005 International Conference on De pendable Systems and Networks.Yokohama, Japan:IEEE Computer Society, 2005:656-665.
[5]刘耀, 胡越明, 金利峰.高可靠计算机系统的容错技术[J].计算机工程, 2004, 30 (z1) :590-592.
[6]GOIRI I, JULIA F, GUITART J, et al.Checkpoint based fault tolerant Infrastructure for virtualized service providers[C]//2010 IEEE Network Operations and Management Symposium.Osaka:IEEE, 2010:455-462.
[7]SARIDAKIS T.Design patterns for checkpoint based rollback recovery[C]//Proceedings of the-10th Conference on Pattern Languages of Programs.IL, USA:Robert Allerton Park and Conference Center, 2003:1-27.
[8]GAISLER J.A portable and fault tolerant microprocessor based on the SPARC V8 architecture[C]//Proceedings of the-2002 In ternational Conference on Dependable Systems and Networks.Bethesda, MD, USA:IEEE Computer Society, 2002:409415.
[9]傅忠传, 陈红松, 崔刚.处理器容错技术研究与展望[J].计算机研究与发展, 2007, 44 (1) :154-160.
干部容错纠错机制心得体会 篇4
一是提高认识，着力解决“不敢容”“不愿容”的问题。
县纪委认真学习领会中省市纪委精神，统一思想、狠抓落实。采取集体研学、业务培训、干部自学等多种形式加强学习宣传容错纠错机制的力度，认真讲解容错的申请、核实、认定、反馈、报备的相关程序和要求，使党员干部深刻领会掌握容错纠错机制的精神实质和本质内涵，也使其在工作中卸下了包袱、打消了顾虑。成立了容错纠错机制建设推进领导小组，由县纪委书记任组长，纪委分管副书记任副组长，案件审理室具体负责此项机制的督促落实、分析研判、督查考核、情况汇总等工作，为推进落实容错纠错机制提供坚强的政治保障。同时，通过明察暗访、不定期的方式对各单位贯彻落实容错纠错的情况进行检查，指导和督促各单位精准使用、规范使用、大胆使用。
二是制定措施，着力解决“谁来容”“对谁容”的问题。