江苏龙网

  1. 首页 > 资讯 > 科技 > >

大数据&云计算|多图干货 | 分布式文件系统设计，该从哪些方面考虑？( 四 )



中心节点共享存储设备——部署多台中心节点 ， 但它们共享同一个存储外设 / 数据库 ， meta 信息都放在这里 ， 中心节点自身是无状态的 。 这种模式下 ， 中心节点的请求处理能力大为增强 ， 但性能会受一定影响 。 iRODS 就是采用这种方式 。
七、高可用性
中心节点的高可用
中心节点的高可用 ， 不仅要保证自身应用的高可用 ， 还得保证 meta data 的数据高可用 。
meta data 的高可用主要是数据持久化 ， 并且需要备份机制保证不丢 。 一般方法是增加一个从节点 ， 主节点的数据实时同步到从节点上 。 也有采用共享磁盘 ， 通过 raid1 的硬件资源来保障高可用 。 显然增加从节点的主备方式更易于部署 。
meta data 的数据持久化策略有以下几种方式 。
直接保存到存储引擎上 ， 一般是数据库 。 直接以文件形式保存到磁盘上 ， 也不是不可以 ， 但因为 meta 信息是结构化数据 ， 这样相当于自己研发出一套小型数据库来 ， 复杂化了 。
保存日志数据到磁盘文件 (类似 MySQL 的 binlog 或 Redis 的 aof) ， 系统启动时在内存中重建成结果数据 ， 提供服务 。 修改时先修改磁盘日志文件 ， 然后更新内存数据 。 这种方式简单易用 。

当前内存服务 + 日志文件持久化是主流方式 。 一是纯内存操作 ， 效率很高 ， 日志文件的写也是顺序写；二是不依赖外部组件 ， 独立部署 。
为了解决日志文件会随着时间增长越来越大的问题 ， 以让系统能以尽快启动和恢复 ， 需要辅助以内存快照的方式——定期将内存 dump 保存 ， 只保留在 dump 时刻之后的日志文件 。 这样当恢复时 ， 从最新一次的内存 dump 文件开始 ， 找其对应的 checkpoint 之后的日志文件开始重播 。
存储节点的高可用
在前面“持久化”章节 ， 在保证数据副本不丢失的情况下 ， 也就保证了其的高可用性 。
八、性能优化和缓存一致性
这些年随着基础设施的发展 ， 局域网内千兆甚至万兆的带宽已经比较普遍 ， 以万兆计算 ， 每秒传输大约 1250M 字节的数据 ， 而 SATA 磁盘的读写速度这些年基本达到瓶颈 ， 在 300-500M/s 附近 ， 也就是纯读写的话 ， 网络已经超过了磁盘的能力 ， 不再是瓶颈了 ， 像 NAS 网络磁盘这些年也开始普及起来 。
但这并不代表 ， 没有必要对读写进行优化 ， 毕竟网络读写的速度还是远慢于内存的读写 。 常见的优化方法主要有：
内存中缓存文件内容；
预加载数据块 ， 以避免客户端等待；

合并读写请求 ， 也就是将单次请求做些积累 ， 以批量方式发送给 Server 端 。
缓存的使用在提高读写性能的同时 ， 也会带来数据不一致的问题：
会出现更新丢失的现象 。 当多个 Client 在一个时间段内 ， 先后写入同一个文件时 ， 先写入的 Client 可能会丢失其写入内容 ， 因为可能会被后写入的 Client 的内容覆盖掉；
数据可见性问题 。 Client 读取的是自己的缓存 ， 在其过期之前 ， 如果别的 Client 更新了文件内容 ， 它是看不到的；也就是说 ， 在同一时间 ， 不同 Client 读取同一个文件 ， 内容可能不一致 。
这类问题有几种方法：
文件只读不改：一旦文件被 create 了 ， 就只能读不能修改 。 这样 Client 端的缓存 ， 就不存在不一致的问题；
通过锁：用锁的话还要考虑不同的粒度 。 写的时候是否允许其他 Client 读? 读的时候是否允许其他 Client 写? 这是在性能和一致性之间的权衡 ， 作为文件系统来说 ， 由于对业务并没有约束性 ， 所以要做出合理的权衡 ， 比较困难 ， 因此最好是提供不同粒度的锁 ， 由业务端来选择 。 但这样的副作用是 ， 业务端的使用成本抬高了 。
九、安全性

由于分布式文件存储系统 ， 肯定是一个多客户端使用、多租户的一个产品 ， 而它又存储了可能是很重要的信息 ， 所以安全性是它的重要部分 。


推荐阅读


上一篇：互联网|区块链带来的巨大机会 居然不是发币？这篇文章告诉你

下一篇：互联网圈内事官方|两天“扫货”三家公司股份，腾讯在下什么大棋？