分布式系统之故障检测及恢复

数据分布和数据读写问题已经大致了解了,现在咱讲讲异常情况的处理。老规矩先讲讲单机系统的故障恢复的解决方案。

一、单机系统的故障恢复

  单机程序可能因为程序bug、宕机等因素导致进程死掉。当进程重启时,往往希望服务能恢复到原来的一致状态。状态的恢复依赖数据和日志。在此我们假设磁盘是OK的(否则无法恢复),即原数据问题暂不考虑,So我们需要考虑的是操作的重现。

  1、操作日志:不论是传统的关系型数据库或者近几年比较火的NoSQL,操作日志都是这些系统必备的故障恢复手段。

   a) 操作日志的形式:传统的关系型数据库的操作日志分为UNDO(回滚)、REDO(重做),UNDO/REDO日志3种。比如一个事务T对记录X执行加2操作,记录X=1,修改过后X=3,那么UNDO日志为<T, X, 1>,REDO日志为<T, X, 3>,UNDO/REDO日志为<T, X, 1, 3>。关系型数据库一般采用UNDO/REDO日志格式。对于NoSql,比如redis,则有自己的日志格式协议文件,叫做aof文件。读者有兴趣可以自己去了解下。

   b) 操作日志的性能优化:有时候系统也许对性能要求较高,允许一定程度的数据丢失。每次操作日志都进行追加可能并不是一个最好的解决方案。这时可以考虑成组提交,操作日志可以积累到一定时间或量时再批量刷入日志文件中。比如redis提供3种AOF选项:i) 关闭AOF文件(不建议) ii) 每次执行操作时都写AOF文件 iii) 每秒写一次AOF文件。对数据敏感性不是太高的系统可以选择每秒fsync一次到AOF文件。哪怕系统出现故障,也只会丢失1s的数据。

  2、CheckPoint:如果仅靠操作日志对故障的系统进行恢复,当系统运行时间较长,操作日志巨大时,则通过REDO日志进行故障恢复的时间可能会让人难以忍受。因此我们需要定期将内存中的数据转储到磁盘上,这样就可以仅仅对转储后的REDO日志进行恢复即可,大大加快了故障恢复的时间。这就是CheckPoint。Redis中将此叫做RDB持久化。

二、分布式系统的故障恢复

  因为分布式系统中每个数据都有多个副本,所以只需总控节点选择一个新的副本成为主副本进行继续提供写服务即可。需要注意的则是:分布式系统数据节点出现的故障是分为临时性和永久性两种情况的。总控节点会对下线的节点进行探测,如果一定时间,节点重新可用,则为临时性故障。否则为永久性故障。

  临时性故障:重新上线的节点需要从其他副本中增量同步这段时间丢失的数据。然后重新提供服务。

  永久性故障:需要选择一个新的节点,拷贝副本的数据,成为新的副本节点。

  

  另外,总控节点也有可能出现故障,目前非P2P的分布式系统基本都是通过强一致性的备机达到HA的效果。多个备机的时候,则可能需要通过选举协议来选择新的总控节点。最著名的选举协议就是大名鼎鼎的Paxos。这个后面会专门对此协议进行介绍。

三、分布式系统的故障探测

  对于分布式系统而言,故障探测是容错处理的先决条件。心跳包(HeartBeat)在单机系统中是进行故障检测的最常用的手段。总控节点每隔一段时间向work节点发送一个心跳包,如果一切正常,work节点就会回复总控节点的心跳包,同时心跳包中会含有work节点的机器的运行情况(如load值, cpu和IO的使用情况)。否则总控节点尝试一定次数后仍收不到回包则认为work节点出现了故障。

  但普通的心跳检测机制是无协议和承诺的,它的检测结果并不一定可靠。比如可能网络问题或者work节点繁忙未应答,总控节点认为work节点失效,但其实work节点仍在正常提供服务。在分布式系统中,这个是存在一定业务风险的。他的问题主要在于它是单方面判定节点失效。比如,总控节点认为work节点失效,所以为服务重新选取了新的主服务节点,而判定失效的节点可能正在继续正常工作,导致"双主"问题。

  为此,分布式系统通常使用租约(lease)来进行故障检测。租约有以下特性:

  1、授权:颁发者在一定期限内給予持有者一定权利的协议。

  2、时限:Lease 表达了颁发者在一定期限内的承诺,只要未过期颁发者必须严格遵守 lease 约定的承诺。

  3、续约:Lease 的持有者在期限内使用颁发者的承诺,但lease一旦过期必须放弃使用或者重新和颁发者续约。

  因此,总控节点可以给work节点发放租约,work节点在有效期内才可以提供服务。快到期时work节点需要向总控节点进行续约才能继续提供服务。若比如出现网络故障,否则总控节点可以认为work节点已经不再提供服务,work节点也因为未成功续约而停止服务。这样就可以保证服务的一致性。

  租约的一个问题是超时判定问题,因为不同节点之间的本地时钟可以不一致,所以需要总控节点对超时时间增加一个放宽量。比如work节点的租约有效期为1分钟,总控节点需要超时65s时才可以判定work节点已经失效。

  分布式系统最难解决的便是一致性问题。后面俺将讲讲一些经典的解决一致性问题的分布式协议。

时间: 2025-01-24 07:57:19

分布式系统之故障检测及恢复的相关文章

微服务架构(Microservices)

说在前面 好久没写博文了,心里痒痒(也许是换工作后,有点时间了吧).最近好像谈论微服务的人比较多,也开始学习一下,但是都有E文,看起来半懂不懂的. Martinfowler的<微服务>,也算是入门必读了.有人翻译过,但是只有一半.还是自己练练手吧. 微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上,却有着显著特征. "微服务

【阿里云产品公测】结构化数据服务OTS之JavaSDK初体验

[阿里云产品公测]结构化数据服务OTS之JavaSDK初体验 作者:阿里云用户蓝色之鹰 一.OTS简单介绍 OTS 是构建在阿里云飞天分布式系统之上的NoSQL数据库服务,提供海量结构化数据的存储和实时访问.NoSQL,泛指非关系型的数据库.随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展.OTS应用程序可以使用阿

开源项目使用经验原则

软件开发领域有一个流行的原则:DRY,Don't repeat yourself,我们翻译过来更形象通俗:不要重复造轮子.开源项目主要目的是共享,其实就是为了让大家不要重复造轮子,尤其是在互联网这样一个快速发展的领域,速度就是生命,引入开源项目,可以节省大量的人力和时间,大大加快业务的发展速度,何乐而不为呢? 然而现实往往没有那么美好,开源项目虽然节省了大量的人力和时间,但带来的问题也不少,相信绝大部分同学都踩过开源软件的坑,小的影响可能是宕机半小时,大的问题可能是丢失几十万数据,甚至灾难性的事

Corosync+pacemaker

Corosync是OpenAIS发展到Wilson版本后衍生出来的开放性集群引擎工程.可以说Corosync是OpenAIS工程的一部分,Corosync执行高可用应用程序的通信组系统,它有以下特征: 一个封闭的程序组通信模式,这个模式提供一种虚拟的同步方式来保证能够复制服务器的状态. 一个简单可用性管理组件,这个管理组件可以重新启动应用程序的进程当它失败后. 一个配置和内存数据的统计,内存数据能够被设置,回复,接受通知的更改信息. 一个定额的系统,定额完成或者丢失时通知应用程序. corosy

K8S基础概念

一.核心概念 1.Node Node作为集群中的工作节点,运行真正的应用程序,在Node上Kubernetes管理的最小运行单元是Pod.Node上运行着Kubernetes的Kubelet.kube-proxy服务进程,这些服务进程负责Pod的创建.启动.监控.重启.销毁.以及实现软件模式的负载均衡. Node包含的信息: Node地址:主机的IP地址,或Node ID. Node的运行状态:Pending.Running.Terminated三种状态. Node Condition:- No

Cororsync+Pacemaker

Corosync是OpenAIS发展到Wilson版本后衍生出来的开放性集群引擎工程.可以说Corosync是OpenAIS工程的一部分,Corosync执行高可用应用程序的通信组系统,它有以下特征: 一个封闭的程序组通信模式,这个模式提供一种虚拟的同步方式来保证能够复制服务器的状态. 一个简单可用性管理组件,这个管理组件可以重新启动应用程序的进程当它失败后. 一个配置和内存数据的统计,内存数据能够被设置,回复,接受通知的更改信息. 一个定额的系统,定额完成或者丢失时通知应用程序. corosy

Pacemaker+ISCSI 实现Apache高可用实战

Pacemaker 1.1 概述 pacemaker(直译:心脏起搏器),是一个群集资源管理器.它实现最大可用性群集服务(亦称资源管理)的节点和资源级故障检测和恢复使用您的首选集群基础设施(OpenAIS的或Heaerbeat)提供的消息和成员能力. Pacemaker 承担集群资源管理者(CRM - Cluster Resource Manager)的角色,它是一款开源的高可用资源管理软件,适合各种大小集群.Pacemaker 由 Novell 支持,SLES HAE 就是用 Pacemake

微服务&mdash;&mdash;Martin Flower【翻译】

原文地址 本文内容 微服务 微服务风格的特性 组件与服务 围绕业务功能进行组织 产品不是项目 强化终端及弱化通道 分散治理 分散数据管理 基础设施自动化 容错性设计 设计改进    微服务是未来吗 其它 微服务系统多大 微服务与SOA 多语言多选择 实践标准和强制标准 让做对事更容易 断路器circuit breaker和产品中现有的代码 同步是有害的   微服务 "微服务架构"一词在过去几年里广泛的传播,它用于描述一种独立部署的软件应用设计方式.这种架构方式并没有非常准确的定义,但是

Linux下使用Corosync+Pacemaker详解及安装

Corosync详解 OpenAIS概述 OpenAIS是基于SA Forum 标准的集群框架的应用程序接口规范.OpenAIS提供一种集群模式,这个模式包括集群框架,集群成员管理,通信方式,集群监测等,能够为集群软件或工具提供满足 AIS标准的集群接口,但是它没有集群资源管理功能,不能独立形成一个集群.OpenAIS组件包括AMF,CLM,CKPT,EVT,LCK,MSG,TMR,CPG,EVS等,因OpenAIS分支不同,组件略有不同.(下面介绍)OpenAIS主要包含三个分支:Picach