大数据&云计算|多图干货 | 分布式文件系统设计，该从哪些方面考虑？( 二 )
本文插图
该图中 GFS master 即为 GFS 的中心节点 ， GF chunkserver 为 GFS 的存储节点 。 其操作路径如下：
Client 向中心节点请求“查询某个文件的某部分数据”；
中心节点返回文件所在的位置 (哪台 chunkserver 上的哪个文件) 以及字节区间信息；
Client 根据中心节点返回的信息 ， 向对应的 chunk server 直接发送数据读取的请求；
chunk server 返回数据 。
在这种方案里 ， 一般中心节点并不参与真正的数据读写 ， 而是将文件 meta 信息返回给 Client 之后 ， 即由 Client 与数据节点直接通信 。 其主要目的是降低中心节点的负载 ， 防止其成为瓶颈 。 这种有中心节点的方案 ， 在各种存储类系统中得到了广泛应用 ， 因为中心节点易控制、功能强大 。
无中心节点
以 ceph 为代表 ， 每个节点都是自治的、自管理的 ， 整个 ceph 集群只包含一类节点 ， 如下图 (最下层红色的 RADOS 就是 ceph 定义的“同时包含 meta 数据和文件数据”的节点) 。
本文插图
无中心化的最大优点是解决了中心节点自身的瓶颈 ， 这也就是 ceph 号称可以无限向上扩容的原因 。 但由 Client 直接和 Server 通信 ， 那么 Client 必须要知道 ， 当对某个文件进行操作时 ， 它该访问集群中的哪个节点 。 ceph 提供了一个很强大的原创算法来解决这个问题——CRUSH 算法 。
五、持久化
对于文件系统来说 ， 持久化是根本 ， 只要 Client 收到了 Server 保存成功的回应之后 ， 数据就不应该丢失 。 这主要是通过多副本的方式来解决 ， 但在分布式环境下 ， 多副本有这几个问题要面对 。
如何保证每个副本的数据是一致的?
如何分散副本 ， 以使灾难发生时 ， 不至于所有副本都被损坏?
怎么检测被损坏或数据过期的副本 ， 以及如何处理?
该返回哪个副本给 Client?
如何保证每个副本的数据是一致的
同步写入是保证副本数据一致的最直接的办法 。 当 Client 写入一个文件的时候 ， Server 会等待所有副本都被成功写入 ， 再返回给 Client 。
这种方式简单、有保障 ， 唯一的缺陷就是性能会受到影响 。 假设有 3 个副本 ， 如果每个副本需要 N 秒 ， 则可能会阻塞 Client 3N 秒的时间 ， 有几种方式 ， 可以对其进行优化：
并行写：由一个副本作为主副本 ， 并行发送数据给其他副本；
链式写：几个副本组成一个链 (chain) ， 并不是等内容都接受到了再往后传播 ， 而是像流一样 ， 边接收上游传递过来的数据 ， 一边传递给下游 。
还有一种方式是采用 CAP 中所说的 W+R>N 的方式 ， 比如 3 副本 (N=3) 的情况 ， W＝2 ， R＝2 ， 即成功写入 2 个就认为成功 ， 读的时候也要从 2 个副本中读 。 这种方式通过牺牲一定的读成本 ， 来降低写成本 ， 同时增加写入的可用性 。 这种方式在分布式文件系统中用地比较少 。
如何分散副本 ， 以使灾难发生时 ， 不至于所有副本都被损坏
这主要避免的是某机房或某城市发生自然环境故障的情况 ， 所以有一个副本应该分配地比较远 。 它的副作用是会带来这个副本的写入性能可能会有一定的下降 ， 因为它离 Client 最远 。 所以如果在物理条件上无法保证够用的网络带宽的话 ， 则读写副本的策略上需要做一定考虑 。 可以参考同步写入只写 2 副本、较远副本异步写入的方式 ， 同时为了保证一致性 ， 读取的时候又要注意一些 ， 避免读取到异步写入副本的过时数据 。
怎么检测被损坏或数据过期的副本 ， 以及如何处理
推荐阅读
- 智能穿戴|漫步者DreamPods体验：外观精致佩戴舒适降噪是最大惊喜
- 数据|智领云荣登“中国大数据企业50强” | 2020大数据产业生态大会盛大召开
- 大数据|华云数据荣获中国大数据50强、2020数字赋能先锋企业30强，入选大数据产业发展白皮书及百佳案例
- 驱动中国|即信Fintech智研中心：银行践行社交化运营的要诀--渠道通 交互通 数据通
- 行业互联网|华云数据荣获中国大数据50强、2020数字赋能先锋企业30强，入选大数据产业发展白皮书及百佳案例
- 技术编程|数据结构001之简介
- 行业互联网|爱数亮相第八届医药健康论坛，以数据赋能药企数字化
- 技术编程|边缘云计算到底是什么？
- 行业互联网|智领云荣登“中国大数据企业50强”| 大数据产业生态大会
- 互联网|图匠数据CTO梁柱锦：利用AI与大数据提升线下零售管理能力 | 公开课预告