开源软件名称：

开源软件地址：

开源软件介绍：

FastOSS 分布式对象存储系统

系统架构介绍

采用中间控制节点架构，由中间服务器控制集群。

• Tracker：中间控制节点，负责管理对象的存储位置和存储桶权限等信息。
• Storage：存储节点，存储对象数据以及对象的元数据。
• Proxy：代理服务器，负责接收HTTP请求并转发到系统中对应的处理服务器。Proxy服务器是无状态的，可以通过Nginx做负载均衡。
• Zookeeper：使用Zookeeper来管理Storage服务器，解除Tracker和Storage的耦合，避免Tracker管理大量的Storage服务器连接和心跳。

Tracker服务

Tracker记录了对象存储系统中每个对象的具体位置（在哪台Storage服务器上），同时它也作为存储桶访问权限的认证中心。

BitCask存储模型

为了保证不丢失对象的位置信息，Tracker使用了BitCask模型来存储KV数据。BitCask的优势在于，它将数据的写操作（增删改）全部转化成了顺序写，相比于随机写大大提升了写入速度。

一致性Hash负载均衡

在选择主副本存储位置时，Tracker服务器目前使用一致性Hash算法来保证Storage负载均衡。在后续的开发中将陆续引入轮询、加权轮询等更多的负载均衡算法。

存储桶访问权限

对象存储不具有文件系统的目录层级结构，不过用户可以使用存储桶来集中管理对象。在FastOSS中，存储桶有三种访问权限设置：

• 私有（Private）：对存储桶的读写全部是私有操作。
• 公共读（Public_Read）：存储桶开放读请求，写请求为私有。
• 公共写（Public_Write）：存储桶完全开放读写请求。

每个存储桶在创建后会生成唯一的AppID、AccessKey和SecretKey。用户通过这三个字符串来访问存储桶。

对于私有请求，用户需要通过SDK的Token工具，根据AccessKey和SecretKey生成访问Token，并在请求中携带Token。

Tracker缺陷

目前的Tracker是系统中唯一的单点，也就是整个系统最大的缺陷。为了避免单点的不可靠性，后续的更新会将Tracker集群化来达到高可用要求。

Storage服务

Storage存储了对象的数据和元数据。

大量小文件存储优化

由于系统的定位是存储大量小文件，所以Storage服务对小文件存储做了优化。

操作系统对每一个文件都会记录一份元数据，也就是Linux中的inode，其中包括权限组、用户组等信息。这些信息在对象存储中没有任何意义，但是会占据磁盘空间。在海量小文件的情境下，大量的文件系统元数据会占用大量磁盘资源。

为了解决该问题，FastOSS将小文件合并成大文件（Chunk），并规定每个大文件大小固定。单个的小文件都会已追加的形式写入大文件。通过这种方式减少额外的元数据存储，提升资源利用率。

删除文件时只需要在内存标记删除，后台会有专门的线程来压缩大文件中被删除的部分。

备份机制

在FastOSS中对于一个写操作，都会尝试去向半数以上的节点写入，不过我们规定只要有一台主机成功收到了副本就算成功。剩下的副本是由成功接收的主机在后台完成同步的。

在读取时，Proxy会尝试根据Quorum机制从R个主机遍历读取，直到成功读取到最新数据。

Quorum定义如下：假设有N个副本，更新操作wi 在W个副本中更新成功之后，才认为此次更新操作wi 成功。称成功提交的更新操作对应的数据为：“成功提交的数据”。对于读操作而言，至少需要读R个副本才能读到此次更新的数据。**其中，W+R>N ，即W和R有重叠。**一般，W+R=N+1。

数据可靠性

备份是最常见的数据可靠机制，FastOSS采用了最常用的三副本机制配合Quorum读写。不过副本机制并不能100%保证可靠，所以FastOSS在后续更新中会逐渐添加如EC码等更高级的机制。

EditLog编辑日志

FastOSS中的元数据除了保存在内存中还会用编辑日志的方式写入硬盘，这种机制类似Redis的AOF持久化。

众所周知，磁盘的写入速度是远不如内存的，为了提高元数据刷盘的效率，FastOSS不会把每一条元数据立即写入磁盘，而是将元数据记录先写入内存的缓冲区，再按照刷盘规则写入磁盘。

Proxy服务

Proxy类似存储系统的网关，它负责接收外部传来的Http请求，然后通过与系统内部的其他服务器交互请求完成处理，最终返回Http回复。

因为Proxy服务是无状态的，所以可以部署多台Proxy服务器并使用Nginx等工具做负载均衡。

对于热点数据，比如多次访问的Object的位置、多次访问的存储桶的权限，Proxy服务器会进行缓存，通过缓存来提高访问速度。