google 文件系统 设计预期:
1. 系统由许多廉价普通组件组成。 (
组件失效是一种常态)
2. 系统支持 大小文件存储
3. 负载中主要包含两种读操作:大规模的流式读取和小规模随机读取。
4. 负载中还包括许多大规模的顺序的写操作,追加数据到文件尾部。
5. 系统必须高效的实现良好定义的多客户端并行追加到一个文件的语意。
6. 高度可用的带宽比低延迟更加重要
主服务器保存三种主要类型的元数据:
. 文件和块的命名空间
. 文件到块的映射
. 以及每个块副本的位置
系统交互:
- 客户机向主服务器询问哪一个块服务器保存了当前的租约,以及其他副本的位置(主服务器和存储器不直接相连)。如果没有一个块服务器有租约,主服务器就选择一个副本给它一
个租约(没有被显示出来)。
- 主服务器回复主块的标识符以及其他副本的位置。客户机为了后续的操作缓存这个数据。只有主块不可用,或者主块回复说它已经不在拥有租约的
时候,客户机才需要重新跟主服务器联络。
- 客户机把数据推送到所有的副本上(数据流-可以客户端全部分发,也可以优化分发)。客户机可以用任意的顺序推送。每个块服务器会把这些数据保存在它的内部LRU缓冲内,直到数据被使用或
者过期。通过把数据流和控制流分离,我们可以基于网络负载状况对昂贵的数据流进行规划,以提高性能,而不用去管哪个块服务器是主块。
- 所有的副本都被确认已经得到数据后,客户机发送写请求到主块(控制流-主块分发)。这个请求标识了早前推送到所有副本的数据。主块为收到的所有操作分配连续的
序列号,这些可能来自不同的客户机。它依照序列号的顺序把这些操作应用到它自己的本地状态中。
- 主块把写请求传递到所有的二级副本。每个二级副本依照主块分配的序列号的顺序应用这些操作。
- 所有二级副本回复主块说明他们已经完成操作。
- 主块回复客户机。任何副本产生的错误都会报告给客户机。错误的情况下,主块和一些二级副本可能成功的写入了数据。(如果主块写入失败,操
作就不会被分配序列号,也不会被传递。)客户端请求被确认为失败,已经修改的区域保持不一致的状态。我们的客户机代码通过重复失败的操作来处理这样的错
误。在完全从头开始写入之前,可能会先从步骤3到步骤7进行几次尝试。
客户端发送数据到 块服务器 中的
数据流优化分发 :
为了避免网络瓶颈和延迟过长的连接,每个机器都把数据传送到在网络拓扑中最近的机器。
最后,我们利用在TCP连接上管道化数据传输来最小化延迟。块服务器一旦
得到一些数据,
马上开始传递它们。管道化对我们帮助极大,因为我们使用
全双工连接的交换网络。马上发送数据不会降低接收的速度。
阅读(1302) | 评论(0) | 转发(0) |