圖2-10中，從左到右的水平方向表示時間在增加，斜向上的箭頭表示一次KeepAlive 請求，斜向下的箭頭則是主服務器的一次回應。M1、M2、M3表示不同的主服務器租用期。CWC2、Q則是客戶端對主服務器租用期時長做出的—個估計。KeepAHve是周期發送的一種信息，它主要有兩方面的功能：延遲租約的有效期和攜帶事件信息告訴用戶更新。主要的事件包括文件內容被修改、子節點的增加、刪除和修改、主服務器出錯、句柄失效等。正常情況下，通過KeepAlive握手協議租用期會得到延長，事件也會及時地通知給用戶。但是由于系統有一定的失效概率，引入故障處理措施是很有必要的。通常情況下系統可能會出現兩種故障：客戶端租用期過期和主服務器故障，對于這兩種情況系統有著不同的應對方式。
1.客戶端租約過期
剛開始時，客戶端向主服務器發出一個KeepAlive請求（見圖2-10中的1),如果有需要通知的事件時則主服務器會立刻做出回應，否則主服務器并不立刻對這個請求做出回應，而是等到客戶端的租約期C1快結束的時候才做出回應（見圖2-10中的2),并更新主服務器租約期為M2?？蛻舳嗽诮拥竭@個回應后認為該主服務器仍處于活躍狀態，于是將租約期更新為C2并立刻發出新的KeepAlive請求（見圖2-10中的3)。同樣的，主服務器可能不是立刻回應而是等待C2接近結束，但是在這個過程中主服務器出現故障停止使 用。在等待了一碰時間后C2到期，由于并沒有收到主服務器的回應，系統向客戶端發出一個危險（Jeopardy)事件，客戶端清空并暫時停用自己的緩存，從而進入一個稱為寬限期（Grace Period)的危險狀態。這個寬限期默認是45秒。在寬限期內，客戶端不會立刻斷開其與服務器端的聯系，而是不斷地做探詢。圖2-10中新的主服務器很快被重新選出，當它接到客戶端的第一個KeepAlive請求（見圖2-10中的4)時會拒絕（見圖2-10 中的5),因為這個請求的紀元號（Epoch Number)錯誤。不同主服務器的紀元號不相同，客戶端的每次請求都需要這個號來保證合理的請求是針對當前的主服務器?？蛻舳嗽谥鞣掌骶芙^之后會使用新的紀元號來發送KeepAlive請求（見圖2-10中的6)。新的主服務器接受這個請求并立刻做出回應（見圖2-10中的7)。如果客戶端接收到這個回應的 時間仍處于寬限期內，系統會恢復到安全狀態，租約期更新為C3。如果在寬限期未接到主服務器的相關回應，客戶端終止當前的會話。
剛開始時，客戶端向主服務器發出一個KeepAlive請求（見圖2-10中的1),如果有需要通知的事件時則主服務器會立刻做出回應，否則主服務器并不立刻對這個請求做出回應，而是等到客戶端的租約期C1快結束的時候才做出回應（見圖2-10中的2),并更新主服務器租約期為M2?？蛻舳嗽诮拥竭@個回應后認為該主服務器仍處于活躍狀態，于是將租約期更新為C2并立刻發出新的KeepAlive請求（見圖2-10中的3)。同樣的，主服務器可能不是立刻回應而是等待C2接近結束，但是在這個過程中主服務器出現故障停止使 用。在等待了一碰時間后C2到期，由于并沒有收到主服務器的回應，系統向客戶端發出一個危險（Jeopardy)事件，客戶端清空并暫時停用自己的緩存，從而進入一個稱為寬限期（Grace Period)的危險狀態。這個寬限期默認是45秒。在寬限期內，客戶端不會立刻斷開其與服務器端的聯系，而是不斷地做探詢。圖2-10中新的主服務器很快被重新選出，當它接到客戶端的第一個KeepAlive請求（見圖2-10中的4)時會拒絕（見圖2-10 中的5),因為這個請求的紀元號（Epoch Number)錯誤。不同主服務器的紀元號不相同，客戶端的每次請求都需要這個號來保證合理的請求是針對當前的主服務器?？蛻舳嗽谥鞣掌骶芙^之后會使用新的紀元號來發送KeepAlive請求（見圖2-10中的6)。新的主服務器接受這個請求并立刻做出回應（見圖2-10中的7)。如果客戶端接收到這個回應的 時間仍處于寬限期內，系統會恢復到安全狀態，租約期更新為C3。如果在寬限期未接到主服務器的相關回應，客戶端終止當前的會話。
2.主服務器出錯
在客戶端和主服務器端進行通信時可能會遇到主服務器故障，圖2-10就出現了這種情況。正常情況下舊的主服務器出現故障后系統會很快地選舉出新的主服務器，新選舉的主服務器在完全運行前需要經歷以下九個步驟。
在客戶端和主服務器端進行通信時可能會遇到主服務器故障，圖2-10就出現了這種情況。正常情況下舊的主服務器出現故障后系統會很快地選舉出新的主服務器，新選舉的主服務器在完全運行前需要經歷以下九個步驟。
(1)產生一個新的紀元號以便今后客戶端通信時使用，這能保證當前的主服務器不必處理針對舊的主服務器的請求。
(2)只處理主服務器位置相關的信息，不處理會話相關的信息。
(3)構建處理會話和鎖所需的內部數據結構。
(4)允許客戶端發送KeepAlive請求，不處理其他會話相關的信息。
(5,)向每個會話發送一個故障事件，促使所有的客戶端清空緩存。
(6)等待直到所有的會話都收到故障事件或會話終止。
(7)開始允許執行所有的操作.。
(8)如果客戶端使用了舊的句柄則需要為其重新構建新的句柄。
(9)一定時間段后（1分鐘)，刪除沒有被打開過的臨時文件夾。
如果這一過程在寬限期內順利完成，則用戶不會感覺到任何故障的發生，也就是說新舊主服務器的替換對于用戶來說是透明的，用戶感覺到的僅僅是一個延遲。使用寬限期的 .好處正是如此。
在系統實現時，Chubby還使用了一致性客戶端緩存（Consistent Client-Sid Cadiing：)技術，這樣做的目的是減少通信壓力，降低通信頻率。在客戶端保存一個和單元上數據一致的本地緩存，需要時客戶可以直接從緩存中取出數據而不用再和主服務器通信。當某個文件數據或者元數據需要修改時，主服務器首先將這個修改阻塞；然后通過查詢主服務器自身維護的一個緩存表，向對修改的數據進行了緩存的所有客戶端發送一個無效標志(Invalidation)。
客戶端收到這個無效標志后會返回一個確認（Ackowledge)，主服務器在收到所有的確認后才解除阻塞并完成這次修改。這個過程的執行效率非常高，僅僅需要發送一次無效標志即可，因為對于沒有返回確認的節點，主搌務器直接認為其是未緩存的。
客戶端收到這個無效標志后會返回一個確認（Ackowledge)，主服務器在收到所有的確認后才解除阻塞并完成這次修改。這個過程的執行效率非常高，僅僅需要發送一次無效標志即可，因為對于沒有返回確認的節點，主搌務器直接認為其是未緩存的。
