- 正确性与性能
- 一致性
前面提到过每个Chubby单元是由5个副本组成的,这5个副本中需要选举产生一个主服务器,这种选举本质上就是一个一致性问题。在实际的执行过程中,Chubby使用Paxos算法来解决这个问题。
- 安全性
Chubby采用的是ACL形式的安全保障措施。系统中有三种ACL名,分别是写ACL名(Write ACL Name)、读ACL名(Read ACL Name)和变更ACL名(Change ACL Name)。只要没被覆写,子节点都是直接继承父节点的ACL名。ACL同样被保存在文件中,它是节点元数据的一部分,用户在进行相关的操作时首先需要通过ACL来获取相应的授权。图2-11是一个用户成功写文件所需经历的过程。
用户chinacloud请求想文件CLOUD中写入内容。CLOUD首先读取自身的写ACL名是fun,接着在fun中查到了chinacloud这一行记录,于是返回信息允许chinacloud对文件进行写操作,此时chinacloud才被允许想CLOUD写入内容。其他的操作和写操作类似。
- 性能优化
为了满足系统的高可扩展性,Chubby目前已经采取了一些措施。比如提高主服务器默认的租约期、使用协议转换服务器将Chubby协议转换成较简单的协议。还有就是使用上面提到的客户端一致性缓存。除此之外,Google的工程师们还考虑使用代理(Proxy)和分区(Partition)技术,虽然目前这两种技术并没有实际使用,但是在设计的时候还是包含进系统,不排除将来使用的可能。代理可以减少主服务器处理KeepAlive以及读请求带来的服务器负载,但是它并不能减少写操作带来的通信量。不过根据Google自己的数据统计表明,在所有的请求中,写请求仅占极少的一部分,几乎可以忽略不计。使用分区技术的话可以将一个单元的命名空间(Name Space)划分成N份。除了少量的跨分区通信外,大部分的分区都可以独自的处理服务请求。通过分区可以减少各个分区上的读写通信量,但不能减少KeepAlive请求的通信量。因此,如果需要的话,将代理和分区技术结合起来使用才可以明显提高系统同时处理的服务请求量。
点击加载更多评论>>