分布式文件系统

Google

chunk+chubby+bigtable
chunk 将文件分为chunk块并编号，由主控服务器控制查询

HDFS

NameNode

主服务器，数据存储在内存中。

1. 主要存储元数据，此外在外存上存储一个fsimage镜像文件已经一个editlog操作记录文件，以保证数据丢失
2. DataNode状态监控，通过短时间间隔心跳，管理DataNode

Sceondary NameNode

定期从NameNode拉取fsimage与editlog。合并成新的fsimage传回NameNode（重做一边操作?）

DataNode

负责数据块的存储与读写，存在于每个从服务器上

NameNode单点失效问题

主控服务器分为SNN与ANN两个，ANN响应请求，SNN作热备份，并可随时成为ANN。
1.使用第三方共享存储editlog，SNN不断获取editlog中操作，保证内存与ANN一致
2.DataNode心跳同时发给ANN与SNN
3.引入FC(failover controller)，将NN的健康状态发送给zookeeper，由zookeeper完成领导者选举功能

同时多个活跃的主控服务器问题

引入隔离
1.第三方共享存储，同时只能有一个NN进入
2.只有一个NN能够发出数据的删除命令
3.只有一个NN能够响应客户端
Paxos可以很好解决上述两个问题

NameNode联盟

使用多个NameNode共同管理DataNode，每个NN对应一个或多个pool，pool映射DataNode空间。添加pool层增加了开销，但是将NameNode与DataNode解耦合，pool上层可适应不同计算框架

HayStack

Blob存储系统，一次写入，多次读取，不修改，极少删除。以图片为例
1.元数据存磁盘，数据存磁盘，一次读数据访存4次
2.元数据存内存，数据存磁盘。内存不够？将多个图片合并成一个文件存储

架构

用户请求->CDN查找->HayStack缓存查找->HayStack存储
缓存系统向存储系统提供逻辑卷ID以及图片ID（这些都存在缓存系统？）。存储系统根据图片ID定位实际偏移量
添加图片在物理卷最后添加新图片
修改与删除即为将原来标记为弃用，并添加新图片，后续统一进行垃圾回收