存储系统的那些事

存储系统，从其固有的任务，很难摆脱复杂系统的诅咒。无论是单次文件系统，还是C / S或B / S结构数据库存储中间件的兴起，还是当今最热的云存储服务，存储都非常复杂，而且越来越复杂。

存储为什么是复杂的，对于什么是存储来说说。存储这个词非常普通，存储+运算(操作)构成一个简单的计算机模型。简而言之，存储是负责维护计算系统状态的单位。在维护方面，我们有最简单的可靠性要求。文件系统如单一的时代，电力机器，程序故障，系统重启常规异常，文件系统必须正确处理，即使磁盘扇区损坏，文件系统也需要考虑尽量减少损失。对于大多数业务流程，您只需要关注业务流程的正常分支，在发生意外情况时，通常只是抛出一个错误，告诉用户:您不应该玩。但是对于存储系统，你需要把大部分的精力花在处理各种异常情况上，你应该相信，即使是这些混乱的、多样化的分支过程的错误，也是“业务逻辑”的正常存储系统。

在互联网时代，使用C / S或B / S结构，存储系统有一个新的指标:可用性。为了确保服务质量，用户不能看到的服务器程序必须在任何时候都保持在网上，最好是逻辑上说，他们不是停机时间(100%可用)。如何使服务器程序具有高可用性?答案是存储中间件。没有存储中间件，这意味着所有的业务流程，必须考虑每个步骤都是持续状态的一步，因此它们挂在另一个服务器(或重启)之后，知道在哪里工作，该做什么。但是，持久化(或存储)状态很麻烦，如果每个业务都独立实现，那么这个负担无疑是沉重的。但是如果有一个高可用性的存储中间件,服务器端业务程序简单地存储中间件更新状态和操作通过在同一时间开始为彼此做更多的业务应用程序实例和负载平衡,很容易实现业务逻辑。

因此，数据库等存储中间件的出现基本上是历史的必然。尽管数据库是通用的，但它绝不是唯一的存储中间件。例如，在业务中使用的富媒体(图片、视频、办公文档等)，我们很少在数据库中存储，我们更经常把它们放在文件系统中。但是，在独立时代诞生的文件系统真的是存储这些富媒体数据的最佳场所吗?不，文件系统需要更改，因为:

1. 伸缩性。单机文件系统的第一个问题是单机容量有限，在存储规模超过一台机器可管理的时候，应该怎么办。

2. 性能瓶颈。通常，单机文件系统在文件数目达到临界点后，性能会快速下降。在4TB的大容量磁盘越来越普及的今天，这个临界点相当容易到达。

3. 可靠性要求。单机文件系统通常只是单副本的方案，但是今天单副本的存储早已无法满足业务的可靠性要求。数据需要有冗余（比较经典的做法是3副本），并且在磁盘损坏时及早修复丢失的数据，以避免所有的副本损坏造成数据丢失。

4. 可用性要求。单机文件系统通常只是单副本的方案，在该机器宕机后，数据就不可读取，也不可写入。

在分布式存储系统出现之前，一些应用程序采用了一些基于单一文件系统的改进版本。例如，将RAID5添加到单个文件系统中，以实现数据冗余，以解决单个文件系统的可靠性问题。假设RAID5数据修复时间为1天(实际上经常不能这样做，尤其是在业务系统自身压力较大的情况下，对RAID修复磁盘读写带宽受限)，数据可靠性单一损失的方案约为100(即:可靠性是2,9)看起来?但你必须注意两种情况。一个是，你有一个更大的集群，你仍然使用相同的土壤方法，例如，你现在有100台这样的机器，然后你失去一年的数据。另一种情况是，如果实际的数据修复时间为3天，那么单台机器的可靠性将在4年内减少到数据的丢失，而在15天内将会损失100次。这个数字显然是不能接受的。

GuGe GFS是第一个被许多人阅读的分布式存储纸。本文建立了分布式存储系统中3个拷贝的状态。然后Hadoop引用本文来实现GFS - HDFS的开源版本。但是关于Hadoop的HDFS有很多误解。GFS的设计具有很强的业务背景，并被用作搜索引擎。HDFS更适合于日志存储和日志分析(数据挖掘)，而不是存储大量的富媒体文件。因为:

1. HDFS 的 block 大小为 64M，如果文件不足 64M 也会占用 64M。而富媒体文件大部分仍然很小，比如图片常规尺寸在 100K 左右。有人可能会说我可以调小 block 的尺寸来适应，但这是不正确的做法，HDFS 的架构是为大文件而设计的，不可能简单通过调整 block 大小就可以满足海量小文件存储的需求。

2. HDFS 是单 Master 结构，这决定了它能够存储的元数据条目数有限，伸缩性存在问题。当然作为大文件日志型存储，这个瓶颈会非常晚才遇到；但是如果作为海量小文件的存储，这个瓶颈很快就会碰上。

3. HDFS 仍然沿用文件系统的 API 形式，比如它有目录这样的概念。在分布式系统中维护文件系统的目录树结构，会遭遇诸多难题。所以 HDFS 想把 Master 扩展为分布式的元数据集群并不容易。