云上存储产品主要有对象存储，块存储，网络文件系统（
NAS），还有最赚钱的CDN，我们将针对这些主流产品，讲讲他们产品特点，有云上存储时候知道如何选型，当然我们是技术型作者也会简单讲讲实现思路，出于信息安全，不可能完全阐述工业界方案。工业界各大厂商很多上层存储产品都重度依赖底层文件系统，我们也捎带说说存储祖师爷DFS。
Linux IO STACK
云计算本质就是单机计算能力的无限扩展，我们先看看单机的文件及
IO
管理。
linux
操作系统一个
IO
操作要经由文件系统
vfs
，调度算法，块设备层，最终落盘
：
（
1
）
其中
vfs层有具体的NFS/smbfs 支持网络协议派生出来NAS产品
（
2
）
VFS还有一个fuse文件系统，可切换到用户态上下文。上层分布式存储只要适配了Libfuse接口，就可访问后端存储
（
3
）
在设备层，通过扩展
ISCSI网络协议，衍生出了块存储
存储产品架构流派
分层或平层
:
如
hbase
，底层基于
hdfs
文件系统，
hbase
不用考虑
replication
，专注于自身领域问题
特点：大大降低开发成本，稳定性依赖底层存储，底层不稳定，上层遭殃。
竖井
:
自己做
replication
，自己做副本
recover
，自己做写时
recover
master-slave
体系架构
两层索引体系，解决
lots of small file
第一层，
master维护一个路由表，通过fileurl找到对应slave location（ip+port）
第二层，
slave单机索引体系，找到具体的location，读出raw data
DFS
特点
:
丰富类
posix语意，特点Append-only存储，不支持pwrite
可能存在问题
:
（
1
）
Pb级别存储方案，非EB级别。 原因namenode集中式server，内存&qps瓶颈，bat体量公司需运维上百个集群
（
2
）
默认三副本，成本高
（
3
）
强一致写，慢节点问题
演进
:
GFS2拆分了namenode，拆分成目录树，blockservice，外加ferdaration，但namespace集中式server缺陷依旧，同时切分image是要停服，水平扩展不是那么友好。
对象存储
:
元数据管理
Blobstorage： blobid->[raw data]
Metastore，aws s3又称为keymap，本质上是个kv系统。存储内容file_url->[blobid list]
I/O 路径
（
1
）
httpserver收到muti-part form,收到固定大小raw data，切成K份等长条带
（
2
）
条带做
EC，生成（N-K）份编码块，共得到N份shard。现在的问题变成了这N份数据存哪
（
3
）
客户端的代理继续向
blobstorage申请一个全局的id，这个id代表了了后端实际node的地址，以及这个node管理的实际物理卷，我们的每个分片数据均等的存在这些物理卷上。
（
4
）
分发写
N份数据，满足安全副本数即可返回写成功，写失败的可延时EC方式修复
（
5
）
httpserver将文件file及对应的分片列表以KV形式写入metastore。
特点
:
基于
http
协议
ws
服务，接口简单，
put/get
，延时高。
EB
级别存储方案，适合云上产品形态。深度目录树变成两层目录结构（
bucket+object
）。
缺点
:
posix
语意接口太少，不提供
append
语意（其实是通过覆盖写提供），更别说随机写。
iscsi模型
与后端交互的的部分在内核实现，后端
target
解析
iscsi
协议并将请求映射到后端分布式存储
特点：
（
1
）
绝大多数请求大小是
4K
对齐的
blocksize.
块设备的使用一般上层文件系统，而大多数主流文件系统的块大小是
4KB
，文件最小操作粒度是块，因此绝大多数的
IO
请求是
4KB
对齐的。
（
2
）
强一致
.
块设备必须提供强一致，即写返回后，能够读到写进去的数据。
（
3
）
支持随机写，延时要低用户基于虚拟块设备构建文件系统（
ext4
），对于文件编辑操作很频繁，所以需要支持随机写。比
NAS/Fuse
类产品性能好，只
hack
块设备读写，上层
dentry lookup
还是走原来的
IO path
，没有像
NAS/FUSE dentry
的
lookup
发起多次
rpc
问题
（
4
）
产品层面需要预先购买容量，扩容需要重新挂载，跟
NAS
比容易浪费空间
实现模型：
云盘逻辑卷按
block切分，为了便于recover，按1G切分，第一层路由由blockManager管理，按volumeid+offset 映射到逻辑block，逻辑block location在三台blockserver上。Blockserver预先创建一个1G文件（falloc，防止写过程中空间不够)，称为物理block。对于逻辑卷这段区间所有的IO操作都会落到这个物理block文件上，很容易实现pwrite。当然也可以基于裸盘，在os看来是一个大文件，分割成不同的1G文件
IO路径：
块设备上层会有文件系统，经过
io调度算法，合并io操作，isici协议发出的IO请求的都是对扇区LBA的操作，所以可以简单抽象成对于卷id加上偏移的操作，我们简单讲讲EBS（Elastic Block Store）层IO路径
（
1
）
网络发出来的
IO
请求是针对
volume+offerset
操作，假定是个写请求
（
2
）
通过
blockManager
查找到逻辑
block
（
3
）
在内存中找到
block
对应的物理地址（
ip+port
），
block
的
replicationGroup
（
4
）
使用业界通用复制链方式如
raft
协议向
replicationGroup
发送
io
请求，
raft
帮我们解决写时失败
tuncate
问题
（
5
）
单节点接到
IO
请求，把
LBA
换算成真实的文件偏移，
pwrite
写下去
优化
a、
可想而知，这种存储模型下，后端
node会有大量的随机写，吞吐肯定不高，有很大的优化空间 可以通过类似LSM引擎方式，将随机写变成顺序写，读者可深入思考，本文不详细探讨了。
b、
虚拟磁盘可以切条掉，相当于
raid盘思路，单块盘的IO变成多多块盘，增大吞吐。
NAS
用户通过
mount目录访问共享文件，mount点挂在的是一个NFS协议的文件系统，会通过tcp访问到NFS server。
NFS server是一个代理，通过libcfs最终会访问到我们后端的存储系统。
后端存储系统
DS包含管理inode的metastore和datastore，metastore
我们充分吸取业界
DFS缺点，解决Namenode集中式server瓶颈，充分考虑bigtable的各种优点。Metastore可基于分布式数据库（newsql），回想一下bigtable，一个用户的文件散落在多个tabletserver上，允许用户跨tabletserver rename操作，所以需要分布式事务完成上述保证，出于对DFS改进，我们把目录树持久化模仿linux fs dentry管理，映射规则如下两张表，dentry表和inode表，dentry表描述目录树，inode表描述文件block列表及atime，mtime，uid，gid等源信息，一般来讲硬链够用，该场景下dentry可以多份，共同指向一个inode。 dentry通过外健关联到inode表
比如
lookup 子节点
SELECT i.* FROM Dentry d, Inode i WHERE d.PARENT_DID=$PARENT_ID
datastore
特点：要求提供随机写，所以跟块存储
EBS设计思路是一样的，大文件切块，按块组织，dataserver上有真实的物理block文件，提供pwrite操作。
特点
弹性容量，不限容量，多机挂载并行读写，
IO线性增长，支持随机写比块存储优势在于用多少花多少，不需要提前申请容量，真弹性
缺点
vfs层 dentry lookup每个层级目录会发起rpc，延时高。
总结
