存储系统的那些事

　　存储系统从其与生俱来的使命来说，就难以挣脱庞大系统的魔咒。无论是从单机时代的文件系统，照旧厥后C/S或B/S结构下数据库这样的存储中心件兴起，照旧现在炙手可热的云存储服务来说，存储都很庞大，而且是越来越庞大。

　　存储为什么会庞大，要从什么是存储谈起。存储这个词很是普通，存储 + 盘算（操作）就组成了一个质朴的盘算机模子。简朴来说，存储就是卖力维持盘算系统的状态的单元。从维持状态的角度，我们会有最质朴的可靠性要求。好比单机时代的文件系统，机械断电、程序故障、系统重启等通例的异常，文件系统必须可以准确地应对，甚至对于磁盘扇区损坏，文件系统也需要思量只管将损失降到最低。对于大部门的营业程序而言，你只需要重点关注营业的正常分支流程就行，对于出乎意料的情形，通常只需抛出一个错误，告诉用户你不应这么玩。可是对于存储系统，你需要破费绝大部门精神在种种异常情形的处置惩罚上，甚至你应该以为，这些庞杂的、多样的错误分支处置惩罚，才是存储系统的“正常营业逻辑”。

　　到了互联网时代，有了C/S或B/S结构，存储系统又有了新指标：可用性。为了保证服务质量，那些用户看不见的服务器程序必须时时保持在线，最好做到逻辑上是不宕机的（可用性100%）。服务器程序怎么才气做到高可用性？谜底是存储中心件。没有存储中心件，意味着所有的营业程序，都必须思量每做一步就对状态举行持久化，以便自己挂掉后另一台服务器（或者自己重启后），知道之前事情到那里了，接下去应该做些什么。可是对状态举行持久化（也就是存储）会很是繁琐，若是每个营业都自己实现，肩负无疑很是极重。但若是有了高可用的存储中心件，服务器端的营业程序就只需操作存储中心件来更新状态，通过同时汇海多份营业程序的实例做互备和负载平衡，很容易实现营业逻辑上不宕机。

　　以是，数据库这样的存储中心件泛起基本上是历史一定。只管数据库很通用，但它决不会是唯一的存储中心件。好比营业中用到的富媒体（图片、音视频、Office文档等），我们很少会去存储到数据库中，更多的时间我们会把它们放在文件系统里。可是单机时代降生的文件系统，真的是最适合存储这些富媒体数据的么？不，文件系统需要改变，由于：

伸缩性。单机文件系统的第一个问题是单机容量有限，在存储规模凌驾一台机械可治理的时间，应该怎么办。性能瓶颈。通常，单机文件系统在文件数目到达临界点后，性能会快速下降。在4TB的大容量磁盘越来越普及的今天，这个临界点相当容易到达。可靠性要求。单机文件系统通常只是单副本的方案，可是今天单副本的存储早已无法知足营业的可靠性要求。数据需要有冗余（比力经典的做法是3副本），而且在磁盘损坏时及早修复丢失的数据，以制止所有的副本损坏造成数据丢失。可用性要求。单机文件系统通常只是单副本的方案，在该机械宕机后，数据就不行读取，也不行写入。

　　在漫衍式存储系统泛起前，有一些基于单机文件系统的改良版本被一些应用采取。好比在单机文件系统上加 RAID5 做数据冗余，来解决单机文件系统的可靠性问题。假设 RAID5 的数据修复时间是1天（现实上往往做不到，尤其是营业系统自己压力比力大的情形下，留给 RAID 修复用的磁盘读写带宽很有限），这种方案单机的可靠性或许是100年丢失一次数据（即可靠性是2个9）。看起来尚可？可是你得小心两种情形。一种是你的集群规模变大，你仍然沿用这个土要领，好比你现在有 100 台这样的机械，那么就会酿成1年就丢失一次数据。另一种情形是若是现实数据修复时间是 3 天，那么单机的可靠性就直降至4年丢失一次数据，100台就会是15天丢失一次数据。这个数字显然无法让人接受。

　　Google GFS 是许多人阅读的第一份漫衍式存储的论文，这篇论文奠基了 3 副本在漫衍式存储系统里的职位。随后 Hadoop 参考此论文实现了开源版的 GFS —— HDFS。但关于 Hadoop 的 HDFS 现实上业界有不少误区。GFS 的设计有很强的营业配景特征，自己是用来做搜索引擎的。HDFS 更适合做日志存储和日志剖析（数据挖掘），而不是存储海量的富媒体文件。由于：

HDFS 的 block 巨细为 64M，若是文件不足 64M 也会占用 64M。而富媒体文件大部门仍然很小，好比图片通例尺寸在 100K 左右。有人可能会说我可以调小 block 的尺寸来顺应，但这是不准确的做法，HDFS 的架构是为大文件而设计的，不行能简朴通过调整 block 巨细就可以知足海量小文件存储的需求。HDFS 是单 Master 结构，这决议了它能够存储的元数据条目数有限，伸缩性存在问题。固然作为大文件日志型存储，这个瓶颈会很是晚才遇到；可是若是作为海量小文件的存储，这个瓶颈很快就会碰上。HDFS 仍然沿用文件系统的 API 形式，好比它有目录这样的观点。在漫衍式系统中维护文件系统的目录树结构，会遭遇诸多灾题。以是 HDFS 想把 Master 扩展为漫衍式的元数据集群并不容易。

 1/4    1 2 3 4 下一页 尾页