码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2015-02-05 23:15:41      阅读:502      评论:0      收藏:0      [点我收藏+]

标签:

 

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

一、单机系统的故障恢复

  单机程序可能因为程序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节点已经失效。

 

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

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

标签:

原文地址:http://www.cnblogs.com/lhonglwl/p/4276126.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!