前面提到過每個Chubby單元是由五個副本組成的，這五個副本中需要選舉產生一個主服務器，這種選舉本質上就是一個一致性問題。在實際的執行過程中，Chubby使用Paxos算法來解決這個何題。
主服務器產生后客戶端的所有讀寫操作都是由主服務器來完成的。讀操作很簡單，客戶直接從主服務器上讀取所需數據即可，但是寫操作就會涉及數據一致性的問題。為了保證客戶的寫操作能夠同步到所有的服務器上，系統再次利用了Paxos算法。因此，可以看出Paxos算法在分布式一致性問題中的作用是巨大的
2.安全性
Chubby采用的是ACL形式的安全保障措施。系統中有三種ACL名，分別是寫ACL名（WriteACLName)、讀 ACL名（ReadACLName)和變更ACL名（ChaugeACL Name)。只要不被覆寫，子節點都是直接繼承父節點的ACL名。ACL同樣被保存在文件中，它是節點元數據的一部分，用戶在進行相關操作時首先需要通過ACL來獲取相應的授權。圖2-11是一個用戶成功寫文件所需經歷的過程。
用戶chinacloud提出向文件CLOUD中寫入內容的請求。CLOUD首先讀取自身的寫ACL名婦女，接著在fun中査到了chinacloud這一行記錄，于是返回信息允許chinacloud 對文件進行寫操作，此時chinadoud才被允許向CLOUD寫入內容。其他的操作和寫操作類似。
3.性能優化
為了滿足系統的高可擴展性，Chubby目前已經采取了一些措施。比如提高主服務器默認的租約期、使用協議轉換服務將Chubby協議轉換成較簡單的協議、客戶端一致性緩存等。除此之外，Google的工程師們還考慮使用代理（Proxy)和分區（Partition)技術，雖然目前這兩種技術并沒有實際使用，但是在設計時還是被包含進系統，不排除將來使用的可能。代理可以減少主服務器處理KeepAlive以及讀請求帶來的服務器負載，但是它并不能減少寫操作帶來的通信量。Google自己的數據統計表明，在所有的請求中，寫請求僅占極少的一部分，幾乎可以忽略不計。使用分區技術的話可以將一個單元的命名空間（Name Space)劃分成AT份。除了少量的跨分區通信外，大部分的分區都可以獨自地處理服務請求。同過分區可以減少各個分區上的讀寫通信量，但不能減少KeepAlive請求的緝信量。因此，如果需要的話，將代理和分區技術結合起來使用才可以明顯提髙系統同時處理的服務請求量。
