1、一致性
    前面提到过每个Chubby单元是由五个副本组成的，这五个副本中需要选举产生一个主服务器，这种选举本质上就是一个一致性问题。在实际执行过程中，Chubby使用Paxos算法来解决这个问题
    主服务器产生后客户端的所有读写操作都是由主服务器来完成的。读操作很简单，客户直接从主服务器上读取所需数据即可，但是写操作就涉及数据一致性的问题了。为了保证客户的写操作能够同步到所有的服务器上，系统再次利用了Paxos算法。因此，可以看出Paxos算法在分布式一直性问题中的作用是巨大的。

    2、安全性
    Chubby 采用的是 ACL形式的安全保障措施。系然中有三种ACL名，分别是写ACL名（Write ACL Name)、读ACL名 (Read ACLName)和变更ACL名(Change ACL Name)。只要不被覆写,子节点都是直接继承父节点的 ACL名。ACL同样被保存在文件中,它是节点元数据的一部分，用户在进行相关操作时首先需要通过 ACL 来获取相应的授权。图4.15是一个用户成功写文件所需经历的过程。
    用户chinacloud请求向文件 CLOUD 中写入内容。CLOUD首先读取自身的写ACL名是fun,接着在fun中查到了chinacloud这一行记录，于是返回信息允许chinacloud对文件进行写操作,此时 chinacloud才被允许向CLOUD写入内容。其他的操作和写操作类似。
    4515322C682F229143CBF4052B371ABC.jpg

    3、性能优化
    为了满足系统的高可扩展性，Chubby目前已经采取了一些措施。比如提高主服务器默认的租约期、使用协议转换服务将Chubby 协议转换成较简单的协议。还有就是使用上面提到的客户端一致性缓存。除此之外，Google 的工程师们还考虑使用代理（Proxy)和分区(Partition)技术，虽然目前这两种技术并没有实际使用，但是在设计的时候还是被包含进系统，不排除将来使用的可能。代理可以减少主服务器处理KeepAlive 以及读请求带来的服务器负载，但是它并不能减少写操作带来的通信量。不过根据Google自己的数据统计表明，在所有的请求中，写请求仅占极少的一部分，几乎可以忽略不计。使用分区技术的话可以将一个单元的命名空间(Name Space）划分成N份。除了少量的跨分区通信外，大部分的分区都可以独自地处理服务请求。通过分区可以减少各个分区上的读写通信量，但不能减少KeepAlive 请求的通信量。因此，如果需要的话，将代理和分区技术结合起来使用才可以明显提高系统同时处理的服务请求量。