單機(jī)系統(tǒng)故障恢復(fù)策略

在單機(jī)系統(tǒng)中，程序可能遭遇程序錯(cuò)誤、崩潰等導(dǎo)致進(jìn)程終止。為了在系統(tǒng)重啟后恢復(fù)服務(wù)至先前狀態(tài)，依賴于數(shù)據(jù)和日志的完整性。假設(shè)磁盤狀態(tài)良好，我們主要聚焦于操作的重現(xiàn)機(jī)制。

1. 操作日志

操作日志是數(shù)據(jù)庫（無論是關(guān)系型還是NoSQL）實(shí)現(xiàn)故障恢復(fù)的關(guān)鍵工具。

• 日志形式：關(guān)系型數(shù)據(jù)庫常采用UNDO/REDO日志，記錄事務(wù)的撤銷和重做信息。例如，事務(wù)T將記錄X的值從1改為3，則UNDO日志記錄為<T,X,1>，REDO日志為<T,X,3>，或合并記錄為<T,X,1,3>。NoSQL數(shù)據(jù)庫如Redis則使用AOF（Append On* File）文件記錄操作日志，具有獨(dú)特的日志格式。

• 性能優(yōu)化：對(duì)于性能敏感的系統(tǒng)，頻繁寫入日志可能不是*選擇。此時(shí)，可采用批量提交策略，即累積一定數(shù)量的操作后再統(tǒng)一寫入日志。Redis提供了多種AOF寫入策略，包括每秒寫入一次，以平衡數(shù)據(jù)一致性和性能。

2. CheckPoint機(jī)制

隨著系統(tǒng)運(yùn)行時(shí)間的增長，操作日志可能變得龐大，僅依賴REDO日志進(jìn)行恢復(fù)將耗時(shí)過長。因此，引入CheckPoint機(jī)制，定期將內(nèi)存中的數(shù)據(jù)快照保存到磁盤上。這樣，在恢復(fù)時(shí)只需重放CheckPoint之后的REDO日志，顯著縮短恢復(fù)時(shí)間。Redis中的RDB持久化即實(shí)現(xiàn)了這一機(jī)制。

分布式系統(tǒng)故障恢復(fù)策略

分布式系統(tǒng)中，每個(gè)數(shù)據(jù)項(xiàng)擁有多個(gè)副本，故障恢復(fù)時(shí)可通過選舉新的主副本來繼續(xù)服務(wù)。根據(jù)故障類型（臨時(shí)性或*性），恢復(fù)策略有所不同。

• 臨時(shí)性故障：節(jié)點(diǎn)重新上線后，需從其他副本同步缺失的數(shù)據(jù)，然后恢復(fù)服務(wù)。
• *性故障：需選擇新節(jié)點(diǎn)，復(fù)制現(xiàn)有副本數(shù)據(jù)，成為新的副本節(jié)點(diǎn)。

此外，總控節(jié)點(diǎn)也可能故障，需通過強(qiáng)一致性的備機(jī)或選舉協(xié)議（如Paxos）來確保高可用性（HA）。

分布式系統(tǒng)故障探測

故障探測是分布式系統(tǒng)容錯(cuò)處理的基礎(chǔ)。心跳包是常用的探測手段，但存在誤判風(fēng)險(xiǎn)。為此，引入租約（Lease）機(jī)制以增強(qiáng)可靠性。

• 租約特性：包括授權(quán)、時(shí)限和續(xù)約。總控節(jié)點(diǎn)向工作節(jié)點(diǎn)發(fā)放租約，工作節(jié)點(diǎn)在有效期內(nèi)提供服務(wù)，并需定期續(xù)約。若續(xù)約失敗或超時(shí)，則視為故障，確保服務(wù)一致性。
• 超時(shí)判定：考慮節(jié)點(diǎn)間時(shí)鐘差異，總控節(jié)點(diǎn)在判定超時(shí)時(shí)會(huì)設(shè)置一定的放寬量，以避免誤判。

一致性問題

分布式系統(tǒng)面臨的*挑戰(zhàn)之一是保持?jǐn)?shù)據(jù)一致性。后續(xù)將深入探討解決一致性問題的經(jīng)典分布式協(xié)議。