01.存储基础
分布式存储基础
存储类型
存储的方式大致可以分为三类，对象存储（Object Storage）、块存储（Block Storage）和文件存储（File Storage）。不同的存储类型有各自的特点和优点，在选择的时候，我们需要根据具体情况来决定最合适的存储类型。
| 比较项目 | 块存储 | 对象存储 | 文件存储 |
|---|---|---|---|
| 基础单位 | fixed-size block | object | file |
| 支持 in-place update | 支持 | 否 | 支持 |
| protocol | SCSI, Fibre Channel, SATA | REST and SOAP over HTTP | CIFS and NFS |
| 性能 | 高 | 中等 | 高 |
| 元数据 | 少量 | 大量 | 中等 |
| 适用场景 | 交易型数据（经常需要变动的数据） | 相对静止（static）的数据 | 共享的文件 |
| 最大优点 | 高性能 | 可扩展性强、分布式使用 | 相对简化地管理 |
块存储在低延时高 IOPS 上有明显优势，特别适合数据库等高性能 IO 场景；对象存储在海量和吞吐上有明显优势，特别适合互联网图片、音视频处理场景；文件存储在吞吐和共享上有明显优势，特别适合高性能计算、以及数据共享场景。
块存储
块存储，简单来说就是使用块设备为系统提供存储服务。块存储分多种类型，有单机块存储，网络存储（如 NAS，SAN 等），分布式块存储（目前主流的如 AWS 的 EBS，青云的云硬盘，阿里云的云磁盘，网易云硬盘等）。通常块存储的表现形式就是一块设备，用户看到的就是类似于 sda，sdb 这样的逻辑设备。
块存储，不论具体存储内容的大小，都会将它存储到一个固定大小的容器中。块存储的主要特点是可以抽象成块设备，也就是大家常见的云盘。可以理解块存储为将个人用品收纳在一个固定大小的盒子内。如果我们需要寻找某件衣服，我们需要将整个盒子打开，然后一件一件地寻找。这里的盒子就相当于一个 block，这个盒子内部的空间是连续的，而且怎样摆放衣物也是不固定的（相反地，如果使用抽屉，我们就需要按照抽屉的内部构造来摆放衣物，因为抽屉会有棱棱角角，也可能会有内部的多层结构）
Block 就是一段连续的、没有硬性结构（unstructured）的比特（bytes）。通常情况下，考虑到数据存储的安全性和抗灾性，存储内容通常会被拆分成多个部分然后存储到不同的 Block 中，这样的设计同时也方便了更新过程。用户只需要去访问存储在某个 Block 中的数据信息，而非整个存储内容。
文件存储
文件存储，一般基于操作系统之上，其基本单位变成单个文件。我们最熟悉的个人电脑就将单个文件进行存储。在查找的时候，我们会通过路径来查找某个文件。通常情况下，对象会包含多个文件，我们可以理解为一个对象由多个文件组成，其中每个文件代表了一个小的部件，存储内容的时候我们会将这几个文件打包一并存储。
对象存储
对象存储，可以理解为将整个物体或者存储对象存储起来。一般来说，对象存储会同时存储大量元数据（meta data）以方便查找。通常来说，我们会把不同的衣物放进不同的抽屉或者同一抽屉的不同结构中，然后给它们贴上不同的标签。等到需要查找某个物件比如领带的时候，我们可以直接找到某一抽屉的固定地方，这样的设计简化了我们的查找过程。对象存储适合存储大量的小文件。
不同存储的应用场景
分布式数据库
在分析分布式数据库之前，我们首先需要来分析下在什么情况下应该使用分布式数据库。虽然分布式数据库看起来是一个很酷炫，而且是可以解决一切大量存储，读取的完美解决方案，但是不可避免的，在实现方式上要比单机数据库麻烦一些。那么什么时候需要考虑分布式数据库呢？根据以往的经验，如果你的系统/应用比以下规模要小，那基本不用考虑分布式数据库。
-
企业级方面：个人接触过的企业级应用，其作为数据仓库，每天从数十个系统导入数据，同时又分发到数十个系统。这样规模的系统，运行了 7，8 年，也仅仅是一个 Oracle 足够了。当然它的实时性要求不高。其他的系统，大量数据的也有用到 Oracle, DB2 cluster(一般是 2 个服务器)，运行 10 多年也足够了。对于企业级数据库，例如 Oracle，SQL-Server，DB2 等，都有各自的 cluster(集群)解决方案。不过 cluster 并非真正意义上的分布式数据库，仅仅是解决高可用性(HA)下数据库的负载均衡问题。最大的缺点就是每个数据库都是冗余的。所谓冗余，就是每个数据库的数据都是一模一样的，正因为一模一样，所以可以很简单的解决负载问题。但是数据量上升到一定程度，对集群中的每个数据库同样会造成很大的压力。虽然如此，但正如上面“是否使用分布式数据库”，你的系统/应用运行 10 年，可能都不会遇到这样的问题：因为企业级数据库的性能很高，也很容易通过硬件来扩展性能。夸张点说，甚至有的人整个 IT 职业生涯，都不会遇到必须使用分布式数据库的场合。
-
互联网方面：虽然没有什么经验，但是类似 iteye.com 这样的规模，根据其前站长分享的文章，也仅仅使用了缓存，没有使用分布式数据库。所以，如果你的系统/应用从长远来看，比以上两个规模都小，或者相当的话，是不用考虑分布式数据库的。
优势
单机房一旦死机，断电、维护根本无法挽回整个数据，想离线读取等都不行。当一个机房不可用，所有的业务就都不可用。荔枝 FM 要求业务离用户最近，南方的用户连南方的机房，北方的用户连北方的机房，国外的用户连国外的机房。大陆的网络和国外的网络有一定的隔离性，如果没有做多机房的连通性，数据的传输和实时性就会有问题。
- 数据安全：机房不可用时数据无法访问
- 业务可用性：机房不可用时业务停止
- 用户响应：因为网络连通性，不同地域的用户的请求响应延迟不同，而多机房架构下，一个机房的数据放在另一个机房是异地多活。上面是数据容灾，下面的是业务容灾，第三个是让服务离用户最近。这是荔枝 FM 做跨机房的原因。