2012-12-31
键-文件存储系统weedfs
weedfs 是跟据facebook的一篇论文 用go语言实现的key-file存储系统。
论文中facebook面临海量的photo存储,数据特点是一次写,读频繁,无修改,很少删除。
分析基于POSIX系统在此应用场景中主要的问题是元信息存储在磁盘,读元信息的磁盘IO成为性能瓶颈--
第一次(可能是多次)读盘将文件名转为i结点,第二次读盘读入i结点,第三次读盘才是读数据。
设计目标:
- 高吞吐低延时 元信息全部存储在内存,避免多次的磁盘IO
- 容错
- 简单
facebook的原始设计
浏览器请求被重定向到CDN,CDN中如果缓存了该图片则直接返回,否则查询Photo存储服务器。 Photo存储服务器是用NFS搞的,他们改了内核做了个文件描述符的缓存open_by_filehandle,用 memcache缓存打开的文件描述符,避免多次读盘
存在的问题是,缓存效果并不好: CDN中图片的访问频率存在“长尾效应”,缓存命中的只有一部分,长尾要耗很大的带宽 Photo存储服务器的缓存,效果不明显。即使有缓存也无法改变POSIX读操作需要多次磁盘操作的本质问题
多张照片存储在一个大文件里,减少文件个数
减少元数据信息,将元数据全放在内存,像权限什么的,对于该应用场景就是不
必要的
按volume,不同机器上的物理volume再划分成逻辑的volume,Directory维护逻
辑到物理的映射;
Cache作用跟原来CDN一样,主要是缓存和单点故障,不过是系统内部的;
生成URL如
http://<CDN>/<Cache>/<Machine id>/<Logical volume, Photo>
Directory作用:
- volume的逻辑物理映射
- volume的读写负载均衡
- volume满的时候,标记为只读
Cache是分布式hash表实现,照片id是key
只缓存来自user的请求,不缓存来自CDN的,因为CDN miss了,内部缓存命中的
可能性也不大。
只缓存可读的volume,因为应用场景中,photo一般是刚传上来时访问比较多
有疑问加站长微信联系(非本文作者)